WordPress.org

Ready to get started?Download WordPress

Forums

Fix/remove the "future = publish" in class-wp-xmlrpc-server.php (4 posts)

  1. kailasa
    Member
    Posted 1 year ago #

    Word Press Core:

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

    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

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

    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

    class-wp-xmlrpc-server.php

    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

  2. Thanks for the feedback. You have valid points and this would have a better chance of getting looked at and possibly resolved if you created a trac ticket for it.

    You can post a new ticket using this link, http://core.trac.wordpress.org/newticket

  3. kailasa
    Member
    Posted 1 year ago #

    Aloha, Chris (I'm in Hawaii)

    Thanks for the suggestion.

    I'm not able to log in to the core.trac using the user name and password I have here. An "old-fashioned" HT basic auth dialog opens, telling me to use the same user name and password, which I did, but it just bounces back out to the ht auth modal again with the two fields blank....

  4. kailasa
    Member
    Posted 1 year ago #

    Please ignore above. I finally got into core.trac. Thanks for all the support and work all of you do for us!

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.