Future dated posts not publishing

[fleety]

Futher to this ticket #3565.

My wordpress blog will not publish future dated posts. Same issue as Trent on ticket #3565. I have a permissions issue. For example, see below. I have changed the permission to 777 for wp-cron.php. Yet still nothing.

My wordpress is 2.1. Fantastico installation.

---

Sample error log
[Sat Feb 3 08:43:09 2007] [error] [client 72.232.95.34] File does not exist: /home/theturne/public_html/403.shtml
[Sat Feb 3 08:43:09 2007] [error] [client 72.232.95.34] client denied by server configuration: /home/theturne/public_html/wp-cron.php
[Sat Feb 3 08:43:08 2007] [error] [client 72.232.95.34] File does not exist: /home/theturne/public_html/403.shtml
[Sat Feb 3 08:43:08 2007] [error] [client 72.232.95.34] client denied by server configuration: /home/theturne/public_html/wp-cron.php

[ryan]

That error is issued by Apache. The mod_dosevasive Apache module is often responsible for it. dosevasive is meant to thwart DOS attacks. If dosevasive is the reason, I'm not sure why wp-cron.php is triggering it. If wp-cron.php is missing, bug #3713 will cause an infinite loop that could cause wp-cron.php to raise the ire of dosevasive. In your case, however, wp-cron.php appears to be present. Try ​this version of wp-cron.php and see if it at least helps with the error messages. It might not remedy the ultimate problem with future postings, but let's see if it makes any difference to the client denied errors.

We may need some help from your host to see if mod_dosevasive is indeed installed and if wp-cron.php is hitting some criteria that is causing it to be denied.

[ryan]

Oops. That should read "try ​this version of wp-includes/cron.php". Download the file and overwrite your existing wp-includes/cron.php.

[fleety]

No. I uploaded the second file you references, and the error messages are still occuring.

Thanks for the suggestion. Anything else?

[ryan]

I think we need the information I mentioned above from your host.

[gMk]

Same issue.

Tried all the above. No result. Do-evasive is not activated.

Server environment

PHP 4.3.9-3.22
mysql 4.1.20-1.RHEL4.1

Nothing showing in the error log. And for that matter nothing showing in the access log either - ie - no references to cron or wp-cron

[johnmarkschofield]

I can verify that I am currently experiencing this bug.

What I did:
Created a post, and selected the checkbox to modify the timestamp. Then I selected a time five minutes in the future, and clicked the "Publish" button. Then I watched the display of "Scheduled Entries" on the Dashboard, and the main page of the site, alternately clicking "refresh" on each page.

What I expected to happen:
I expected the display of minutes remaining on the "Scheduled Entry" to count down to 1 or zero. I then expected refreshing the main page of my blog would show me the published entry.

What actually happened:
The minutes remaining for the scheduled entry counted down to 1, stayed there for three minutes, and then started increasing by one each minute. Refreshing the main page shows that the future-dated (now past-dated) post has not been posted. Checking the post itself in the Manage Pages --> Edit screen shows that it is "apparently" published (The radio button on "Published" is selected, and the date is in the past.)

Additional Information:
My blog time zone is set correctly, and the example times on the options page show the correct time in my time zone.

My host is nearlyfreespeech.net, on a manually-installed WordPress 2.2.

My blog's url is blog.sudosu.net.

Php -v from the command line gets me:
PHP 4.4.6 with Suhosin-Patch 0.9.6 (cli) (built: Apr 5 2007 00:40:40)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

My wp-cron.php file exists, and is readable by the web server:
-rw-r--r-- 1 me me 849B May 26 18:26 wp-cron.php

I've grepped through access.log and error.log (from Apache) and wp-cron.php isn't mentioned in either. Ever.

[johnmarkschofield]

As an additional bit of data, let me say that loading wp-cron.php in a web browser after the scheduled publication time does NOT fix the problem -- this does not appear to be a problem with wp-cron.php not being called, but with wp-cron.php not doing whatever it's supposed to do when it's called.

[Otto42]

Somebody has to load your actual website for wp-cron to be called. Did you look at the blog itself? Or just reload the admin screens?

Also, calling it directly should cause the post to publish. What is the value of the "cron" option in your database?

[Otto42]

Edit: Scratch that, calling wp-cron manually will not force it to work, because you won't have the necessary hash and wp-cron will exit. This is to prevent denial of service attacks, I think.

[foolswisdom]

Replying to Otto42:

Edit: Scratch that, calling wp-cron manually will not force it to work, because you won't have the necessary hash and wp-cron will exit. This is to prevent denial of service attacks, I think.

Otto, I think you are correct about the reasoning.

