I recently upgraded to WordPress 2.7 and ever since I did my scheduled posts no longer work. I will schedule a post and then I will check it after it was set to go up and it will just say “Missed Schedule.”
I am with HostGater, and I emailed them about it but after going back and fourth for a day they just pointed me over here. The server I am on meets all of the requirements etc…
Is there a fix for this? Is anyone else having the same problem?
In other threads, MichaelH writes:
See if this helps:
Please let us know if that does (or does not) work for you. Thank you.
No that did not work for me. I have only had http://rpc.pingomatic.com/ in the Update Services since we started.
I still have any scheduled posts going past their due date/time and showing as Missed Schedule.
Can you advise any further ?
I have ~15 very fast ping sites in my list. I am not willing to delete any of them on my main sites as a huge drop in traffic will result. This missed posts issue was plaguing a few of my blogs where all I have is pingomatic (have not built a customized list for those yet) so this is not the whole problem.
However, while this COULD be part of the issue (See http://trac.wordpress.org/ticket/8923) its still poor implementation on the WP side of things. A timeout of 0.01 seconds for cron is just silly. Like was suggested in that ticket, someone needs to take a step back and re-evaluate how stuff is being done behind the scenes.
So what it comes down to is we have all these hacks in place which seem to be VERY temperamental and HEAVILY dependent on the server environment allowing non-standard things (like a server being able to talk to itself) so people don’t have to set a cron job on the server?
No, that’s not correct at all. A normal, correctly configured, server can talk to itself just fine. It’s only when you start doing strange and weird things like not having DNS setup properly or blocking loopback connections that you cause problems.
A stock Red Hat Enterprise web server works perfectly, as does every other Linux server system I’ve ever configured. As long as you don’t break it intentionally in some way, of course. The problem is that a lot of poor server admins tend to break things like loopback because they think that it improves security in some way. It doesn’t, and all the guides telling you to do stuff like that are wrong.
So adding wp-cron.php to the cron cycle will take care of the scheduling issue? Is that what I am hearing?
No. wp-cron has a block on it to prevent hits from anybody except the same WordPress installation as it’s using. This is to prevent denial of service attacks. What you need to do is to figure out why your php setup is unable to make an http connection back to itself. When you’ve worked that out, then the problem will go away.
Well, loopback is disabled for security purposes. Allowing a server to talk to itself is a really bad idea. First off, there is no need to have a server talk to itself. The first rule of security is have as few doors into the system as possible. Less entry points means fewer places bad guys and their tools can break in. There is a reason why most bank vaults do not have a window and only one door in and out.
The only reason a server has to talk to itself is lazy software developers who want to use hacks to get around the proper way of doing things. I.e. instead of setting up a server cron job, we have WP kick itself in the butt to go and do things.
The same developers will always be the first ones to blame problems on host machines, because properly configured, secure servers (and that’s the only time a server is properly configured is when its secure, anything else is wrong regardless of how many people do it) are the exception rather than the rule. Shared hosting places leave all kinds of crap turned on to maintain maximum compatibility (at the expense of security) with poorly made software (take phpBB for example, a wonderful example of how NOT to design software) which encourages developers to continue their habits of releasing crap and blaming the few users who do know what is going on for problems that in actuality started on the other side of the table.
I am not going to put the entire network at risk to run WordPress, I’d rather get rid of WordPress first. For this same reason, I refuse to run Zend optimizer because Zend allows scripts to run without me being able to see what they are doing. Of course, the developers keep telling me thats so people cant steal their programs. Unacceptable. I don’t give out root keys to anyone who wants to make sure that their software isn’t being stolen, so why would I allow software to run in protected memory space? Some software requires it, so I simply wont use it. As much of a pain in my rectum as it would be to ditch WordPress at this late stage, that may be what ends up having to happen.
But I would like to avoid it. Wouldn’t it be possible to use a cron job on this to somehow fix the problem? I.e. take wp-cron, modify it to remove the block, hide it somewhere below the public directory so that no one can DoS it and have a cron job call it every few 10 minutes or so? I.e. do this the right way instead of doing it the “lets maintain compatibility with everyone’s wide open as the grand canyon shared hosting company” way?
That is ridiculous. If you want to set up cron jobs then do it. WP is set up to allow users to schedule tasks without having to use cron. A LOT of modern cms-type server software have similar ability. Cron jobs are much more complicated, and a lot of WP users would not be able to do it. WP allows users of any level to be able to have cron-like ability in their blog. Pretty awesome.
If you are such an amazing webmaster who needs things so severely secure, then set up your own cron jobs and stop complaining.
For the rest of us, wp cron works great unless a server is not set correctly (or is extremely secure as in your case i guess). If you would close your trap for a second, maybe some of the people here who need help troubleshooting their server issues could actually get it.
It isn’t lazy developers or bad development, quite the opposite.
I am really confident this is about the new script. The 2.7 version.
I being into scheduling my post since WP2.5 and 2.6 . It worked ok to me. And I guess to most of you also.
But, since upgraded, the scheduled post, never meet the time. It is always miss scheduled.
I really think it is not about the host since, most of hosting face the same thing.
If you taking about coding there and here, I dont think it can help our non-geek friends.
Make sure your Timezone is correct also under O”Settings > General”.
@ jcow – I’ll ‘shut my trap’ (as you so eloquently put it) when the issue gets fixed. I’m sorry, no one informed me that this forum was only for people who agreed with and praised every direction WP goes in. I missed that memo. But thank you oh so much for clearing that up.
So if I remove the block from wp-cron.php, move it somewhere and/or rename it and have a sever cron process call it, it will work? Are there any problems with that implementation that anyone can see? I.e. is there anything that looks for it to be there that will complain when its not there?
I have this same problem and I made a simple plugin: WordPress Scheduled MIAs. It’s a fix for this problem untill WP fixes it themselves.
It’s a fix for this problem untill WP fixes it themselves.
There’s not going to be a fix for a problem with somebody’s server. We can’t fix a problem that is caused by the server configuration explicitly blocking what is trying to be done.
Well, loopback is disabled for security purposes. Allowing a server to talk to itself is a really bad idea.
False. This is not only not security, it’s worse in that it is *pretend* security. If you disagree, then please, by all means, explain exactly what “exploits” this sort of thing prevents.
I do know real server security, BTW, as that sort of thing is what I do for a living, so don’t feel the need to dumb it down.
First off, there is no need to have a server talk to itself.
WordPress makes a call back to itself for an explicit reason: to run the wp-cron in a separate server process, so as not to cause a long delay for the user when those long processes are running.
So if I remove the block from wp-cron.php, move it somewhere and/or rename it and have a sever cron process call it, it will work?
Yes, if you want to do it that way. It’s inefficient and wasteful, since you’ll be needlessly running wp-cron on a timed schedule instead of on an “as needed” basis, but it would certainly work.
The advantage to letting wp-cron the way it was intended to work is that it doesn’t run on a schedule, it only runs when it is needed. The schedule is dynamic instead of fixed to 10-minute intervals.
Also, that “block” is there for a reason. Removing it is a potential security problem, in that it allows the potential for a DOS attack on your site. You can mitigate this by making a copy of wp-cron, renaming it to something else, and modifying that one instead.
The block, BTW, are these lines:
if ( $_GET['check'] != wp_hash('187425') ) exit;
Remove those and then you can call it from a normal cron process.
@otto42: I have a different problem as you can see in my blog post.
I think future posts should not need to be scheduled for publishing. A simple SQL query could show posts with past dates and future status and publish them … in WP core. I don’t know …
I just meant to make sure that you have selected the timezone that you are posting in. If it is set for a different timezone, the posts would get posted in that timezone’s time. It might not be your problem, I just wanted to eliminate variables.
Example: If you are in New York, but your timezone is set for Pacific time, your posts would get posted 3 hours late.
I’m sorry, no one informed me that this forum was only for people who agreed with and praised every direction WP goes in.
I, of course, never said that. The problem is that you are coming in to defend your special server configuration, and say that WP is wrong to design for the most basic, common server config. If you are unwilling to allow WP to work correctly, then use a work-around, but it would be useful if you would allow people who are willing to accept support to get it, instead of writing dissertations on how much you don’t like the WP setup because it doesn’t work on your special server.
- The topic ‘Missed Schedule – Scheduled Posts Not Publishing With 2.7’ is closed to new replies.