I have created a very simple module that corrects bad interactions of other modules.
THE PROBLEM:
I am the maintainer of Slideshow Creator, and users are complaining of its interaction with the line break converter filter (LBC). Slideshow Creator (SSC) translates a special code in any text field into a slideshow, but the codes end up long and complicated and so users want to insert line breaks to make them readable. If LBC is placed before SSC, it changes those newlines into p and br tags and destroys the slideshow code. OTOH, if it is placed afterwards, due to what seems to be a bug in LBC, it inserts a spurious p tag inside the generated slideshow code. In short, the only way to use these two together is to put LBC first and write an unreadable one-line atrocity for the SSC code.
Clearly, there might be other filters with bad interactions, so a general solution is needed.
THE PROPOSED SOLUTION
My new simple module provides two filters and an admin page. On the admin page you specify regular expressions for content that should be shielded. Then the first filter finds and removes any material in the text that matches any of the regexes. You then run the problematic filter, which can't mess with the removed material because it isn't there. Finally the second filter replaces the removed material.
The way I use it to fix my particular problem is to use the regex from the SSC filter. It removes the SSC code, then the LBC is run, then the SSC code is replaced and the SSC filter runs.
This is a very basic filter, but it seems to fill a need. Any thoughts?
Ron
Comments
If a regular expression is
If a regular expression is involved, then you've lost pretty much all non-developer site admins.
I'm proposing to change the way the input filter system works to help avoid complications like this. Would you be willing to support something like that?
The Tokyo Drupal Guy!
Thanks for that suggestion.
Thanks for that suggestion. Your proposal goes beyond the purpose of this filter. It's a small simple module that fixes filter interactions here and now in D6 and D7, it isn't a grand plan for future drupal versions. If you can do filters better, by all means try it. But we have sites to get up and running now. The regexes can usually be found in the modules that have the other filters and can be just lifted. Failing that, people can ask questions in the issue queue. I don't think that is a big problem. The question is, is this useful, and also does anything similar exist? (I can't find anything.)
As an aside though, looking at your proposal and if I understand it right, it would mean that no text fields would ever display again exactly as formatted by the user, not anywhere, because the DOM would remove all the original idiosyncrasies such as spacing etc. If you want huge user confusion, that would surely be it? (And I don't see how it would avoid bad filter clashes.) Any thoughts?
This discussion would best be
This discussion would best be done in that issue, but suffice it to say that assuming the final output is HTML, then spacing idiosyncrasies are already ignored by the browser anyway. If you need to have line breaks turned into
<p>tags or multiple spaces turned into s, then it would just be a matter of having a filter that does that run in the pre-DOM phase. Also, if you have the core "Clean up incorrect HTML" filter enabled (the correct name escapes me at the moment), then this is happening already; all that that filter does in D7 is just create a DOM object, letting PHP's HTML parser deal with broken HTML in the process, and then serialize it again.(After re-reading your comment, it strikes me that maybe you're thinking filters run on content before it's stored in the database and there's no way to "get back" content exactly as it's entered, in which case I suggest you read up on how input formats work before continuing with your idea. But if this is a misunderstanding only on my part, please ignore.)
At any rate, I still think you're expecting to much of NORPs to understand how to find a regular expression out of a code file and extract it, but by all means, if you disagree, please continue. I still hope you'll consider supporting my proposal, though. There's no reason you can't do both. (For whatever reason, I don't come across people who have the slightest interest in the filter system very often, so please forgive me for trying to drum up support for my proposal on the rare times I do.)
The Tokyo Drupal Guy!
Thanks Garrett, No I did know
Thanks Garrett, No I did know how filters are supposed to work (though some wysiwyg editors wrongly change the DB content itself). I was thinking about less skilled users writing html then doing ^U in firefox and seeing it laid out entirely differently and not understanding why. I'll read up your other issue more carefully before I make an uninformed comment there.
Back to my module, I think people will understand the purpose of this filter. There are probably 1/2 dozen modules that cause trouble (but for a lot of people), so I can collect the correct regexes for those (perhaps even make them choose-from-a-list later on). My main question concerns whether I am duplicating work or maybe overlooking a security concern? (As for the latter, clearly this filter could be misused if included in a text format accessible to untrusted users and shielding a critical filter like removing unsafe html tags - the README will have a big warning about that.)