For testing, I comment out those to lines.

[johnmarkschofield]

Replying to Otto42:

Somebody has to load your actual website for wp-cron to be called. Did you look at the blog itself? Or just reload the admin screens?

Also, calling it directly should cause the post to publish. What is the value of the "cron" option in your database?

I was switching between the admin page ​http://blog.sudosu.net/wp-admin and the main page ​http://blog.sudosu.net, hitting refresh on each. So even if loading wp-cron.php in my browser won't work, it should have been called correctly by hitting reload on the main page.

I have both command-line and PHPMyAdmin access to my Mysql database, but I'm not sure where to find the "cron" value. Is this still something you need? Can you give me more details on how to do this so I can provide you the requested info? What table is it in?

Thanks very much!

[Otto42]

It's in the options table. It has a name of "cron" and the value itself, a big long weird looking string, is what we need to see.

[intoxination]

Replying to johnmarkschofield:

Replying to Otto42:

Somebody has to load your actual website for wp-cron to be called. Did you look at the blog itself? Or just reload the admin screens?

Also, calling it directly should cause the post to publish. What is the value of the "cron" option in your database?

I was switching between the admin page ​http://blog.sudosu.net/wp-admin and the main page ​http://blog.sudosu.net, hitting refresh on each. So even if loading wp-cron.php in my browser won't work, it should have been called correctly by hitting reload on the main page.

I have both command-line and PHPMyAdmin access to my Mysql database, but I'm not sure where to find the "cron" value. Is this still something you need? Can you give me more details on how to do this so I can provide you the requested info? What table is it in?

Thanks very much!

[intoxination]

Ahh Sorry about that. Someone posted when I did and it screwed me up.

In /wp-cron.php, comment out the following lines:

if ( $_GET['check'] != wp_hash('187425') )
	exit;

Then try to call wp-cron.php from your browser and see if that works.

[johnmarkschofield]

Replying to Otto42:

It's in the options table. It has a name of "cron" and the value itself, a big long weird looking string, is what we need to see.

doing_cron = 1182354680

cron = a:58:{i:1180297276;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180367541;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180367611;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180491368;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180491419;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180575787;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180901298;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180902035;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180902094;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180903177;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180903224;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180903254;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180989783;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180990268;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180990712;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180990745;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1180990845;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181188323;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181188518;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181413366;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181413596;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181413666;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181413724;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181413767;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181413811;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181414124;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181414164;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181414188;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181414314;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181414377;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181414554;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181414602;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181414874;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181667564;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181936573;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1181936603;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147009;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147063;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147114;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147190;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147355;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147433;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147551;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147771;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147810;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147861;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182147916;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182196779;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182196887;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182213484;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182230655;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182271068;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182271185;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182291692;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182291868;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182291877;a:1:{s:8:"do_pings";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:2:{s:8:"schedule";b:0;s:4:"args";a:0:{}}}}i:1182292899;a:1:{s:19:"publish_future_post";a:1:{s:32:"bed4dd527a4e72670c1622eaea39b524";a:2:{s:8:"schedule";b:0;s:4:"args";a:1:{i:0;i:197;}}}}s:7:"version";i:2;}

[johnmarkschofield]

Replying to intoxination:

Ahh Sorry about that. Someone posted when I did and it screwed me up.

In /wp-cron.php, comment out the following lines:

if ( $_GET['check'] != wp_hash('187425') )
	exit;

Then try to call wp-cron.php from your browser and see if that works.

To make sure I did the edits properly (I'm not fluent in PHP), here's my wp-cron.php file:

[me@sudosublog /home/htdocs]$ cat wp-cron.php

<?php
ignore_user_abort(true);
define('DOING_CRON', TRUE);
require_once('wp-config.php');

if ( $_GETcheck? != wp_hash('187425') )
exit;

if ( get_option('doing_cron') > time() )

exit;

update_option('doing_cron', time() + 30);

$crons = _get_cron_array();
$keys = array_keys($crons);

if (!is_array($crons)

$keys[0] > time())

return;

foreach ($crons as $timestamp => $cronhooks) {

if ($timestamp > time()) break;
foreach ($cronhooks as $hook => $keys) {

foreach ($keys as $key => $args) {

$schedule = $argsschedule?;
if ($schedule != false) {

$new_args = array($timestamp, $schedule, $hook, $argsargs?);
call_user_func_array('wp_reschedule_event', $new_args);

}
wp_unschedule_event($timestamp, $hook, $argsargs?);
do_action_ref_array($hook, $argsargs?);

}

}

}

update_option('doing_cron', 0);

?>

[me@sudosublog /home/htdocs]$

[johnmarkschofield]

Replying to intoxination:

Ahh Sorry about that. Someone posted when I did and it screwed me up.

In /wp-cron.php, comment out the following lines:

if ( $_GET['check'] != wp_hash('187425') )
	exit;

Then try to call wp-cron.php from your browser and see if that works.

Perfection. Calling wp-cron.php in this way DOES publish future-dated posts. My test from yesterday just showed up.

[johnmarkschofield]

Additional Information:

1) With the "wp_hash" line commented out of wp-cron.php, the problem continues. (As I reported earlier, with that commented out, loading wp-cron.php in a browser DOES publish the future-dated posts. But I thought making the change to wp-cron.php might fix the overall problem of future-dated posts not being published automatically. It did not fix it.)

