Usability of legacy pages category/% and taxonomy/term/%

We are providing alternative legacy pages for categories, in the style of core Taxonomy: category/% and taxonomy/term/%. These are not nodes (unlike the 'proper' category pages), but obviously the point here is to have a page more or less equal to core Taxonomy, both in formatting and the ability to combine multiple categories/terms to a single page (and so to accept the exact path arguments used by core Taxonomy).

Unfortunately, these pages have two serious usability flaws. First one is, that the shown description is not properly filtered using the node's input format. This is yet another place, where we can't inherit the code from core Taxonomy (as the current implementation does), due to the node-based nature of categories: While the description on core Taxonomy terms is just a plain textfield (where filter_xss_admin() or HTML removal from feeds is enough), in Category we have a fully-blown node teaser which simply just cannot be shown without proper input format being applied.

The existing code have a comment saying: HTML will be removed from feed description, so no need to filter here. That's quite not true, because filtering does [potentially] much more than just removal of HTML tags. Sure, with just a 'Filtered HTML' input format it's all fine, but there are filters with much more complex substitutions: For example, Smileys module replaces textual smileys with image tags, Image Assist replaces square-brackets-pseudo-tags to further image tags, BBcode and Texy and similar formatters replace all sorts of pseudo-tags to various HTML formatting... Even if the resulting HTML is going to be removed (i.e. in a feed description), we still need to run the filters, so that we get rid of the raw pseudo-tags. Showing them in the feed is obviously a bug. And on the page display, we need the filtering even more, as we're going to actually render the teaser. With current code not only various pseudo-tags are shown to the site visitor, and formatting of the description broken by their inactivity - if someone used the php code input format on a category description, the code gets exposed to visitors on the category/% pages. (Might have security implications even.)

The second major flaw of these legacy pages is, that they are simply different from the proper node-based category pages. While it's the very point of having these, to give a Taxonomy-like output and functionality (multiple categories arguments and the like), it's very annoying at the same time, to have in fact duplicate pages (SEO concern), that lack a lot of the full display: No node theming of the category, no additional elements such as category_display links and TOC trees, no category_views alternative node listings, no comments functionality, no 'add child' links, no other node-based additions (like fivestar widgets, whatever...), different URL with a different breadcrumb, also resulting in no menu expanded and no URL alias used. All these differences are quite able to make these legacy pages _very_ different from the real thing (node/%), and therefore broken for the eyes of a site visitor, who accidentally got there, and don't know what's up (and who don't have any navigation back to the node-based view).

As for my use case, this became a concern after I started to evaluate the Simplenews module (that I'm more or less required to install on the site now), as Simplenews links to the paths taxonomy/term/xyz a lot from various places, and all these links are in fact taking the user to a realm of broken pages, with no easy way back.

The solution here is to simply redirect from the legacy URL's to the proper node-based pages of the categories, solving all the confusion and inconsistency, as well as duplicate contents [SEO] etc. In the other hand, we might want to keep the legacy pages in some use cases (as the nodes are different output, and lack the ability to combine more categories to a single list). So in the end, I believe that we need a new setting somewhere, to determine whether to redirect for consistency, or whether to keep legacy pages for compatibility.

Now, another question is, where this new setting should live. A logical place would be Taxonomy wrapper (as this is Taxonomy legacy stuff), but the wrapper doesn't have any administrative pages, and can't really have any persistent storage for non-core stuff, given that it doesn't go through traditional module install/uninstall process. Another idea is the main category module, but in this scope it's rather a minor setting, and doesn't really fit anywhere. So, in the end I went with category_display module, which is already full of various 'display this and that link' options, and is supposed to be an optional tool for more display tuning - so I believe it fits there.

So, the attached patch contains:

- A new 'legacy_redirect' setting in category_display, along with description, schema, and upgrade path. As traditional in category package, it's a per-container setting.

- A new function category_display_legacy_page_redirect($cid) checks the setting, and redirects to node-based pages as necessary. This is now called from category_page() in a similar way, like all the other interactions between category.module, category_display.module and category_views.module are already done.

- This doesn't apply to RSS feeds, because they are more or less identical in both node and legacy view, and I'm unsure what RSS readers might do, if receiving a redirect response. I think, that it's not worth the trouble to play with feeds here, as the user won't see the other RSS link anyway, after being redirected.

- All three instances of unfiltered description output are fixed, along with a fitting code comments, so the pages now work properly without the redirect, too.

- Additionally, taxonomy_term_page() got a bit of cleanup - it's just a tiny wrapper function, but the include file was loaded in not-really-clean way, and the comment was more or less wrong (it doesn't really redirect by itself, it just returns the rendered output from another page callback). Also the neighboring taxonomy_save_vocabulary() function got a minimal comment at the top - this is missing from both Taxonomy wrapper and core Taxonomy, but it makes the function visually difficult to separate from previous code.