No Longer Pinging Update Services after 1.5.1

…any luck with the trackbacks?

I’ve sent pingbacks succcessfully, and have sent and received trackbacks, but rpc.pingomatic.com seems to be dropping the ball; other services are responding when I explicitly ping them through Update Services.

You’re right, Kafkaesqu?-, it looks like Ping-o-Matic is the only one not functioning correctly.

Haven’t noticed any change in the pings PoM has been receiving, could you be more specific?

When I post (with ping-o-matic in the update services), none of ping-o-matic’s services are notified. However, If I post with all of ping-o-matic’s services entered separately into the update services field, they are successfully notified.

As for an update on my continuing trials with trackback and pingback, see: https://www.ads-software.com/support/topic/33208#post-187980

I should also add that my server error logs have been completely blank all day.

Ok, I’ve tried every troubleshooting step that I know of, so I’ve decided to submit the bug. Details and bug report here: https://mosquito.www.ads-software.com/view.php?id=1325

Update: I tried another test post and can see (via ping-o-matic’s 100 recent pings list) that I have successfully pinged ping-o-matic. But, none of the external services are showing that they have been updated as a result of the ping-o-matic ping. Perhaps this is a problem on ping-o-matic’s end.

Update: I’m having the same problems with a brand-new fresh WP v1.5.1 installation.

Trackbacks don’t seem to be working for me. I pinged the Dev Blog after I posted the upgrade news and although my Admin Panel says I successfully pinged, nothing is showing up on the Dev Blog.

I solved my pingback problem. Those looking to use up 30 minutes following a guide that literally makes no sense, proceed here: https://www.ads-software.com/support/topic/33208#post-188089

My ping-o-matic problem unfortunately remains.

Did you check and make sure that class-IXR.php in wp-includes
still has the IXR in uppercase? It seems to be the only file in wp
that uses upper case and I had a problem cause (like a dummy) I
forgot to switch off “force lower case” in my ftp client.

If functions.php can’t access class-IXR.php there won’t be any
IXR_client to send to pingomatic.

I just checked and it’s still uppercase “class-IXR.php”. Nonetheless, thanks for your response.

I think this is a ping-o-matic issue. My pings are reaching ping-o-matic, but they arena€?t being routed to any of the external update services.

Scratch that, I had no problems with a fresh WP v1.5.0 installation. This appears to be a problem with WP v1.5.1.

More info from my error logs:

[10-May-2005 10:43:30] PHP Warning: fclose(): supplied argument is not a valid stream resource in /****/******/*****/wordpress/xmlrpc.php on line 1189
[10-May-2005 10:43:30] PHP Warning: Cannot modify header information - headers already sent by (output started at /****/******/*****/wordpress/xmlrpc.php:1189) in /****/******/*****/wordpress/wp-includes/class-IXR.php on line 371
[10-May-2005 10:43:30] PHP Warning: Cannot modify header information - headers already sent by (output started at /****/******/*****/wordpress/xmlrpc.php:1189) in /****/******/*****/wordpress/wp-includes/class-IXR.php on line 372
[10-May-2005 10:43:30] PHP Warning: Cannot modify header information - headers already sent by (output started at /****/******/*****/wordpress/xmlrpc.php:1189) in /****/******/*****/wordpress/wp-includes/class-IXR.php on line 373
[10-May-2005 10:43:30] PHP Warning: Cannot modify header information - headers already sent by (output started at /****/******/*****/wordpress/xmlrpc.php:1189) in /****/******/*****/wordpress/wp-includes/class-IXR.php on line 374

The “headers already sent” errors appear to be caused by the “supplied argument is not a valid stream resource” error.

This is just getting weirder and weirder….

A recent test with the unedited xmlrpc file did not work (as predicted) and produced no errors in error log (argh). A recent test the edited xmlrpc file (I removed fclose($fp); from line 1189) also did not work, and also did not produce any errors in the error log.