2) Just to idiot-check, I disabled my custom theme, and switched to Kubrick. The problem continued unchanged. This is not a theme issue.

[intoxination]

So the problem is in WP not calling your cron. Are you sure your host allows fsockopen to port 80? It is not uncommon for some hosts to block this (which is required for cron).

[johnmarkschofield]

Replying to intoxination:

So the problem is in WP not calling your cron. Are you sure your host allows fsockopen to port 80? It is not uncommon for some hosts to block this (which is required for cron).

I'm about to post a support request to my host to ask that question. Is there any way I can determine that on my own?

[intoxination]

Are you able to send/recieve trackbacks/pings? If so then FSock is O.K.

[johnmarkschofield]

Replying to intoxination:

Are you able to send/recieve trackbacks/pings? If so then FSock is O.K.

Pingbacks/Trackbacks do not appear to be working. I host two Wordpress installations on Nearlyfreespeech.net -- blog.sudosu.net, for my blog, and www.sudosu.net, for my more static content. I created a post on www.sudosu.net, and created a link in the body to a post on blog.sudosu.net. (That should have created a pingback, yes?) Then I modified the post on www.sudosu.net, adding a manual trackback (using the field at the bottom of the edit window) to the url of the post on blog.sudosu.net (​http://blog.sudosu.net/2007/worst-listening-comprehension-ever/). Both of those should have showed up as pingbacks/trackbacks on that article, no?

They did not. Did not show up on the page, or as comments needing moderation.

I'm not entirely familiar with pingbacks/trackbacks, so I'm not 100% certain I've done this correctly -- but to me it looks like trackbacks and pingbacks are not working. Does that seem correct?

--jms

[intoxination]

I would venture to say that it is an FSock problem then. Your best bet would be to ask tech support from your host about their FSock support and what limits it may have.

[Otto42]

If you have pings on, and you post a link to one of your own posts in another of your posts, then you should, very shortly after running wp-cron, automatically get a new "comment" posted in the original post.

Like this:
You make post A, and leave pings enabled on that post.
You make post B (which contains a link to post A).
You run wp-cron manually (as discussed before) or it runs automatically.
Post A automatically gets a new comment that says, basically, post B exists.

That's a pingback. If these do not appear, then your site is blocked from connecting back to itself for whatever reason.

And because of the way 2.1 and up now uses wp-cron, this sort of thing will also prevent wp-cron from running and thus prevent future posting from working as well.

In order for wp-cron to run automatically, the code has to be able to open a connection to itself. Sometimes this is prevented due to bad DNS settings, sometimes it's prevented due to stupid security policies. But regardless, it'll break wp-cron from working, which now prevents a lot of other things from working.

Solutions:
-Get the host to fix it
-Get a better host
-Switch back to Wordpress 2.0.whatever.

In any case, this is not a Wordpress bug, it's a hosting issue.

[johnmarkschofield]

Sorry, not closed.

In my previous trackback test, I did NOT run wp-cron.php manually (loading it in a web browser).

I have since followed your suggestions above. I made post B, and linked to a previously-created post A. I then looked at Post A. No trackback. I then ran wp-cron.php manually. The pingback appeared correctly. You can verify this at ​http://blog.sudosu.net/2007/lots-more-photos-on-flickr/

So my lack of pingbacks/trackbacks appears to be the same problem that is keeping future posting from working.

[intoxination]

Have you tried disabling all plugins and going to your default theme?

[Otto42]

The pingback appeared correctly.

Well, that blows that theory out of the water then. If the pingback appeared, then that means that it was successfully able to do an fsockopen to your own server.

2 things to check:

1. Check that both the URL's on the Options->General page are correct. Wordpress uses the first of these as the website that it's hitting when it tries to run wp-cron.

2. Try it again on an automatic basis, but forcibly set doing_cron = 0 in your database before you do it. Then you have to hit the website after the future post time to make it try to run wp-cron.

[johnmarkschofield]

Replying to intoxination:

Have you tried disabling all plugins and going to your default theme?

The only plugin I have active is Google Sitemaps. I had previously tried the default (Kubrick) theme. Just to idiot-check, I disabled the Google Sitemaps plugin, and switched to Kubrick. The problem continued unchanged.

[johnmarkschofield]

Got a response from my host -- which doesn't shed much light on the matter:

Hi John -- If done properly this should work, but if you are connecting to yourself, there are numerous ways to break it. Unfortunately there's not enough information in that thread to give us a good clue what is going on. Check the response code from the fsockopen() call to see if it works.

If Wordpress is ignoring a failure, that would definitely be a Wordpress bug.

Cheers,

Kirsten

On Wed, 20 Jun 2007, 18:40:11 UTC, John Schofield wrote:

I'm adding to an existing case in the WordPress bug DB:

​http://trac.wordpress.org/ticket/3742#comment:9

We've isolated the problem to Wordpress not calling the wp-cron.php
file.

They are asking, "So the problem is in WP not calling your cron. Are
you sure your host allows fsockopen to port 80? It is not uncommon
for some hosts to block this (which is required for cron)."
​http://trac.wordpress.org/ticket/3742#comment:23

Does NFSN allow fsockopen to port 80?

If not, is it possible to enable this?

Thanks very much!

[johnmarkschofield]

Replying to Otto42:

The pingback appeared correctly.

Well, that blows that theory out of the water then. If the pingback appeared, then that means that it was successfully able to do an fsockopen to your own server.

2 things to check:

1. Check that both the URL's on the Options->General page are correct. Wordpress uses the first of these as the website that it's hitting when it tries to run wp-cron.

Both of them are: ​http://blog.sudosu.net

2. Try it again on an automatic basis, but forcibly set doing_cron = 0 in your database before you do it. Then you have to hit the website after the future post time to make it try to run wp-cron.

The value of doing_cron is currently 0. (I did not change anything. When I went into phpmyadmin, I saw the value was 0.) I loaded blog.sudosu.net multiple times, and the future-dated post did not appear.

[johnmarkschofield]

I have a hand-edited .htaccess file. Just as an idiot-check, I renamed it to .htaccess.disabled. Of course, all my links stopped working, but I was able to go to and reload ​http://blog.sudosu.net . The "missing" future-dated posts did not appear -- so it's not a case of .htaccess redirecting traffic away from wp-cron.php. (I didn't think it was -- but now I'm sure.) I've since renamed it BACK to .htaccess, and made the site work again. {grin}

[intoxination]

Replying to johnmarkschofield:

Got a response from my host -- which doesn't shed much light on the matter:

Hi John -- If done properly this should work, but if you are connecting to yourself, there are numerous ways to break it. Unfortunately there's not enough information in that thread to give us a good clue what is going on. Check the response code from the fsockopen() call to see if it works.

If Wordpress is ignoring a failure, that would definitely be a Wordpress bug.

Cheers,

Kirsten

On Wed, 20 Jun 2007, 18:40:11 UTC, John Schofield wrote:

I would ask them to give a little more detail, particularly on "if you are connecting to yourself, there are numerous ways to break it". The fsockopen will call your site address/cron.php.

To get the error reported from fsockopen, you need to edit the wp-includes/wp-cron.php file (keep a back up - once you get the error, you will want to restore it to the original state). Look for this:

	} else {
		$argyle = @ fsockopen( $parts['host'], $_SERVER['SERVER_PORT'], $errno, $errstr, 0.01 );
	}

