[wp-hackers] Trackbacks staying in post.to_ping

Otto otto at ottodestruct.com
Wed Sep 3 15:16:10 GMT 2008

If by "the scheduler", you're talking about wp-cron, then how that
works is somewhat trickier.

-On every page view, the wp_cron function is triggered (by this
add_action('init', 'wp_cron') ).
-The wp_cron function checks the cron option in the options table to
see if there's any scheduled tasks. If there are, it calls
-spawn_cron does an http hit to get_option( 'siteurl' ) .
'/wp-cron.php?check=' . wp_hash('187425'). This is basically hitting
back on itself to activate the wp-cron.php script in a separate

Now, this is usually the failure point. For whatever reason, a
surprising amount of webservers are not configured to be able to
resolve their own addresses, or they have some kind of routing issue
with hitting themselves this way, or there's a security rule blocking
it, or one of half a dozen other things. So that's the first thing to
check, you want to write some code that does an http get on the same
server as the code is on. If that fails, then this is your main
problem and you need to figure out why it's failing.

When wp-cron.php is run, it checks that hash value (this is to prevent
other systems from hitting wp-cron, since the hash will be unique to
your system, as it's salted with the secret key), then gets the cron
jobs from the database and runs them. Wp-cron jobs are basically
action hooks that plugins and other core code hooks onto. In this
case, the action hook is "do_pings" and the function that gets called
is "do_all_pings".


On Wed, Sep 3, 2008 at 9:41 AM, Max Deputter <max at awakers.com> wrote:
> @fflush($fs); worked as a good replacement for fread() and it's smarter as
> well.
> Now that's part 2 of the problem being fixed but that part one is that the
> scheduler does not seem to run correctly. When do_all_ping() ran manually,
> it moved to_ping to pinged even if the socket closed before the buffer
> flushed. Now that the socket issue is fixed, I'm not sure what to do about
> the scheduler. I thought about running a crontab on my 2 line script to ping
> trackbacks every 5 mins but I'd like to minimize the modifications on the
> core files. Any ideas on how I can debug the scheduler? I did not reverse
> its code yet but I'm guessing, that since it's not using crontab, it must be
> answering to a trigger (like page views). I'll reverse the code tomorrow to
> understand it better but in the meantime, if any of you have any ideas, by
> all mean let me know. by the way, this is a fresh install of WP2.6 without
> any modifications what so ever.
> Max
> Otto wrote:
>> I've seen this issue in other circumstances as well. If you do an
>> fsockopen, an fputs, and then an fclose, sometimes the fclose doesn't
>> flush the thing and your request never gets sent. Adding an fread or
>> better yet an fflush forces it to actually send the data and work.
>> In the trackback() function, find this code:
>> $fs = @fsockopen($trackback_url['host'], $trackback_url['port'],
>> $errno, $errstr, 4);
>> @fputs($fs, $http_request);
>> @fclose($fs);
>> Between the fputs and the fclose, add this line:
>> @fflush($fs);
>> I'll bet it'll work properly then.
>> In 2.7, the trackback and ping functions need to be modified to use
>> the new http class instead of manually using sockets and such. I'll
>> bring it up on trac somewhere.
>> On Wed, Sep 3, 2008 at 2:24 AM, Max Deputter <max at awakers.com> wrote:
>>> Dear WordPress hackers, I have the weirdest problem. My trackbacks stay
>>> in
>>> the to_ping column. But if I hack in a bit, I can launch them. The move
>>> to
>>> the pinged column but did not really ping. When I modify the code a bit,
>>> it
>>> works. But they still stay in to_ping for new posts. Here's my path so
>>> far.
>>> Everytime I submit a post with a trackback, it stays in to_post. I looked
>>> in
>>> the code and it seems there's some kind of scheduled
>>> wp_schedule_single_event that triggers a general ping fest when there's a
>>> blog post. My earliest to_ping dates from 2008-08-11 08:30:42...
>>> I made a test.php file with the following content:
>>> <?php
>>> require_once("wp-load.php");
>>> do_all_pings();
>>> ?>
>>> Then I modified wp-include/comment.php to add some debug info that will
>>> show
>>> up on the shell as I run my test.php script:
>>>      print "I opened to " . $trackback_url['host'] . " with port " .
>>> $trackback_url['port'] . "\n";
>>>      if(!$fs) print "FS Did not succeed\n";
>>>      fputs($fs, $http_request);
>>>      print "I put: $http_request\n";
>>> Now I can see what is being outputted and I give it a shot with
>>> telnetting
>>> directly to a test blog I created on wordpress.com
>>> (awakers.wordpress.com)
>>> and surprise, it works with telnet but it did not work with the php code.
>>> I
>>> also notice that I got <error>0</error> so deduct that I should see the
>>> error message if I get wordpress' answer via code. I add the following
>>> two
>>> lines to comment.php
>>>      $res = fread($fs,8192);
>>>      print "Response:\n$res**************\n";
>>> I am eagerly waiting to see finally what is holding my blog fury back.
>>> Response:
>>> HTTP/1.1 200 OK
>>> Server: nginx
>>> Date: Wed, 03 Sep 2008 06:50:13 GMT
>>> Content-Type: text/xml; charset=UTF-8
>>> Connection: close
>>> X-hacker: If you're reading this, you should visit automattic.com/jobs
>>> and
>>> apply to join the fun, mention this header.
>>> X-Pingback: http://awakers.wordpress.com/xmlrpc.php
>>> Content-Length: 78
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <response>
>>> <error>0</error>
>>> </response>**************
>>> What?!? I check on the blog and believe it or not, the trackback request
>>> is
>>> there. I make another trackback, remove the fread code and it doesn't
>>> work.
>>> At this point, I assume that closing the socket without reading some of
>>> it
>>> kills the trackback.
>>> So that's where I stand now. The do_all_pings scheduled does not run and
>>> when I run things manually, it needs to read from the socket after it
>>> puts
>>> to it.
>>> Here's some info about my setup that might or might not be relevant:
>>> Running CPanel on Centos5.2 under a VMware ESXi server
>>> The ip of the machine is and I'm natting traffic in and out on
>>> required ports 80,443 etc
>>> The router is OpenBSD's PF.
>>> Regards,
>>> Max
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list