Make WordPress Core

Opened 11 months ago

Last modified 9 months ago

#25089 assigned defect (bug)

XML-RPC server wrongly conflates post_status "future" with "publish"

Reported by: kailasa Owned by: markoheijnen
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.4
Component: XML-RPC Keywords: 2nd-opinion dev-feedback
Focuses: Cc:


Word Press Core:


is broadcasting "future" as "publish" with this code

// Consider future posts as published

	if ( $post_fields['post_status'] === 'future' )
		$post_fields['post_status'] = 'publish';

this presents a problem for someone who really needs to use XMLRPC to talk to the wp database (via wp.getPosts/WP_QUERY et al....) and distinguish between published posts and scheduled posts.

In a real media world (of books and magazines, articles, PHD dissertations etc.) "Published" means "Now available to the public."

I can't really understand why this decision was made and would consider it a bad one. I suppose the author that file is thinking "OK the post is done and ready to go... it's just waiting for the clock to roll around... so it is effectively published." But this just shows ignorance or lack of experience in the real world of media distribution.

If a variable in a framework has 8 discreet assigned values by default, they are there, separate and distinct, for very good reasons. Future is *not* publish. The former does not appear on the blog, the latter does... they are different.

The core code should not be making decisions to override these distinctions and force developers to "unconflate" two values that someone had the not-so-bright idea to make equal.

wp.getPosts has a filter struct as one optional paramater... I should be free to pass "post_type:POST; post_status:future" as a filter so that my wp.getPosts requests only return posts with a time of now/today or earlier (i.e. post_status not equal to "future")

We have two options. We can either get all posts and then in our LiveCode web app framework (revIgniter) write a routine to parse them all for some date range to ignore all that are in the future. This a horrible hack...and will eat CPU...

OR the other option is we hack the core and comment out the offending two lines in


(which I have done for now)

But of course, we then break the Golden Rule "Don't Hack The Core!" and must remember to keep copies of our version of class-wp-xmlrpc-server.php to replace the one that comes in on upgrade... but of course this is really bad, because perhaps the next upgrade to WP has major changes to the class-wp-xmlrpc-server.php...We all know this is not best practices....

So I'm forced to go in after each upgrade and comment out the silly decision to tell the world that "consider bananas (future) equal to apples (publish)"

Please remove that code from


this opens the door to a feature request to make the XML-RPC framework customizable and extensible. I will submit that as a separate ticket but refer back to this issue. (if some developer would like "future" to be equated with "publish"... ok, fine, but that should be a "theme" option.

Change History (12)

comment:1 dd3211 months ago

Introduced with [19848] for #18433

Although I can't speak for the reasons, From what I can tell, It was probably done as WordPress considers scheduled posts as "published on a future date", and/or XmlRPC clients not having a notion of a scheduled post (it being, a future-dated published post). but I'm only guessing here.

comment:2 markoheijnen11 months ago

  • Milestone changed from Awaiting Review to 3.7
  • Severity changed from major to normal
  • Version set to 3.4

This is just a copy/paste from the other methods but yes this wasn't a smart move. The code need to change a bit but we still will force things to publish/future depending on the date.

I do have to say that you didn't need to hack core since there is a filter to add new methods to the XML-RPC. That also mean overwrite a WP method.

comment:3 markoheijnen11 months ago

#25090 was marked as a duplicate.

comment:4 nacin11 months ago

  • Keywords 2nd-opinion added

If a post has a time in the future, wp_insert_post() automatically converts 'publish' to 'future' and schedules it. So I'm not actually sure if this affects XML-RPC interaction at all, and is just designed to smooth things out for the underlying API and for clients.

comment:5 markoheijnen11 months ago

I do think that too. Even if it works fine we need to check if we can remove it. Since how the code is right now is just confusing.

comment:6 kailasa11 months ago

" I do have to say that you didn't need to hack core since there is a filter to add new methods to the XML-RPC. That also mean overwrite a WP method."

Can you explain to me how to implement this? such that the implementation falls into /wp-content/themes/myTheme

and will not be over written on upgrade? My understanding is that

our revIgniter code is using this call to WP:

return callXMLRPC("wp.getPosts", pBlogID, pUser, pPassword)

we need to do this now:

return callXMLRPC("wp.getPosts", pBlogID, pUser, pPassword, [add filter 'no-future' struct here])

The problem is: the xmlrpc server is issue "publish" as the status for all future posts.

So, if we *can* filter the future posts *before* the serve output routine, that would be great.

How? I am not a word press expert so we need your guidance.

Then we don't even had to add the struct filter to our wp.getPosts call.

comment:7 kailasa11 months ago

and BTW the behavior that automatically turns "future" into "publish" is not the issue. Of course we want that scheduling option just like it is now... changes to xml-rpc will probably not affect this at all.

comment:8 markoheijnen11 months ago

So what is the issue then? You can't have a future post in the past and you can't have a publish post in the future.

comment:9 kailasa11 months ago

  • Keywords reporter-feedback added

I'm sorry for confusing the issue. The "proper behavior" that I am referring to is not the xml-rpc server, but WordPress's method of monitoring future posts and automatically changing the post_status to "publish" when the scheduled date/time arrives. Of course, when that time arrives, it is no longer "future" it is "now"... the problem with the xml-rpc making "future=post" remains.

comment:10 SergeyBiryukov11 months ago

  • Keywords dev-feedback added; reporter-feedback removed

comment:11 markoheijnen10 months ago

  • Owner set to markoheijnen
  • Status changed from new to assigned

comment:12 nacin9 months ago

  • Milestone changed from 3.7 to Awaiting Review
Note: See TracTickets for help on using tickets.