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.
