Prevent buggy output caused by input filter order

I agree... I've had plenty of frustrating experiences wondering why Markdown wasn't working, then realizing the issue is in the order of applied input filters.

I added documentation to the project page (http://drupal.org/project/markdown). Feedback appreciated.

It would be great to detect this in the module and throw an error if an input format is configured improperly.

Markdown may conflict with other input filters, depending on the order in which filters are configured to apply. For example, if the "Convert URLs into links" filter is run before Markdown, Markdown-style links will be applied to an already transformed URL, creating unintended results. Additionally, the HTML filter may strip tags from converted Markdown text if the HTML filter runs after Markdown. If using Markdown produces unexpected markup when configured with other filters, experimenting with the order of those filters will likely resolve the issue.

I guess when filters are enabled, we should check on validation whether "convert urls into links" and "html filter" comes before markdown. Since there is no situation that is intentional (as it always results in buggy output), we can just throw an error there.

Attached is a patch that checks if filter_markdown comes before filter_url and filter_html.

I don't like the idea of a "check filter order" patch. Are there any other input filters that do anything similar? It seems like unnecessary hand holding when reading one line of install documentation solves the problem.

I don't know if any other filter does this kind of hand-holding, but people all too often forget to set the filters in the proper order. Warning doesn't hurt at all.

If the documentation was sufficiently clear and everyone read the documentation before using the module it wouldn't be necessary, yet it might be welcome even then for the corner cases.

Right, I see how it could be helpful. But if you add the core line break filter before the strip tags filter (which doesn't include p by default) your filtered text comes out all wonkey, and you think for a second, check the filter order, and fix things up. There's no "you most likely don't want to do that" message.

There's probably a better way to handle this than by creating a new pattern, which if widely adopted would create tons of ui/x noise (tons of errors until you get all of the filters with required orders right). I doubt it would be widely adopted, but why open the gate. Also I'm not too into the idea of enforcing a "right" way to order filters -- there may be edge cases none of us see right now where the forbidden order fixes some problem, and taking away a site builder's opportunity to fail also takes away their opportunity to choose.

So what's another way we can get this information out there? A validation style error that bars the user from saving a text format if the filters are out of order (I think) is too restrictive. A pop up js modal warning the user and giving them the choice to cancel or proceed wouldn't be too bad, but that would be a new ui pattern, and would clash with the established ui. There could be a note in the message area on install that reminds the user of the recommend order of filters, but unless they set up formats right away they'll probably forget. We could add a note in the filter description text, something like "For the Markdown filter to work as expected, it should be placed before the line break and URL to link filters in the filter order", which although not sexy has precedent and would give the users the info when they need it.

I lean towards the last option, for consistancy's sake. But I'm not hugely against any of them, just taking a wider look at the issue.

I guess we can implement your suggestion since we hardly let anyone other than the administrator (node/1) manage the text filters. And leave the patch here for the crazy folks that let their users tweak the input filters.

I also don't like the idea of preventing a filter order by throwing an error. I think this should be a warning instead.

Changed to warning.

reroll atop 7.x-2.x

Additionally, the HTML filter may strip tags from converted Markdown text if the HTML filter runs after Markdown. If using Markdown produces unexpected markup when configured with other filters, experimenting with the order of those filters will likely resolve the issue.

Does the markdown filter only generate "safe" HTML or would using Markdown on its own in formats for untrusted users constitute an XSS vulnerability?

If so, the better option would be to add certain tags to the allowed tags configuration of the HTML filter.

@Heine, definitely. I think that should be fixed in the README. Oh, nevermind, @dmetzcher has already fixed that in #1890542: Quote Character Does Not Produce Blockquote Tags when Markdown is run after the "Limit allowed HTML tags" filter.. I'm closing this issue, I guess that's enough.