And after that add:

echo $errno."  ".$errstr;

Once you do that, check your front page. It will print out the error number and string. It will also tell you that it cannot modify the header information. You can ignore that part. Once you get the error, reupload your original cron.php file, so your visitors don't get nagged by all that.

[intoxination]

Sorry - the file to edit is wp-includes/cron.php and the file the fsockopen will call is ​http://{yoursite}/wp-cron.php

It has been a long day.

[johnmarkschofield]

Replying to intoxination:

Sorry - the file to edit is wp-includes/cron.php and the file the fsockopen will call is ​http://{yoursite}/wp-cron.php

It has been a long day.

Long here too. {grin} Thanks for your help.

Here's the code, post-edit:

                }
        } else {
                $argyle = @ fsockopen( $parts['host'], $_SERVER['SERVER_PORT'], $errno, $errstr, 0.01 );
        }

        // FIXME: Following line is for testing only; should be removed.
        echo $errno."  ".$errstr;

        if ( $argyle )
                fputs( $argyle,

The only effect of this change seems to be a lower-case "o" in the upper-left hand corner of the site.

This is not much of a problem, so I've left the debug code in place for now. You can go to ​http://blog.sudosu.net and verify for yourself.

I also loaded ​http://blog.sudosu.net/wp-cron.php ; this did make a future post that had been queued appear; I saw no error messages.

[intoxination]

If it's returning 0 then it is connecting. I would ask your hosting company to check the access logs (or you can if you have access) to see if there is a connection to wp-cron.php from your server's IP address.

[JeremyVisser]

This discussion belongs on the ​forums. It's just a shame that you 1337 WP hackers don't hang out there as much. (hint, hint)

[johnmarkschofield]

Replying to intoxination:

If it's returning 0 then it is connecting. I would ask your hosting company to check the access logs (or you can if you have access) to see if there is a connection to wp-cron.php from your server's IP address.

I ran the following command:

''grep wp-cron.php access_log''

All of the lines returned were identical other than the time: (All were from the same IP, which I have blocked out.)

XX.XX.XX.XX - - [19/Jun/2007:21:43:20 -0700] "GET /wp-cron.php HTTP/1.0"
200 0 "-" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4"

(In addition to the unlikely user agent, it's from my home IP address.)

There were no matches for wp-cron.php in error.log.

[intoxination]

Well the socket is connecting to something. Since the address it connects to is from your site_url set in the Wordpress options, that means it is trying to connect to your site. Since the socket isn't returning an error, and your log isn't showing the connection, the problem is definitely within your host's set-up.

I would suggest posting this at ​http://wordpress.org/support/ Perhaps someone there has experienced a similiar problem with their hosting provider and can give you a better direction on getting it fixed.

[Otto42]

Closing as invalid since he was directed to the support forums. Reopen if there's an actual bug to go with this.

[talltree]

I had this problem too while using nearlyfreespeech.net hosting and future posts not working. I made this change to the code and now it works

in /includes/cron.php search for

if ( $argyle ) 
      fputs( $argyle, 
           "GET {$parts['path']}?check=" . wp_hash('187425') . " HTTP/1.0\r\n" 
         . "Host: {$_SERVER['HTTP_HOST']}\r\n\r\n" 
      ); 
}

and replace with

   if ( $argyle ){ 
      fputs( $argyle, 
           "GET {$parts['path']}?check=" . wp_hash('187425') . " HTTP/1.0\r\n" 
         . "Host: {$_SERVER['HTTP_HOST']}\r\n\r\n"   ); 
      fflush($argyle); 
      fgets($argyle); 
      fclose($argyle); 
   } 
}

