WordPress RSS feed broken

Hi there,

I’m checking with our developers to see if it’s possible to have that option unchecked by default. I’ll get back with you as soon as possible.

The AddThis placeholder divs are normally added to each of your pages/posts once the plugin is activated, even if the “Show AddThis sharing buttons” box is unchecked.

Can you let us know what HTML is causing the issue with the description elements in your feed? If you uncheck the “Show AddThis sharing buttons” box, are you seeing that it resolves the issue?

Thanks for looking into this. Yes, after the recent update, the placeholder divs were added to all posts. When we deselect the Show box, they do not appear in the feed. It is these divs that are causing issues with XSL style sheets that is applied when the feed in rendered on another site. The placeholder divs break the HTML structure and layout of the page on which the feed is rendered. We can uncheck boxes on posts, but as we have hundreds of posts, this would be too time consuming.

On related note, we have the Addthis code in our page templates, we don’t need to add this code to the top of all pages and posts as well. If we can turn this off globally somehow that would be appreciated.

Thanks for the information. Typically, there’s not a way to have the checkbox set to not show the buttons by default. I’m consulting with our developers to see what the best approach would be and will get back with you as soon as possible.

Much appreciated! And thanks for the quick responses.

Our developers are requesting additional information about the feed feature that you’re using. Are you using the WordPress feed feature or another plugin for the feed? Any additional information about how the feed is generated is helpful. Thanks!

Sure thing, we’re using the built-in feed feature for a category. So, like this:

https://www.example.com/category/categoryname/feed

Further to this, we just updated to Version 4.0.5 and now have another issue. After updating, our UTF-8 feed no longer validates due to invalid characters in the feed:

error on line 30 at column 25: Input is not proper UTF-8, indicate encoding !
Bytes: 0x06 0x05 0x07

We traced this down to 3 invisible ascii characters being added to the beginning of the <description> element. See Bytes above – you can look them up. In IE, view-source, we could view them and they look like a hyphen, pipe and bullet.

Luckily we caught this in our Dev environment. We won’t be able to update Production until a fix is found.

Any help is much appreciated!

I can corroborate what sevensoutbill says above. We had to troubleshoot why our WordPress feeds weren’t working today, and there are three ASCII characters that are included in the <description> tag of our RSS feeds generated by WordPress when the latest version of the AddThis plugin is activated. (We probably didn’t notice the broken feeds when the plugin was first updated a couple of days back).

Important: Actually, it’s not really the RSS that’s the problem – these ASCII characters are being injected into the post source code, so it’s just that the RSS is breaking because the source code itself is bad from whatever AddThis is adding.

We’re seeing this in any page/post that has summaries/excerpts while AddThis is activated. What happens is that in the summary/excerpt, the first <p> tag gets three ASCII control characters after it, the ACK ENQ and BEL character codes. You can plainly see them when looking at the code in a text editor.

sevensoutbill: Find a page of yours (like a category page) that has excerpts or summaries. Copy the page’s source code into a text editor. See if you don’t see those ASCII characters right there in the source code after the first <p> tag like we’re seeing with AddThis activated. Once we deactivate AddThis, those ACK ENQ and BEL characters that immediately follow the <p> tag go away and the code looks clean (and hence, the feeds work again).

Just looking around at the AddThis code, and it appears these ASCII control characters are intentional (although I’m sure not where they are ending up, lol). There are references to these control codes in at least one of the AddThis PHP files and at least one AddThis Javascript file.

Here’s a code excerpt from the “add-divs-to-coded-excerpts.js” file:

/**
 * Queries window.document for a 3-letter non-printing code
 *   The order of the code identifies a type of excerpt (archive, category, etc).
 *   Inserts sharetoolbox and recommendedbox divs on either side of the excerpt.
 *
 * @alters window.document
 */
function addDivsToCodedExcerpts() {
    var excerptNodes = getDocumentNodesWithCode();
    for(var i=0; i<excerptNodes.length; i++) {
        var excerptNode = excerptNodes[i];
        var excerptCode = excerptNode.data.substring(0,3);
        var suffix = "";

        if(excerptCode === String.fromCharCode(5,6,7)) {
            suffix = "-homepage";
        } else if(excerptCode === String.fromCharCode(5,7,6)) {
            suffix = "-page";
        } else if(excerptCode === String.fromCharCode(6,7,5)) {
            suffix = "";
        } else if(excerptCode === String.fromCharCode(6,5,7)) {
            suffix = "-cat-page";
        } else if(excerptCode === String.fromCharCode(7,5,6)) {
            suffix = "-arch-page";
        }

That’s not the complete function – just showing some of it to show the ASCII codes 5, 6, and 7 are used to identify and alter with surrounding divs various types of WP page excerpts.

AddThis: I don’t know if this matters, but just poking around your add-divs-to-coded-excerpts.js code, I see that you’re doing a regular expression match search on line 15 where you explicitly list the repetition by using the {3} parameter.

Code: if(data && data.match && data.match(/[05-07]{3}/g))

However (and again, I don’t know that this actually matters or not) later you don’t specify a repetition when you’re replacing those character codes with empty strings on line 72:

Code: excerptNode.data = excerptNode.data.replace(/[05-07]/g, "");

Thanks for all of the information! I’m working with our developers on this issue and we’ll get a fix out for this as soon as we can.

Hi everyone!

Our developers just pushed out a new version of our plugin (4.0.6), which we believe will fix the issue with the feeds. If one of you could try upgrading to that version and let us know whether or not it fixes the issue, we’d appreciate it!

Thanks,
Matt

Hey Matt – Thanks for the quick response. We upgraded, but see no change in the problem with the RSS feeds – same hidden ascii characters remain. One change we did notice is that now in the source on our category pages we’re seeing the previously invisible characters as this: -+*

Correction! After clearing temp files/cache..doh! Feeds are now valid – thanks! There are still the three new characters present in the except content but they are not interfering with the feed validation/parsing and they don’t seem to appear anywhere on the front side. Still need to test and see how our published feeds render on other sites before going to production, but looks good so far.