I’ve been hacking SimpleTagsPlus into not displaying the embedded tags when the content is called via the_content_rss. I wanted it to do so because I’m using the_content_rss in my theme for publishing excerpts (in my other blog), and that makes those embedded SimpleTags look ugly. That’s because they’re not rendered, which in turn is due to the fact that SimpleTagsPlus functions are applied only to the_content and not to the_content_rss.
I was able to fix this by adding, to the_content_rss, a filter of my own for skipping the tags altogether (i.e. replacing any occurences of [tags]...[/tags] with an empty string). But while doing this I came across some interesting issues…
First off, there’s this funny little bug #3884 in WordPress’ bug tracker:
Plugins using the filterare never applied in the RSS2 and Atom feeds, and still not working in the tag of the RDF feed.the_content_rss
While reading about it I came to think that my feeds must have been displaying those ugly [tags]...[/tags] blobs as part of their content. And now, because of #3884, it seems that I can’t fix it in feeds other than the plain RSS one.
But it turns out to be more complex than that. Instead of full posts, I’ve been providing my feed readers only with summaries for some time now (can’t remember when or why I made the switch), and thanks to that, the embedded tags are not displayed in the feeds.
Apparently, the question of summaries vs. full posts in feeds is a rather heated one, and I honestly can’t say my choice to provide only the summaries has been a heavily deliberated one. But now, because of the issue I had thought already plagued my feeds, I’m not sure I would even want to make the switch back to full text feeds even if I otherwise did: the full text posts in my feeds would then contain those unrendered embedded tags right at the beginning where I’ve chosen to place them.
By using a heavier solution to tagging, such as Ultimate Tag Warrior, from the beginning I would have avoided this, since (AFAIK) UTW does not make tags part of the posts themselves like STP does, thus eliminating them from the feeds — just the way I’d want it to be. But back when I was considering the alternatives, UTW seemed somewhat of an overkill. Obviously, I wasn’t thinking far enough ahead or big enough.
I found a WordPress.org support forum thread discussing the possibility of providing readers with both the summary feed and the full text feed (via Oliver@StevePavlina.com), and I think I’m gonna try and implement the solution suggested there. And then I’m gonna have a serious look at replacing SimpleTagsPlus with Ultimate Tag Warrior. A a bonus, that would allow me to display a nice-looking tag cloud on my archives page, something which apparently can’t be done with SimpleTagsPlus.
Added 18:57: The one feed that displays full summaries, when the option is selected, is the RSS2 feed, and while tweaking the files I found that it calls the_content and not the_content_rss for producing the content, so it will be properly formatted by SimpleTagsPlus after all, eliminating any problems when switching back to full text feeds. Since I had already figured out how to publish both the summaries and the full text feeds, I just reversed the procedure by making full text posts in feeds the default and publishing an additional summaries-only feed with the hack described in the aforementioned WP forums link.
Added 20:27: I came across some very bizarre behavior from WordPress after having set up my summaries feeds. The feeds were seemingly ok in the browser, but Google Reader wouldn’t load them and Feed Validator claimed there was a 404 error fetching them — yet it would display their source right after the error! At first I couldn’t even find anything resembling this, and when I did (examples 1, 2, 3, 5) the links had no solutions or the solutions were referred to but the links were dead, or the solution was more than two years old and couldn’t be applied to newer WordPress versions.
Finally, I found a bug posted on wp-trac, describing a similar-sounding situation with a little hackish but functioning workaround. Apparently, forceably rewriting the headers to report 200 instead of 404 does the trick, like so:
header("HTTP/1.1 200 OK");
header("Status: 200 All rosy") ;
I inserted these lines into my feed-(rss|rss2|atom)-summaries.php files, between the header('Content-type... and $more = 1; lines, and voilà! No more 404 from Feed Validator.