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.
I can't really understand why this decision was made and would consider it a bad one. If a variable in a framework has 8 discreet assigned values by default, they are there, separate and distinct, for very good reasons.
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 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
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 each time and comment out the silly decision to tell the world that "consider bananas (future) equal to apples (publish)" and add change any other customizations we make to get the xmlrpc framework to meet our needs.
Also we are finding other issues with calling xmlrpc. I could detail these here, but it's also probably not a wise route to open a door for all developers to pile on about what they want in
The issue is really that this part of the framework does not follow the model of customization/extensibility. That code that conflates "future" with "publish" should really be a developer option that we can add to our theme/functions, etc. such that it customizes the xmlrpc behaviors, is preserved on upgrade and does not require core to manage X number of custom xmlrpc requirements. This the way themes work and it should also work for xmlrpc. If someone wants "future" to equal "publish" he can make is so without touching the core.
So, for now I have three requests:
1) Please! remove that code that broadcasts "future" as "publish" from the "class-wp-xmlrpc-server.php"
2) consider providing a custom API to xmlrpc that follows with the preserved-on-upgrade /wp-content/theme/plug-in model, for customization and extensibility.
3) And last: if anyone has a solution for "undoing" the "future=publish" output for any xmlrpc request to wp.GetPosts, which would not require us to edit the "class-wp-xmlrpc-server.php" file... I could use that right now as a solution while you all think about 1 and 2 above