WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

#3742 closed defect (bug) (fixed)

Future dated posts not publishing

Reported by: fleety Owned by:
Milestone: 2.7 Priority: normal
Severity: normal Version: 2.5
Component: Administration Keywords:
Focuses: Cc:

Description

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

Change History (54)

comment:1 fleety7 years ago

  • Milestone 2.3 deleted

comment:2 ryan7 years ago

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.

comment:3 ryan7 years ago

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

comment:4 foolswisdom7 years ago

  • Milestone set to 2.2

comment:5 fleety7 years ago

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

Thanks for the suggestion. Anything else?

comment:6 ryan7 years ago

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

comment:7 gMk7 years ago

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

comment:8 foolswisdom7 years ago

  • Milestone changed from 2.2 to 2.4

comment:9 johnmarkschofield7 years ago

  • Milestone 2.4 (future) deleted
  • Version changed from 2.1 to 2.2

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.

comment:10 Nazgul7 years ago

  • Milestone set to 2.4 (future)

comment:11 johnmarkschofield7 years ago

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.

comment:12 follow-up: Otto427 years ago

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?

comment:13 follow-up: Otto427 years ago

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.

comment:14 in reply to: ↑ 13 foolswisdom7 years ago

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.

comment:15 in reply to: ↑ 12 ; follow-up: johnmarkschofield7 years ago

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!

comment:16 follow-up: Otto427 years ago

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.

comment:17 in reply to: ↑ 15 intoxination7 years ago

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!

comment:18 follow-ups: intoxination7 years ago

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.

comment:19 in reply to: ↑ 16 johnmarkschofield7 years ago

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;}

comment:20 in reply to: ↑ 18 johnmarkschofield7 years ago

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]$

comment:21 in reply to: ↑ 18 johnmarkschofield7 years ago

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.

comment:22 johnmarkschofield7 years ago

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.

comment:23 follow-up: intoxination7 years ago

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).

comment:24 in reply to: ↑ 23 johnmarkschofield7 years ago

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?

comment:25 follow-up: intoxination7 years ago

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

comment:26 in reply to: ↑ 25 johnmarkschofield7 years ago

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

comment:27 intoxination7 years ago

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.

comment:28 Otto427 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

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.

comment:29 johnmarkschofield7 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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.

comment:30 follow-up: intoxination7 years ago

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

comment:31 follow-up: Otto427 years ago

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.
  1. 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.

comment:32 in reply to: ↑ 30 johnmarkschofield7 years ago

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.

comment:33 follow-up: johnmarkschofield7 years ago

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!

comment:34 in reply to: ↑ 31 johnmarkschofield7 years ago

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

  1. 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.

comment:35 johnmarkschofield7 years ago

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}

comment:36 in reply to: ↑ 33 intoxination7 years ago

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.

comment:37 follow-up: intoxination7 years ago

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.

comment:38 in reply to: ↑ 37 johnmarkschofield7 years ago

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.

comment:39 follow-up: intoxination7 years ago

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.

comment:40 JeremyVisser7 years ago

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)

comment:41 in reply to: ↑ 39 johnmarkschofield7 years ago

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.

comment:42 intoxination7 years ago

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.

comment:43 Otto427 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

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

comment:44 Nazgul7 years ago

  • Milestone 2.4 (future) deleted

comment:45 in reply to: ↑ description talltree6 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 2.2 to 2.5

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

comment:46 DD326 years ago

  • Milestone set to 2.7

comment:47 bransonsparks6 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

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

comment:48 santosj6 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:49 santosj6 years ago

  • Keywords tested needs-patch added; future dated posts removed

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

comment:50 santosj6 years ago

  • Keywords tested removed

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

comment:51 Otto426 years ago

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.

comment:52 tbhimdi6 years ago

  • Milestone changed from 2.7 to 2.6.2

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

comment:53 follow-up: evilbeet6 years ago

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?

comment:54 in reply to: ↑ 53 jacobsantos6 years ago

  • Keywords needs-patch removed
  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.