FWIW, I think the "no filters" requirement a la Install.txt is unfortunate, for these reasons:
1. Some users want to use raw HTML (among them me, because it's more efficient, especially with filtered HTML). However, TinyMCE doesn't respect whitespace in raw HTML, so the code is unreadable. Yes, I tried the pre-formatting setting, but what TinyMCE does is wrap the HTML in a pre tag, and still remove the whitespace!)
2. Some filters are important! Like Glossary, for example, or the filters that shorten URLs, or the filters that recognize email. Generically, the ability to post-process content after submission is important. Is it really necessary for us to sacrifice that for the sake of TinyMCE?
In short, we're being asked to sacrifice filters for TinyMCE. Why should we have to do that?
Comments
Comment #1
kreynen commentedComment #2
kreynen commentedhttp://drupal.org/node/130304
Comment #3
mstef commentedSo this post links to another page..which links back here..?
And the reason is......
Comment #4
kreynen commentedBecause it's related to several other posts. Rather than sift through page after page of errors, to see if anyone else is having the problem most users simply post their problem. I cleared out hundreds of posts when i posted the summaries of the outstanding issues. My hope was that people with more experience with the specific problem would step up to help. Judging by the number of people contributing patches, I'd say the summaries worked.
Marking posts as duplicates and closing old issues has made the issue queue much more manageable for me. Drupal's issue queue leaves a lot to be desired, but it is the only tool I have. If there was a better way to group related issues, I'd use it. Since there isn't and I don't have to write one, I use the tool I have in ways that work for me. I know this may be hard to believe, but I have things I'd rather be doing that helping people with TinyMCE.