Make WordPress Core

Opened 11 years ago

Closed 10 years ago

#28014 closed defect (bug) (invalid)

XML-RPC posting to wrong "blog" on Multisite

Reported by: rtvenge's profile rtvenge Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9
Component: XML-RPC Keywords: has-patch close
Focuses: multisite Cc:

Description

When trying to post wp.newPost to "blog" on multisite instance via XML-RPC (other than main blog aka blog_id=1), the blog doesn't post to the blog_id specified, but rather to blog_id = 1.

To replicate:

Post XML (below) to http://myrootmultisite.com/xmlrpc.php:

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
  <methodName>wp.newPost</methodName>
  <params>
    <param><value>3</value></param>
    <param><value>USERNAME</value></param>
    <param><value>PASSWORD</value></param>
    <param>
      <value>
      	<struct>
      	  <member>
                <name>post_type</name>
                <value><string>post</string></value>
            	</member>
      		<member>
      			<name>post_title</name>
      			<value><string>Test XML-RPC Post</string></value>
      		</member>
      		<member>
      			<name>post_content</name>
      			<value><string>Content of the post.</string></value>
      		</member>
      	</struct>
      </value>
    </param>
  </params>
</methodCall>

Expected result: post is created under blog_id 3.
Actual result: post is created under blog_id 1.

It's presumably ignoring blog_id.

Workaround

Workaround is to change domain to blog_id's domain (ex: mysite.multisite.com) rather than root domain (ex: multisite.com). This does not work for me, as I'm using domain mapping and cannot create an SSL Cert for every domain name.

Attachments (3)

class-wp-xmlrpc-server.php.28014.diff (466 bytes) - added by rtvenge 11 years ago.
Fix for problem by adding switch_to_blog($blog_id);
class-wp-xmlrpc-server.php.28014.2.diff (50.6 KB) - added by rtvenge 11 years ago.
Adding switch_to_blog() fix on ALL functions in XML-RPC, not just addPost.
class-wp-xmlrpc-server.php.28014.3.diff (2.4 KB) - added by rtvenge 11 years ago.
whoops! removed some other commits. :( fixed.

Download all attachments as: .zip

Change History (19)

This ticket was mentioned in IRC in #wordpress-dev by RyanT. View the logs.


11 years ago

@rtvenge
11 years ago

Fix for problem by adding switch_to_blog($blog_id);

@rtvenge
11 years ago

Adding switch_to_blog() fix on ALL functions in XML-RPC, not just addPost.

#2 @rtvenge
11 years ago

Turns out that the issue wasn't just with the wp.newPost method, but with all of them. I've uploaded an updated diff that has it fixed in all wp methods.

#3 @rtvenge
11 years ago

  • Keywords has-patch added

#4 follow-up: @kpdesign
11 years ago

@rtvenge: Thanks for the patches. :)

It seems your latest patch removes the hook docs and code changes that were committed in r27730 and r28065.

Could you update your repo to the latest version of trunk, then apply just your changes again, and upload a new patch please? :)

Last edited 11 years ago by kpdesign (previous) (diff)

@rtvenge
11 years ago

whoops! removed some other commits. :( fixed.

#5 in reply to: ↑ 4 @rtvenge
11 years ago

Replying to kpdesign:

@rtvenge: Thanks for the patches. :)

It seems your latest patch removes the hook docs and code changes that were committed in r27730 and r28065.

Could you update your repo to the latest version of trunk, then apply just your changes again, and upload a new patch please? :)

Thanks for catching that! The file my coworker gave me originated from the current Wordpress Core. Didn't even cross my mind that someone might have actually also had a change. Noop mistake, sorry. :)

#6 @josephscott
11 years ago

The blog_id value was only ever there for compatibility with XML-RPC APIs from other systems. For posting to a particular WordPress site you should use the correct XML-RPC URL for that site. If you follow the regular XML-RPC API discovery process then you will be pointed to the correct URL.

I wouldn't recommend changing how the blog_id parameter works at this point.

#7 @dinomic
11 years ago

  • Severity changed from normal to major

josephscott, I don't think that disregarding the blog_id for XMLRPC is a good idea! For a start, this functionality used to work and now doesn't - so this will break any apps that rely on this.

Secondly, the discovery relies on the root /xmlrpc.php file, so why should it *not* continue to honour other requests if a valid blog_id and credentials are sent?

Please see how this other bug I filed with is related to the blog_id issue: #28075

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#9 @rtvenge
11 years ago

Thanks for chiming in, @dinomic. I agree that the xmlrpc should (and can with my patch) obey the blog_id parameter. At this point, it doesn't even return an error, which is very confusing for the developer.

@josephscott, can you help me understand why we are adverse to applying this patch? What I'm hearing is "Let's not fix this, because the workaround works just fine". My issue with the workaround is, it's going to cost thousands of dollars in SSL certificates to securely connect to hundreds of sites on a Multisite network.

#10 @dinomic
11 years ago

@rtvenge, you hit the nail on the head! The XMLRPC "appears" to work, because there are no errors - other than you are not given access to the resources you are after. This made if VERY difficult to work out what was actually going wrong, and it's only when I found this bug report when I realised that the bug was the cause of the weird behaviour we were seeing.

IMHO, if there is a non-optional parameter that an XMLRPC method is expecting, it should make use of that parameter. If you want to drop the use of blog_id, then create a new version of the method that doesn't require it - just leave the existing method alone, working as it did before.

There's no other way to explain this but as a breaking change!

#11 @nacin
11 years ago

This has never worked. Ultimately, switch_to_blog() isn't enough, as it wouldn't result in plugins loading, or the proper theme included, etc.

It should be possible to hijack an XML-RPC request before we even choose a site in wp-includes/ms-settings.php, then based on the incoming blog ID, pick a particular site. At the moment though, this isn't something we are going to be able to do in core. First, it's really hacky. And second, if we suddenly start listening to the blog ID after all of these years, I guarantee some existing XML-RPC call will break.

#12 follow-up: @dinomic
11 years ago

@nacin, I beg to differ about it not working before. We have a mobile app out there that worked just fine before the 3.9 update, and now we're having to change things because the blog_id is ignored.

#13 in reply to: ↑ 12 @nacin
11 years ago

Replying to dinomic:

@nacin, I beg to differ about it not working before. We have a mobile app out there that worked just fine before the 3.9 update, and now we're having to change things because the blog_id is ignored.

I promise we have never, ever respected the blog_id parameter. Ever.

It's possible that you had special code in place that no longer works due to multisite changes in 3.9 (namely, #27003), but that shouldn't have broken anything, and if it did, please file a bug report.

#14 @markoheijnen
10 years ago

#28075 was marked as a duplicate.

#15 @markoheijnen
10 years ago

  • Keywords close added
  • Severity changed from major to normal

I also worry that it will break things and because of that I would close this ticket. Also the patch is a bit to easy. For example I would ignore switch_to_blog() when not on the main site because we can't expect that all developers would pass 0 as the blog_id.

We could pass the arguments to the action 'xmlrpc_call' so if someone wants to try make blog_id parameter working they can do that on a more easy way.

#16 @nacin
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

See also comment:11 as to why I'd hesitate to even try switch_to_blog() for this.

Note: See TracTickets for help on using tickets.