If installed, FCKEditor will operate on any input formats -- even ones that are not HTML. This can cause unnoticed user data corruption, which is why I have marked this "critical". If that is not the proper convention, feel free to downgrade.

It seems to me that the use of FCKEditor is closely tied to input format. If the input format is some form of HTML, then FCKEditor *may* make sense, but not always -- e.g. if it is full HTML FCKeditor may munge it in some cases. Regardless, if the input format is NOT html, there is no way that FCKEditor should get turned on for the content area.

I think that the right way to fix this is to condition FCKeditor activation on the input format, and then provide a mechanism in the FCKeditor configuration page to say what input formats FCKeditor should act on.

Comments

ontwerpwerk’s picture

ontwerpwerk commented
Version: 5.x-1.3-beta » 5.x-1.x-dev
Category: bug » feature
Priority: Critical » Normal

The behaviour of FCKeditor has always been regardless of input format - because the editor may also be loaded for textfields that do not have any format information associated (site mission and footer come to mind)

Change of that behaviour is a feature change, not a bug (the module does what it's designed to do)

At the moment there's no practical code to determine whether a textfield has a filter associated, so if anyone has any ideas about that please provide a patch.

Jorrit’s picture

Jorrit commented
Status: Active » Closed (fixed)