Incoming links error message?

Okay, so I noticed this similarity among all the feed validator links posted:

Your feed appears to be encoded as "UTF-8", but your server is reporting "ISO-8859-1"

Could this be the issue? I also read this trac ticket:
https://core.trac.www.ads-software.com/ticket/9689

… which mentions content type checks.

Apparently this issue is affecting all of WordPress.com
https://en.forums.wordpress.com/topic/incoming-links-suddenly-stopped

… since last year.

Nicely spotted! Looks like it’s an intermittent problem with the feed produced by Google.

Try adding this to your theme’s functions.php file:

add_action('wp_feed_options', 'force_feed', 10, 1);
function force_feed($feed) {
	$feed->force_feed(true);
}

Thanks for the effort @esmi.

1. I inserted the code into my child theme functions.php.

2. There was no change, so I went into the database and deleted all _transient entries in the wp_posts table (trying to reforce a cache of the feed).

3. I logged out of the dashboard and back in again.

After the “Incoming Links” widget re-loaded, I received this error:

RSS Error: This XML document is invalid, likely due to invalid
characters. XML error: syntax error at line 1, column 62

Okay, I keep coming back to this encoding message. I honestly think this has something to do with this message:

Your feed appears to be encoded as "UTF-8",
but your server is reporting "ISO-8859-1"

I’ve contacted my server (HostGator), and after putting me on hold for an hour (I think for him to go eat a sandwich), he came back and told me it was most likely a coding error. Thanks?!?!

I was hoping there was a setting I could adjust which would allow me to alter how my server is interpreting that encoding.

I also tried editing the core wp-includes/class-simplepie.php file with various mods, such as:

$feed->set_output_encoding('ISO-8859-1');
$feed->set_input_encoding('ISO-8859-1');

Nothing works. Although I do receive a different error message (mentioned in my last comment).

So, what file is used to render this feed? Perhaps I can go in and manually edit the header content encoding and change it from UTF-8 to ISO-8859-1.

Thanks.

How about asking for force_feed() to be added to core so that it’s used automatically instead? I’ve been told that this would be a valid enhancement. Do you want to add to it to Trac as a feature request or shall I?

Here’s something to consider. I’m seeing the same problem with my “incoming links” feed. The URL validates (and has no links), but when I view it in the browser, there’s a line of CSS after the closing </rss> tag. Odd, but it made me look at trying to “proxy” the call, feeding the feed request through another page that would/could clean the crap out of the feed before passing it along. Not the most elegant solution, but it was an interesting test.

So, I through together a quick CURL page that took the feed off a query parameter, made the call, and just passed the data back (no modifications). What I got back was a CAPTCHA validation request form (coming off Google’s servers), with the following text:

Our systems have detected unusual traffic from your computer network. This page checks to see if it’s really you sending the requests, and not a robot. Why did this happen?

This page appears when Google automatically detects requests coming from your computer network which appear to be in violation of the Terms of Service. The block will expire shortly after those requests stop. In the meantime, solving the above CAPTCHA will let you continue to use our services.

This traffic may have been sent by malicious software, a browser plug-in, or a script that sends automated requests. If you share your network connection, ask your administrator for help — a different computer using the same IP address may be responsible. Learn more

Sometimes you may be asked to solve the CAPTCHA if you are using advanced terms that robots are known to use, or sending requests very quickly.

My working theory is it has nothing to do with WordPress code, or with the URL, but with the IP of the server the call is coming from, and Google’s own protection mechanism has some network blocks (like Dreamhost and Hostgator) tagged for “human intervention required” for some requests.

@ Scott,

Thank you for that. I agree, I do have a lot of trouble with spammers and hackers. I take every defense I know about, however there are still one or two that slip through every once in a while.

@esmi,

Per Scott’s comment above, I’m now not sure it’s a wordpress core problem either.

I’m going to follow Scott’s advice first, and see if I can get it working from my end.

One of the main core devs has suggested that force_feed() should be enabled automatically in the incoming Links widget and it could be added as an enhancement. And that’s not something he often says, so you might want to grab this whilst you can. ??

Thanks esmi.

https://core.trac.www.ads-software.com/ticket/21017

EDIT: I accidentally added it as a bug, instead of feature request. Any way to change that?

Um – not sure. I’ll ask around.

Esmi – thanks for passing on my comments ??

Josh – wanted to reply to your specific issue in here rather than the ticket.

As mentioned, be careful with force_feed, as if a feed is failing it is usually failing for a reason … as you discovered above. (Sorry but for this reason the patch I submitted in the ticket doesn’t enable force_feed here).

Your theory regarding the server IP and Google’s CAPTCHA ring true – previously I’ve only seen this error intermittently and put it down as temporary Google/network issues.

Did you happen to notice the HTTP status code returned in the CURL response header? I can’t reproduce at the moment – the full send/response including headers would be perfect if at all possible.

Looking to add some better error checking to the widget as part of this patch.

@devgav: some of the feeds I checked were effectively valid.

Google IP ban support link for reference. Might be worth filling that in, and hoping they take a look.

A possible work around in your case might be (other than waiting for Google/changing the server IP):

1. Sign up here: https://code.google.com/apis/console
2. Request access to the Google Custom Search API
3. Get your API key from the API Access Menu
4. Use the link below in WP, remembering to put in your API key & domain name.
5. https://www.googleapis.com/customsearch/v1?key=INSERT-YOUR-KEY&cx=017576662512468239146:omuauf_lfve&alt=atom&q=link:https://joshlobe.com/

Beware: The standard RSS feed from Google uses Google Blog Search to return only blog results. This feed uses standard Google Search, so returns all sites linking to your blog.

Without diving into the docs don’t know if it’s possible to filter this further I’m afraid, but do let me know if you find a way! ??

Interestingly, running this locally on my Windows machine throws an SSL cert errors. Try this advice if you see that: https://code.google.com/p/google-api-php-client/issues/detail?id=22

Finally – it will be worth running a check of all websites running on your servers IP, to make sure there is no malware/unwanted PHP code lying around hitting Google’s servers. Server logs can help a lot with this if setup correctly and your server – otherwise any good host should be willing to help.