Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Lots of people don't really understand what Full HTML is, or why it might be insecure. #245052 deals with renaming it to reflect the insecurity, but I think we should consider moving it altogether. And not only that - add 'html filter' as a #default_value on the add input format screen, so that users have to uncheck it specifically.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | drupal.filter-format-filter-save.patch | 5.78 KB | sun |
| #13 | drupal.filter-format-save.patch | 5.38 KB | sun |
| #4 | filter_profile.patch | 4.28 KB | catch |
Comments
Comment #1
BioALIEN CreditAttribution: BioALIEN commentedI am guessing a lot of people use Full HTML for certain roles. Especially since Filtered HTML lacks support out of the box for img,h1,h2,h3,h4,h5,h6,strong and the list goes on.
For a beginner, it could be too daunting and too much to ask to go in and add their desirable tags.
Maybe the simplest solution is to promote best practices by adding a nice warning on the "Input format" page?
Comment #2
alexanderpas CreditAttribution: alexanderpas commentedI agree, even more, i suggest to extend the default setting for the filter to allow at least:
<h1> <h2> <h3> <h4> <h5> <h6> <em> <strong> <code> <del> <blockquote> <q> <sub> <p> <br> <ul> <ol> <li> <dl> <dt> <dd> <a> <b> <u> <i> <sup>(familiar??, it's the tags drupal.org allows)or something like this...
<a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <embed> <object> <strike> <caption>(taken from the FCKeditor)Comment #3
catchalexanderpas:
<object> and <embed>are not tags you want to give out to just anyone.BioALIEN: maybe we could have a 'very restricted HTML' and 'somewhat restricted HTML' format - so more and less filtered, as opposed to unfiltered - obviously those names would need some work.
Comment #4
catchHere's a first step towards this - it simply moves the code for creating input formats out of system.install and into default.profile - that way other install profiles can define their own input formats. It also means that the expert install profile starts with zero input formats configured, not sure if that's a feature or a bug yet ;)
No tests were harmed in the creation of this patch.
Comment #5
alexanderpas CreditAttribution: alexanderpas commentedif you aren't aware of the difference ;)
http://globalnerdy.com/wp-content/uploads/2007/12/bug_vs_feature.gif
Comment #6
BioALIEN CreditAttribution: BioALIEN commentedNot sure if it helps with where this is going but in the latest Drupal 6.3 release, the security was tightened around the use of HTML
<object>tags. Even admins are not immune to this latest change.Comment #7
catchI think it does. My general plan is 1. Move them into install profiles 2. Modify what they're called, and maybe some of the defaults in tandem with #245052: Rename input formats to reflect their purpose..
This would mean we could possibly do stuff like have 'full HTML' only in "drupal for experts", and enforce "filtered HTML" in the default profile, or something like that. But I reckon relocating them first is worthwhile on it's own.
Comment #8
Boris Mann CreditAttribution: Boris Mann commentedAargh. Those crazy db_query's with hard coded numbers in it drive me insane! Can we construct an array for http://api.drupal.org/api/function/filter_admin_format_form_submit/7 ?
Comment #9
catchI thought we specifically couldn't do that in install profiles. Or am I mis-directed?
Comment #10
moshe weitzman CreditAttribution: moshe weitzman commentedI think we could do that, but that function would need refactoring to remove the drupal_set_message() and cache_clear with make no sense during installation. I think that can be done in a follow-up patch.
Comment #11
floretan CreditAttribution: floretan commentedMoving input format definitions to the install profile is good, but that means that every install profile would need to declare it's own. So we need to get an API for creating input formats (and
db_query("INSERT INTO {filters} ...does not qualify as an api :-) ).Also, even if the "expert" profile is supposed to be minimal, it should have at least the "Filtered HTML" input format enabled.
Comment #12
Boris Mann CreditAttribution: Boris Mann commentedre: db_query -- yep, this is the underlying need of all that cruft in system - we need to get to having clean functions to do these thing.
Anyone up from trying their hand at a filter_create function?
Comment #13
sunAttached patch refactors that cruft into a new function filter_format_save(). *SCNR*
Comment #14
catchThis looks great and the hunk of code that's moved around is already covered by tests. However it only deals with input formats, we still need an API function for filters to be able to fully de-cruft system.install - also we should convert the inserts to dbtng, but not necessarily in this patch.
Comment #15
sunAdded filter_filter_save() using a db_merge query (based on DBTNG docs - if this is wrong, then the documentation is wrong).
Comment #16
moshe weitzman CreditAttribution: moshe weitzman commentedLooks nice.
In a followup patch, I'd love for us to introduce string based primary keys for formats like we do for content types. The problem now is that we have no reliable way of referring to a format such as the 'php input format' as created by php module.
Comment #18
sunNot sure, how much of that was already covered by the filter system revamp, so tagging for later review.
Comment #19
sunEntire patch is covered by recent FilterSystemRevamp changes already.
Not sure about the OP - feel free to re-open + rename this issue.