kailasa
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: Upgrade to PHP 5.5.15 Broke Word Pressit appears that Word Press is working now… duh! Cookies which held session variables and data were being called by the browser, but these were some how no longer available after the core PHP upgrade. How the core PHP upgrade to 5.5.15 could affect a domain level entry like this I don’t know, but it did. Basically it caused GET requests to pull the *.php text and not actually trigger apache to execute the PHP. After clearing the cache include all cookies.. then reloading it worked… very strange.
The good news is (probably not news at all) WP works fine with PHP 5.5.15
case closed.
Forum: Fixing WordPress
In reply to: Upgrade to PHP 5.5.15 Broke Word PressHosting provider is ServePath, GoGrid in San Franscisco… I can’t see word press to check on the version… but I have FTP access… what file to I check to see the version?
Forum: Plugins
In reply to: [WP-o-Matic] Can I use WP-0-Matic to import an RSS file?I should add that we want to poke the category for all these as “Archives” when we do the import.
Forum: Requests and Feedback
In reply to: Fix/remove the "future = publish" in class-wp-xmlrpc-server.phpPlease ignore above. I finally got into core.trac. Thanks for all the support and work all of you do for us!
Forum: Requests and Feedback
In reply to: Fix/remove the "future = publish" in class-wp-xmlrpc-server.phpAloha, 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….
Forum: Fixing WordPress
In reply to: How Do You Show "Future" in the Post Status Options Dropdown Menu?Yes, I understand how it works. But “future” is not redundant as it means we can filter posts beyond today without having to script complicated routines to parse for and compare date strings.
My actual goal is to get the latest post that is published to appear on the home page of my web site. The problem is that the easiest way to do this is to use the XMLRPC API wp.getPosts, which leverages wp_query class. This is obviously what all that is for. And it works just fine.
But when we do this, posts that are set with a date in the future appear as the latest post on the home page, (because post_status=’published’) but do not appear on the blog itself because they remain as “scheduled.”
I need to use the wp.getPosts API and pass to it the struct.filter.post_status.published. And to have the future posts post_status set to “future” this way my call to wp_getPosts will only pull “published” and ignore those set to “future” wp_getPosts API does not even provide hooks to filter on date ranges… so… you see, post_status=future not redundant at all.
Unfortunately even the engineers at the WP core lacked the vision to see why a post_status of “future” has intrinsic value and entered this unfortunate override in /includes/class-wp-xmlrpc-server.php
// Consider future posts as published
if ( $post_fields[‘post_status’] === ‘future’ )
$post_fields[‘post_status’] = ‘publish’;This is just wrong… don’t make two values the same. They are different for a reason, otherwise we would not have different values in the first place. Just because you don’t know the reason, does mean it’s useful to hard wire into the frame work something that conflates the two.
OK, so now it appears I will need to use the plug in that allows finer control over the post_status, and the “hack the core” by commenting out that section in the class-wp-xmlrpc-server.php file.
This is not ideal. On upgrade I’ll need to keep fixing that file. As the monsters say “argh!”