[wp-trac] [WordPress Trac] #25089: XML-RPC server wrongly conflates post_status "future" with "publish"

[WordPress Trac]

#25089: XML-RPC server wrongly conflates post_status "future" with "publish"
--------------------------------------+------------------------------
 Reporter:  kailasa                   |       Owner:  markoheijnen
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  XML-RPC                   |     Version:  3.4
 Severity:  normal                    |  Resolution:
 Keywords:  2nd-opinion dev-feedback  |     Focuses:
--------------------------------------+------------------------------

Comment (by kailasa):

 Replying to [comment:12 nacin]:

 I'm curious why this was pushed back to "Awaiting Review"

 Again, the issue is simple: the  xmlrpc server

 /wp-includes/class-wp-xmlrpc-server.php

 is wiping out the post status value of "future"


 {{{
 // Consider future posts as published

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

 }}}

 The problem remains: We have differentiated values in the database for a
 good reason. If I query wp_post, I should be able to filter out any
 "future" posts so that only those that are currently seen by blog
 visitors, will be called.

 It's just "wrong" for the core code to force conflate the two. We should
 be able to depend on the date base to return what is there. What is done
 here would be similar to force-ably doing this:


 {{{
 if ( $post_fields['last_name'] === 'Smith' )
                 $post_fields['last_name'] = 'Jones';

 }}}

 Which means we can never target "Smith" when requesting a name list.

 As it is now we have to write "hacks" to filter the results ourselves
 which we do in LiveCode like this:


 {{{
 function wpGetLastPosts pBlogID, pUser, pPassword
 # make a call to wp.getPosts:
         put wpGetPosts(sWordpressBlogID,
 sWordpressUsername,sWordpressPassword) into tA
         put the keys of
 tA["methodResponse"]["params"]["param"]["value"]["array"]["data"] into
 tList
         replace "value[" with empty in tList
         replace "]" with empty in tList
         sort tList
     put 0 into k
 # We should not need to do the following parsing and evaluation routine on
 the data.

 repeat for each line x in tList
                 put "value["&x&"]" into tPost
                 put
 tA["methodResponse"]["params"]["param"]["value"]["array"]["data"][tPost]["struct"]["member[3]"]["value"]["dateTime.iso8601"]
 into tTemp
                 put char 1 to 4 of tTemp into tYear
                 put char 5 to 6 of tTemp into tMonth
                 put char 7 to 8 of tTemp into tDate
                 put (tYear , tMonth , tDate,0,0,0,0) into tPostDate
                 convert tPostDate to long internet date
         -- Comparing the date with the actual date, do not show anything
 from the future
         put (tYear , tMonth , tDate,0,0,0,0) into tPostDateInSeconds
         convert tPostDateInSeconds to seconds
         put the date && the time into tCurrentDateInSeconds
         convert tCurrentDateInSeconds to seconds

         if (tPostDateInSeconds > tCurrentDateInSeconds) then
             next repeat
         end if
 }}}

 it would be better if we could simply depend on the database for what is
 actually in the database, like this


 {{{
 repeat for each line x in tList
                 put "value["&x&"]" into tPost
                 put
 tA["methodResponse"]["params"]["param"]["value"]["array"]["data"][tPost]["struct"]["member[4]"]["value"]["post_status"]
 into tPostStatus

         if tPostStatus = "future" then
             next repeat
         end if

 # thus ignoring all posts that are scheduled
 }}}

 I have other plans which will involve calls to wp.getPosts and I *really*
 need to be able to depend on "future" is not equal to "published" which
 obviously it is not in the database itself.


 Besides, even the conceptual view that a post that has been scheduled is
 no longer a draft is therefore "published" breaks a core media content
 production principle, (I'm talking with 40 years experience in this field,
 if that carries any weight) Ask any newspaper managing editor or book
 publisher. Much content is created in advance and then it is given a
 "publication date"  in the future... it is not considered "published"
 until that date actually arrives. There are huge dependencies on being
 able to "trust" that this is true. But Word Press's xmlrpc server is
 breaking this "trust."  Something is really, only truly published when it
 has an audience that can see it; advertisements which are getting views;
 available for click throughs etc.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/25089#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform