Allow more chars in "Limit allowed HTML tags" filter

rerolled.

#3 first time failed, second time passed. Works on my local. IMO ready for RTBC.

Once you have a textarea, don't you have to deal with newlines then?

Did a manual test using filter-chars-limits-2579471-3.patch and it works as expected. Adding screenshots to the summary.

@dawehner about newlines:
Not sure if you're asking about tests, risks or edgecases, but if you're not: I tried to add som linebreaks in the area, and they where removed on save. So it does not seem to be an issue, allthough this is just from a sitebuilders perspective.

Did a quick test just copy/pasting the defaults of this field

<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id> <p> <br> <span> <img src alt height width data-entity-type data-entity-uuid data-align data-caption> <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id> <p> <br> <span> <img src alt height width data-entity-type data-entity-uuid data-align data-caption> <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id> <p> <br> <span> <img src alt height width data-entity-type data-entity-uuid data-align data-caption> <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id> <p> <br> <span> <img src alt height width data-entity-type data-entity-uuid data-align data-caption>

That's a lot of tags imo, so tbh, hitting that limit almost brings you to full html anyway, so I'm not sure how much this would help, besides a bit more UX because you'll have faster view on which tags are actually in there. Also, this isn't major at all.

I do think that the CKEditor toolbar config not syncing with the allowed HTML filters at the bottom is not ideal. I can see this leading to frustration for users as to why their CKEditor configurations aren't appearing as they would assume if they didn't also include it in an allowed HTML tag. But I tend to agree with swentel here in that the 1024 character limit allows for quite a lot of tags.

I recognize that the "left/right/center" alignment buttons in CKEditor do take up ~30 characters each i.e. <p class="text-align-center">, but for the default CKEditor setup, they are the largest tags in terms of characters. The others being <sub>, <sup>, <hr />, <table border cellpadding cellspacing style>, <tbody>, <tr>, <td>, <u>,< s>. I would say that the two cases that droplet suggests in comment #14, (1900 characters & 1030 characters) are still edge cases. The 1000 character example from comment #13 is a copy and paste of the same tags, which wouldn't be the case in a real world scenario.

For me it is difficult to understand how one would have a case that would require more than the current 1024 characters for allowed tags, but still need to limit tags which is why one couldn't use the FULL_HTML option -- and for that case to be common enough to warrant a change here.

@droplet - I understand now. I don't see an issue with patch #3 after testing. Looking at how the configurations are stored in the database, there doesn't look to be a limitation for changing from a textfield to a textarea. I would defer to more input from the community on this though.

This behavior has been there since ages (#254725: Maxlength field for Allowed HTML tags too short and no-one has ever complained about it since then. Let's not focus on security or the state of the issue (because we can discuss that for hours)

Note that I don't oppose the patch, but needs work for two reasons:

• The newlines are saved, this should not happen (see underneath)
• As a consequence, you get a javascript error: Uncaught TypeError: Cannot read property 'tagName' of null - you see in before the submit

We should have a way to disallow entering new lines because it breaks the javascript before submission too.

settings:
      allowed_html: "<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id> <p> <br> <span> <img src alt height width data-entity-type data-entity-uuid data-align data-caption>\r\n<table> <tr> <td>"

The real quick fix then (if we want to keep this novice) is to set the maxlength to 2056 for instance.

The patch attached here is for increasing the maxlength to 2056. If we want to move in the other direction (changing the form element to a textarea & not allowing newlines to be saved), we can create that patch as well.

Note - not sure why I came up with 2056 :) 2048 seems more 'logical' because it's the double of 1024 - anyway, works for me.

Updated patch to use 2048 :).

All the feedback from @swentel is addressed so RTBC.

Can we get a follow to change this to a textarea and to handle the new line issue. I think that that makes a lot of sense.

Committed 988c359 and pushed to 8.0.x and 8.1.x. Thanks!

Follow up issue for converting this input to a textarea and resolving the newline issue that results from it can be found here.