Inbound Pingbacks Not Working

It would be useful to see what message comes back from your site when it receives a pingback request. We can simulate a pingback request sent to your site by using cUrl to send a small file with the necessary data. If your computer does not have curl command available from the command prompt or terminal window, you can install it. It’s native to ‘nix machines and recent Win 10 machines.

To build the data file, create an empty text file named pingback.xml. It’s easiest if it is placed in the folder from where you run the curl command so you don’t need to fuss with paths.

Place this content in the file:

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
 <param>
  <value>
   <!-- source -->
   <string>https://example.com/post-referring-to-your-post/</string>
  </value>
 </param>
 <param>
  <value>
   <!-- target -->
   <string>https://your-site.com/post-referred-to/</string>
  </value>
 </param>
</params>
</methodCall>

Edit the URLs to reflect true links to posts. The source cannot be your site and the linked post must contain a link to your site’s post. The target must be the post linked to in the source post. Save the edited file.

Run this command:
curl -X POST -d @pingback.xml https://your-site.com/xmlrpc.php
except use the correct URL for your site.

Your site should respond with an XML error message. All we’re interested in is the values after “faultCode” and “faultString”.

Thanks for your response bcworks!

I don’t know whether the Siteground crew fixed something silently in the background after all, or whether somehow my theme *was* blocking them, but I successfully received a pingback yesterday after changing my theme. (Was Genesis Framework + Magazine Pro, now OceanWP)

I still struggle to see how it might’ve been the theme, as the pingback ‘comment’ itself was not being generated fullstop, it wasn’t just a display issue.

Even so, out of curiosity about whether I might be able to use this script to ‘repair’ some of the missed pingbacks in the past, I took it for a spin.

No error codes were generated, but neither was the pingback. Should I expect it to? The target post still has comments open, the source post is definitely doing a direct link to the post rather than via reader, short link or anything else.

Although possibly I’m making an assumption I shouldn’t — FaultCode is returning 0 as an integer. I assume that means no error, but that might be wrong. FaultString is returning an empty string.

FaultCode 0 is still an error. It’s akin to functions returning false on failure. If the pingback were successful, you would not get FaultCode or FaultString messages, you get “Pingback from {$source} to {$target} registered. Keep the web talking! :-)”. Fault code 0 and empty fault string means the request was rejected due to other problems beyond what WP screens for, such as if a link to the target post really exists at the source post.

I did see the same 0 fault empty string response when I was testing pingbacks a while back. Turns out the target site had .htaccess security rules preventing external access to xmlrpc.php, so WP never got a chance to provide a fault code or string. Since WP tries to tell us what went wrong, I suspect the lack of information means the fault is due to something external to WP. .htaccess can be one source, but other security measures could be the cause as well.

Incidentally, you cannot test this on localhost sites, even if the two sites can otherwise talk to each other through different virtual hosts. WP sees that the hosts resolve to a local IP and rejects the transaction.

Themes shouldn’t impact pingbacks, but since they can hook into core code, they could pretty much impact anything if the author felt so inclined.

That’s curious that you did get a pingback from elsewhere but sending that XML fails. I have used it to successfully add pingback comments, it does work. It’s harder to say why it would fail, especially when there is no fault message.

To debug pingbacks in detail, temporarily add error_log() calls to applicable source code to check various intermediate variables. Start on xmlrpc.php. Execution continues in wp_xmlrpc_server::pingback_ping()