Thanks

[bransonsparks]

talltree's fix worked for me on NearlyFreeSpeech.net!

[santosj]

Patch has to be actually applied before this can be closed. Just because the fix works, doesn't mean it is in WordPress core.

[santosj]

Actually, that code has been updated to use the new HTTP API. Needs to be tested with latest checkout or WordPress Nightly.

[Otto42]

The change given above (for the old code) basically changes it to do an fflush, fgets, and fclose. The fflush and fgets is useless in this context, it's the fclose that's closing the socket and making all the data get written for certain.

Looking at the new HTTP API, if you're using the fsocket method (instead of one of the other four), then it does an fsockopen, fwrite, and fclose.

So this patch should not be necessary anymore in trunk/2.7 and up.

Might be nice to add the fclose line only into 2.6.1, if it's not too late. If it is too late, I still recommend sticking it into the 2.6 branch for those people using SVN or in case there is a 2.6.2.

But this one is no longer relevant for 2.7 users.

[tbhimdi]

Changing milestone to 2.6.2 since this bug is irrelevant in 2.7.

[evilbeet]

The patch provided by talltree does not resolve the issue for me (hosted on Choopa) or for a lot of the folks over on the support forum. The cron.php code hasn't changed at all since the last time this feature worked (pre-2.5), which leads me to believe the problem lies elsewhere. Is there another patch we can use while we wait on 2.7? And are we certain this issue will be resolved by 2.7?

[jacobsantos]

Replying to evilbeet:

The patch provided by talltree does not resolve the issue for me (hosted on Choopa) or for a lot of the folks over on the support forum. The cron.php code hasn't changed at all since the last time this feature worked (pre-2.5), which leads me to believe the problem lies elsewhere. Is there another patch we can use while we wait on 2.7? And are we certain this issue will be resolved by 2.7?

If the talltree patch worked, then yes, this would be fixed. The HTTP API uses other transports besides fsockopen, so most likely one of those should work for you also. If it doesn't work, then open a new ticket. The issue will have been with the HTTP API and not with wp-cron in that case.

This should be fixed by the HTTP API in 2.7.