WordPress.com blog or a self-hosted ww.wp.xz.cn install?
If you need help with wordpress.com, you need to go there and post in their forusm. This site is for self-hosted WordPress installs only.
Thread Starter
hcvst
(@hcvst)
Hi Ipstenu,
thanks for your reply. I have the issue with any hosted WordPress installation (wordpress.com, name.com) however not with the one that sits on the same server as my custom blog. If you have a self-hosted install perhaps I could try to ping one of your posts to see whether the same error occurs, please 🙂
I was hoping to find a wordpress developer here – sorry if I posed in the wrong place. The file in question is xmlrpc.php and possibly line 3259 ‘$linea = apply_filters(‘pre_remote_source’, $linea, $pagelinkedto);’
I don’t have another server to test this with but if nothing else helps I’ll get an Amazon instance for a day and deploy WP there and try to debug.
Best regards,
HC
I have pingbacks turned off on all my stuff, actually.
I suspect it’s probably just not working on wordpress.com sites (which are different from self-hosted in many levels). You could try posting about it in http://core.trac.ww.wp.xz.cn/ though that’s really not the place for support per sey….
I would get a second server (or someone who has one) and test against that to see if it works on self-hosteds on other servers.
I’ve been working on a plugin that works with pingbacks, and you were close, I tested the line you mentioned, but the problem seems to be with the line in class-wp-xmlrpc-server.php which uses strip_tags.
(line 3422 in WP 3.1):
$linea = strip_tags( $linea, '<a>' ); // just keep the tag we need
For some reason this function is not working properly at all on some templates (or that is the way it seems) and instead of returning all the <a> tags is cutting a lot of them out, making it seem to the server like there is no target link in the source URI.
Unfortunately, even if this were fixed in WordPress in the future, pinging servers with old versions without the fix is still going to give you the same old error. but the good new is..
I have included a workaround in my new plugin:
http://ww.wp.xz.cn/extend/plugins/pingchecker/
Basically it does a regex match for links in your content, then echoes them in a hidden div in the footer, making it much easier for the strip_tags function to actually find them.
…am off to post this as a bug in the appropriate forum, hopefully then it will be fixed for future versions of WordPress at the source.
🙂
Thread Starter
hcvst
(@hcvst)
Thanks majick777. Good timing too, just deployed another blog and started to see Fault 17 again 🙂 Any idea which anchor tags get picked up and which don’t? Do they need a newline following them for example – or something similar that could be fixed in my blog posts?
HC
It’s pretty hard to tell why some are actually getting picked and which ones stripped without testing a particular page. I don’t think newlines are going to help, it’s just going to strip them anyway.. From what I could tell it is influenced by different templates and plugins adding code, the main site I was testing on it seemed to be all the plugins adding javascript code to the header that confused the hell out of strip_tags. You could always run something like this as a test with a php file (run it from anywhere really), but I’d still recommend the plugin just in case…
<?php $linea = file_get_contents('http://yourblog.com/yourpage/'); $linea = str_replace('<!DOC','<DOC',$linea);$linea = preg_replace('/[\s\r\n\t]+/', ' ', $linea); $linea = preg_replace( "/ <(h1|h2|h3|h4|h5|h6|p|th|td|li|dt|dd|pre|caption|input|textarea|button|body)[^>]*>/","\n\n",$linea); $linea = strip_tags($linea,'<a>'); echo $linea; ?>
…which basically just replicates the output that the xmlrpc server class checks for valid href tags. if you see valid links outputted, they are the ones that are showing up. in my case, I am getting a whole bunch of chopped up javascript at the top, then my menu links but no post content links, and then with the new plugin the content links show up at the bottom now.
🙂 so I’m happy with that.
Just another note, it was definitely some code in my header causing the main problems, some javascript and some style code added by some plugins. Moving it to the footer seemed to make a difference to running the above test code. 🙂
