Filter enforcement and raw HTML output

Going backwards...

Issue 2 should be resolved in #3493938 🎉

Issue 1 is something I'm not unaware of. Perhaps it is something that can be corrected with some updated language. When I originally wrote the module, I wanted it to be secure by default, and not easy to make insecure (by not using the "Limit HTML" filter.) With the "strongly recommended" language, I meant that it can't be made insecure via configuration - only by implementing a hook (which I documented here → .)

Note to self, once I tag a 2.0.0 release, I need to update the documentation page.

So, we could change the language to be more clear on this point, or add a configuration option to remove this dependency? If we do the latter, should it be a global configuration (which I kind of like because it would not be on the text format add/edit page and thus a slightly higher hurdle) or a per-text-format option? Or, is there another option to be considered?

thoughts?

-mike

I appreciate the intent behind making things secure by default. That is a great philosophy.

Maybe this is a 2-step process?

Step 1 (short-term): Update the documentation and help text. Right now, the messaging reads like a strong suggestion, but the code enforces it as a hard requirement. That mismatch can be confusing, as it was for me. A small change could prevent some head-scratching.

Step 2 (longer term): I wonder if there is an opportunity to bring some of this thinking back to Core. If the goal is to ensure that all text formats are secure by default, maybe Core should issue a warning when the "Limit allowed HTML tags" filter is disabled. That would make things more consistent and remove the need for individual modules like Markdown Easy to enforce that logic on their own. Just a thought.

To your question about adding a config option to make the filter optional: personally, I wouldn't. The current approach works. When configured correctly, the extra filter doesn't really get in the way. For some users, it might be a bit annoying at first, but once it's configured correctly, you can forget about it.

In short, my vote would be: (1) clarify the documentation and help text, (2) keep the current behavior without adding a setting, and (3) consider whether secure-by-default enforcement belongs in Core for all text formats.

Changing to 2.0.x

Changing my mind - going back to 1.0.x 😃

ultimike → changed the visibility of the branch 3530329-filter-enforcement-and to hidden.

ultimike → changed the visibility of the branch 3530329-filter-enforcement-and to active.

ultimike → changed the visibility of the branch 3530329-filter-enforcement-and to hidden.

ultimike → changed the visibility of the branch 3530329-filter-enforcement-and to active.

ultimike → changed the visibility of the branch 1.0.x to hidden.

Ready for review. These changes are really only useful for the 1.0.x branch because 📌 Improve interaction with HTML filter Active , ✨ Create new "power user" flag to disable warnings and validation Active , and 📌 Remove/lesson dependency on "Convert line breaks into HTML" Active will modify this behavior.

As suggested above, core issue created: ✨ Provide warning on Site Status page when "Limit allowed HTML tags" filter is not used? Active

-mike

I reviewed this merge request and think it looks great. It's a clear improvement. In my opinion, it's ready to be merged.

I agree this only makes sense in 1.x. I've reviewed the change and it makes it a lot clearer for the end user.

Moving to RTBC.

Woot! Merged.

-mike

Automatically closed - issue fixed for 2 weeks with no activity.