Cameron

We’re still having problems too which makes me think that wp-super-cache might not have been (entirely) at fault. I’m contemplating trying to debug the ajax call next. :/

To the plugin Author, I would suggest the following:

1. Provide a direct link from the plugin on the installed plugins page to the */wp-admin/options-general.php?page=easy-instagram page. I was unaware of this page at first and we’ve used other plugins (Akismet for one) that do this.
2. Provide a clearer message than “folder */easy-instagram/cache is not writable”. A non-existant folder should be easy enough to detect and report back through the admin.

I encountered the same issue on another site. I think it’s a caching issue. We also use WP-Super-Cache for managing caching of our entire site so I’m not 100% certian yet which is at fault. Whenever I force flush WP-Super-Cache, our instagram feed comes back. If I figure it out, I’ll post an update.

ok… hopefully this helps some people.

In my case, it appears that the error message that fetch_feed()/SimplePie spits back to the plugin is wrong. I found and used this validator on the URL the plugin generates: http://validator.w3.org/

This was the output:

Line 91, Column 2644: non SGML character number 25
…health, safety or efficacy claims, itâs also brought the potential for a retu…

You have used an illegal character in your text. HTML uses the standard UNICODE Consortium character repertoire, and it leaves undefined (among others) 65 character codes (0 to 31 inclusive and 127 to 159 inclusive) that are sometimes used for typographical quote marks and similar in proprietary character sets. The validator has found one of these undefined characters in your document. The character may appear on your browser as a curly quote, or a trademark symbol, or some other fancy glyph; on a different computer, however, it will likely appear as a completely different character, or nothing at all.

Your best bet is to replace the character with the nearest equivalent ASCII character, or to use an appropriate character entity. For more information on Character Encoding on the web, see Alan Flavell’s excellent HTML Character Set Issues reference.

This error can also be triggered by formatting characters embedded in documents by some word processors. If you use a word processor to edit your HTML documents, be sure to use the “Save as ASCII” or similar command to save the document without formatting information.

This illegal character wasn’t in my client’s FB post, it appears to be in the article they linked to. I tried digging deeper into fetch_feed and SimplePie, regarding how these parse the XML document from FaceBook, but there doesn’t appear to be a quick/easy solution there.

I’m not sure what can be done within the plugin to cope with this parsing error from wordpress core. It seems like fetch_feed/SimplePie have to parse the entire XML document just so the plugin can pull the X most recent posts, so even if a problematic post falls outside of the first X entries, it can still foul up the plugin.

This is line 91 from my XML:

<description><![CDATA[Our Sherry Emery quoted on ...

it looks like the problem is with “[Our”, which to me is bizarre.

If I throw the H3-Div pairs inbetwen the [wptabs] shortcodes, it works. Unfortunately, I can’t ask a client to do this whenever they need to update their content.

Playing around with this and my content, I did notice that having parenthesis inside the wptabtitle shortcode seems to screw up the accordion formatting. Once I removed the parenthesis, that seemed to fix things. Maybe that’s the key? If that’s the case, it seems like an odd shortcoming/bug.