Future posting with dateCreated in Wordpress via XMLRPC in Ruby - ruby

I'm reaching the end of my tether trying to schedule a new post through Wordpress' XMLRPC interface from Ruby.
I am creating a new Time object and filling it with my date and time, I then call .xmlschema to get a datetime string in the correct format for Wordpress' XMLRPC interface.
Unfortunately, Wordpress treats this as a string, and I can't work out how to get the xmlrpc.php to treat it as an object; really can't get my head around it.
Calling the metaWeblog.newPost method, and sending:
{:title => 'Foo', :post_status => 'publish', :dateCreated => my_date.xmlschema}
to Wordpress.
Anyone been through this before?

Can you check what you are actually sending (the post data)? The date should be encapsulated in <dateTime.iso8601></dateTime.iso8601>, not in <string></string>. The WordPress Trac has a similar report.

Related

Pull FullContact Ruby Gem Photos?

https://github.com/fullcontact/fullcontact-api-ruby
I'm trying to use the FullContact API Wrapper for Ruby (it's a gem) instead of the pure REST API. I'm trying to figure out how to grab the person's profile pictures from email address. I know how to get them from the REST API that responds with JSON, but not sure what the example code there is doing.
person = FullContact.person(email: "brawest#gmail.com") (pulled from example in the Github linked)
So now how do I retrieve profile pictures from person? What data type is it storing?
The FullContact gem uses Hashie, and from a call it returns a Hashie::Rash object.
So if you were trying to access photos:
> person = FullContact.person(email: "email")
=> [#<Hashie::Rash contact_info=#<Hashie::Rash family_name=...
> person.photos
=> [#<Hashie::Rash is_primary=true type="facebook" type_id="facebook" type_name="Facebook"...
Hope that helps!

Render a view's output later via a delayed_job

If I render html I get html to the browser which works great. However, how can I get a route's response (the html) when being called in a module or class.
I need to do this because I'm sending documents to DocRaptor and rather than store the markup/html in a db column I would like to instead store record IDs and create the markup when the job executes.
A possible solution is using Ruby's HTTP library, Httparty or wget or something and open up the route and use the response.body. Before doing so I thought I'd ask around.
Thanks!
-- Update --
Here's something like what I ended up going with:
Quick tip - in case anyone does this and need their helper methods you need to extend AV with ApplicationHelper:
Here's something like what I ended up doing:
av = ActionView::Base.new()
av.view_paths = ActionController::Base.view_paths
av.extend ApplicationHelper #or any other helpers your template may need
body = av.render(:template => "orders/receipt.html.erb",:locals => {:order => order})
Link:
http://www.rigelgroupllc.com/blog/2011/09/22/render-rails3-views-outside-of-your-controllers/
check this question out, it contains the code probably want in an answer:
Rails 3 > Rendering views in rake task

CouchDB: weird query_parse_error with curl, not with Ruby

I'm hosting my Couch instance on iriscouch.com and doing some testing with a simple Sinatra app, using CouchRest Model.
Here's a simple model I'm using:
class User < CouchRest::Model::Base
property :first_name, String
property :last_name, String
timestamps!
design do
view :by_first_name
end
end
I'm successfully creating new users with:
User.create(:first_name => "Stonewall", :last_name => "Jackson")
Executing User.by_first_name.all results in this HTTP request:
http://test_admin:pwd#testytest.iriscouch.com:80/blt/_design/User/_view/by_first_name?include_docs=true&reduce=false
"Accept"=>"application/json"
"Accept-Encoding"=>"gzip, deflate"
"Content-Type"=>"application/json"
This is executed by RestClient, via CouchRest. No problems there.
But when I try to curlthis URL, I get complaints from Couch about the include_docs parameter:
{"error":"query_parse_error","reason":"Query parameter `include_docs` is invalid for reduce views."}
I'd like to understand what's going on here. Why is include_docsa problem only when using curl?
One difference is that your URL now contains a question mark. If you don't protect the URL in the shell, it will be interpreted as a special character.
If you want a simpler way to test your services, you can use RESTClient instead of curl.

Padrino model from json data

I have been looking at Padrino for a project I am working on, and it seems a great fit, as I would ideally be wanting to support data being sent and received as json.
However I am wondering if there is any automated helper or functionality built in to take data from a post request (or other request) and put that data into the model without having to write custom logic for each model to process the data?
In the Blog example they briefly skim over this but just seem to pass the parameter data into the initilizer of their Post model, making me assume that it just magically knows what to do with everything... Not sure if this is the case, and if so is it Padrino functionality or ActiveRecord (as thats what they seem to use in the example).
I know I can use ActiveSupport for JSON based encoding/decoding but this just gives me a raw object, and as the storage concerns for each model reside within the main model class I would need to use a mixin or something to achieve this, which seems nasty.
Are there any good patterns/functionality around doing this already?
Yep, you can use provides and each response object will call to_json i.e:
get :action, :provides => :json do
#colletion = MyCollection.all
render #collection # will call #collection.to_json
end
Here an example of an ugly code that fills certain models.
# Gemfile
gem 'json' # note that there are better and faster gems like yajl
# controller
post "/update/:model/:id", :provides => :json do
if %w(Account Post Category).include?(params[:model])
klass = params[:model].constantize
klass.find(params[:id])
klass.update_attributes(JSON.parse(params[:attributes]))
end
end
Finally if you POST a request like:
attributes = { :name => "Foo", :category_id => 2 }.to_json
http://localhost:3000/Account/12?attributes=#{attributes}
You'll be able to update record 12 of the Account Model.

Where did this Ruby parameter convention come from?

There's a piece of Ruby middleware used by Rails and other frameworks to the parse the parameters you've sent to the server into a nested Hash object.
If you send these parameters to the server:
person[id] = 1
person[name] = Joe Blow
person[email] = joe.blow#test.com
person[address][street_address] = 123 Somewhere St.
person[address][city] = Chicago
person[address][zip] = 12345
person[other_field][] = 1
person[other_field][] = 2
person[other_field][] = 3
They get parsed to this:
{
:person => {
:id => "1",
:name => "Joe Blow",
:email => "joe.blow#test.com",
:address => {
:street_address => "123 Somewhere St.",
:city => "Chicago",
:state => "IL",
:zip => "12345"
},
:other_field => [ 1, 2, 3 ]
}
}
I believe this is supported by PHP as well. Can anybody tell me what this convention is called, where it came from, and what other languages support it? (Perl, Python, etc.)
Field research
I'm trying to find out if there's a name for this convention, but I can't find it yet.
Ruby
For what it's worth, the piece of middleware that does this in Ruby is Rack::Utils. See the source on Github.
There is some more information on the subject in the Ruby on Rails Guides.
And here is an interesting ticket about the code being moved from Rails to the Rack middleware.
PHP
I've done some digging in the PHP source, and it seems that all the magic there happens in the main/php_variables.c source file. The SAPI code calls the php_std_post_handler method defined here. This eventually calls the php_register_variable_ex method, which is 185 lines of complex string-parsing in C (I must admit that C isn't my forte).
The only name I could find here was the php_std_post_handler, the PHP standard POST handler.
Python
In Python, this format isn't supported by default. See this question here on stackoverflow.com on the subject.
Perl
The CGI library in Perl doesn't support this format either. It does give easy access to single or multiple values, but not nested values as in your example. See the documentation on feching the value or values of a single named parameter and fetching the parameter list as a hash.
Java
Check out the heated debate on the subject of query parameter parsing in this question. Java doesn't parse this 'nested format' of POST parameters into a data structure by default.
Conclusion
I've looked into this, and haven't found a single name for this way of parameter parsing. Of the languages that I've looked into, only Ruby and PHP support this format natively.
It's not called anything, AFAIK, other than "sending parameters". If anything, it's called "parameter [type] conversion", where Rails just "converts" it into a hash.
Other frameworks go further, using the parameter names as expressions used to create typed objects initialized with type-converted parameter values.
All parameters are is a string value with a name. Any/all structure is imposed by the language/framework in use on the server side; what it gets transformed to is 100% dependent on that language/framework, and what that conversion consists of would determine what it would be (reasonable) called.
that would be a JSON object, which is quite standard and supported by most languages/libraries these days.

Resources