XMLRPC always posts to first blog (needs review)

Additional hints: i found a difference with WP.com in this case. The XMLRPC handling seems to be completely different. When using the exact Blog URL and a username which has admin access to 10+ Blogs i don't see any window to choose a blog from in Blogdesk (www.blogdesk.org). I directly get a message "the blog ID could be determined" and the blog id is inserted into the regarding field in Blogdesk. When trying the same on a standard WPMU install (no matter if with multisite plugin or not and no matter if on domains or subdomains) i always get a list of all blogs i have access to and have to choose one.

On WP.com everything is working fine and i'm able to post to any of the wp.com blogs.

@Donncha: You should probably know the differences betweens XMLRPC stuff in wp.com version and wpmu!?

Ok i found out the problem and as far as i can see that shouldn't be a big problem for a coder to fix that.

The difference between wp.com and wpmu xmlrpc answers is that wp.com reports the xmlrpc url for each blog what wpmu doesn't do.

Probably anyone around able to provide a patch for? I would if i could :(

ok i found the problem beeing known for over half a year (http://trac.mu.wordpress.org/ticket/307)

anyways... here's some comparison of wpmu / wp.com around that blogger.getUsersBlogs answer:

wp.com-version: {{{<value>

<array><data>

<value><struct> <member><name>isAdmin</name><value><boolean>1</boolean></value></member> <member><name>url</name><value><string>http://123.wordpress.com/</string></value></member> <member><name>blogid</name><value><string>123457</string></value></member> <member><name>blogName</name><value><string>test2</string></value></member> <member><name>xmlrpc</name><value><string>http://test2.wordpress.com/xmlrpc.php</string></value></member>

</struct></value>}}}

wpmu version:

{{{<value><struct>

<member><name>isAdmin</name><value><boolean>1</boolean></value></member> <member><name>url</name><value><string>http://123.blogdomain.com/</string></value></member> <member><name>blogid</name><value><string>2</string></value></member> <member><name>blogName</name><value><string>123Blog</string></value></member>

</struct></value>}}}

@Donncha: As this problem seems to be fixed with wp.com for some months now, how much work has to be done to fix it for wpmu?

dumb me just added

'xmlrpc' => get_option('home') . '/xmlrpc.php'

after line 630 in xmlrpc.php. That seems to work according to ecto's console output.

Basically this still leaves some problems that seem to reside on ecto's side but it fixes the missing xmlrpc-urls on a per-blog-base.

Don't know if this is the way it should be but probably someone could review it and work it in?

According to the ecto coder the problem is that WordPress? just ignores the BlogID within the XMLRPC requests. Also according to him this is only dirty worked around at wp.com and not really solved by returning only one blog on blogger.getUsersBlogs.

In this case it would probably be silly to just implement the same dirty solution into wpmu.

Couple of things to point out just to make sure that we are all on the same page. blog_id in WPMU and blog_id in XML-RPC aren't really the same thing. It's a long story, but for all intents and purposes WordPress? ignores blog_id in XML-RPC methods and unfortunately that isn't going to change.

What you are running into is that Ecto (and some others) expect to be able to send all XML-RPC requests to a single end point for all blogs. This doesn't work because WordPress? ignores the blog_id Ecto sends (remember above, long story, isn't going to happen). The reason Ecto and friends think this will work is because we send them all the user/blog info. Turns out the way to provide a better user experience for clients that want to use a single end point is to provide less data, not more.

So here's what I've done for WordPress?.com and what needs to happen for WPMU in general:

• Restrict blogger.getUsersBlogs to only return data for one user/blog combination when querying against an individuals blog (like josephscott.wordpress.com)
• Provide a new method, wp.getUsersBlogs, that acts just like blogger.getUsersBlogs does traditionally, with one extra bit info, the xmlrpc end point for the blog.
• Special case when calling the master blog of a WPMU install (like wordpress.com) for blogger.getUsersBlogs that overrides the method with the results of wp.getUsersBlogs

The result of these three steps has made things a little more sane for clients that only want to use one end point, but know enough to query a master WPMU blog to get a real list of blogs the user has access to. This also means that if you want to manage more than one blog in WPMU from Ecto, you have to setup an one Ecto account per blog. This is more work, but also ends up being more correct.

I'll attach some patches that make the three steps I outlined above happen. These patches worked in my test environment where all blogs are on one host. Would be nice if others tried it out under different conditions.

WPMU specific hack to provide traditional blogger.getUsersBlogs data if the query is sent to the master (blogid = 1) blog

Joseph, thanks for stepping in and beeing so precise in your answer. That clears things up a bit but also makes it more like a not-to-understand situation for me. Isn't there a clear definition about how that multiblog stuff should be handled within the API that is used here? That API isn't a WP only thing afaik and so it should be defined and there should be one clear way about how to do that sort of stuff? If: who's doing wrong in the game? If not: too bad.

Thanks also for providing the patch files but i think your agree with me that this is an ugly workaround and it's a real pity that ecto isn't usable in it's smart multiblog-stuff together with wpmu/wp.com.

Maybe there's still a way to get heads together and find a smarter solution.

When I first ran into this on wordpress.com I was fully prepared to hack up XML-RPC to properly support blog_id everywhere. The problem I ran into wasn't on the WP side, it was the API specs. To make a long story short, there are some XML-RPC methods that WP supports that don't include blog_id as a parameter. Which shot down the whole idea.

I agree that it isn't a great solution, but so far it is the only way I've found to ensure the correct behavior. And I'd much rather have correct behavior than to be elegant with completely wrong behavior. So far that has worked for wordpress.com.

Jospe, the diff file unfortunately didn't run well when applying. After opening it with a text editor i was surpised seeing half of it beeing kinda 'binary'? i'm a bit confused.

patching file xmlrpc.php Hunk #3 succeeded at 616 (offset -39 lines) patch unexpectedly ends in middle of line patch unexpectedly ends in middle of line

is the error i get when trying to patch it against the actual xmlrpc.php

any ideas?

Replying to helmi:

Jospe, the diff file unfortunately didn't run well when applying. After opening it with a text editor i was surpised seeing half of it beeing kinda 'binary'? i'm a bit confused.

I've updated the match against mu -trunk.