Trimmed body display format can result in faulty and chopped off HTML if "Correct faulty and chopped off HTML" is not activated on the text format

I would argue that this is sort of major, as for example there is a workaround of just uninstalling the quickedit module

Can you not use them "Correct faulty" and trim at the same time successfully?

It seems for sure there would be no other way. Drupal can trim text, but if that leaves tags hanging open, it is the site builder's responsibility to check the box "correct faulty HTML".

What would you have Drupal do to fix this?

Sorry for the grumpiness, not having a great day here—that's not your fault.

So this is effectively checking the box for them?

8.0.x is closed for development.

I've confirmed this is still occurring, but I don't think it meets the criteria for Major since there is a very easy workaround of enabling "Correct faulty and chopped off HTML".

Incredibly, the patch still applies, and it works as advertised. Updated IS with screenshots of before and after. Leaving in review as this seems simple enough but the patch still needs a code review.

Let's add some tests.

+++ b/core/modules/text/text.module
@@ -150,8 +150,8 @@ function text_summary($text, $format = NULL, $size = NULL) {
+  // Even if the htmlcorrector filter is not present, fix the trimmed summary's faulty HTML.

The code comment can't be > 80 chars.

Updated patch attached with a shorter comment.

Turns out we already have tests for this and they are failing. With the fix this time.

Not ready for review since it needs tests and now we're debating whether it's even a bug - since the patch breaks existing tests.

OK jibran's patch may fix the tests so this is ready for review, if it passes.

There was random fail in first run which is gone after another test run. Now patch is ready for a review.

So, the test TextSummaryTest.php was passing but was testing the wrong strings and it now updated to test for the correct HTML.

+++ b/core/modules/text/text.module
@@ -152,8 +152,8 @@ function text_summary($text, $format = NULL, $size = NULL) {
+  // Fix faulty HTML in the trimmed summary.

Why is the faulty HTML only fixed when there is s format?

There are also coding standard errors.

The more I think about it the more it feels like a 'work as designed' to me. Here is why:

Why is the faulty HTML only fixed when there is s format?

If the answer to this question is, yes, we should fix that too then that would mean \text_summary() will fix all the faulty chopped trims so why even have filter_htmlcorrector in the first place. This is the only use of filter_htmlcorrector here.

I think this is a support request and OP needs to enable filter_htmlcorrector filter to fix the problem.

Anyway, here the fix only patch without tests for anyone who needs that. Please don't test it.

Why is the faulty HTML only fixed when there is s format?

The 'Trimmed' formatter is only available for formatted text fields, so this only applies when there is a format. Unless I am misunderstanding the question?

The 'Trimmed' formatter is only available for formatted text fields, so this only applies when there is a format. This statement is incorrect. Trimmed is not a format. Trimmed is just for summary fields, in the context of this issue. A summary field has the same filter as its corresponding textarea. A summary field get trimmed either by <!--break--> string, text.settings.default_summary_length, or the size provided to \text_summary(). The trimmed output is only corrected when filter_htmlcorrector is part of the format.

Here are three cases:

1. HTML will not be corrected if there is no filter format.
2. HTML will not be corrected if there is a filter fomrat and filter_htmlcorrector is not set.
3. HTML will corrected if there is a filter and filter_htmlcorrector is set.

Trimmed is not a format.

Err - yes it is? And this issue occurs when using it, regardless of whether there is a summary involved. And it is not applicable to plain text fields.

This is a screenshot of the display settings for a Text (formatted, long, with summary) field:

This is a screenshot of the display settings for a Text (formatted, long) field:

This is a screenshot of the display settings for a Text (plain, long) field:

LOL, @quietone and I are talking about filter format or text format in the UI and you are talking about field formatter and formatted fields which are textfield, textarea, and textarea with summary with filter format.

These are filter formats:

It is true that from the UI you can't set format to NULL but \text_summary() can work with NULL format hence @quietone's question.

I know that you were talking about text formats, that is why I said it's not possible to use the trimmed formatter on a field that doesn't have a text format :)

Thanks for the commit.
Works on 8.9.2, 9.0.3 and 9.1.x.
Seems like it was working for most of the tags but strong

We don't seem to have any new test coverage here?

ie. if this resolves a bug, why isn't an existing test failing?

Still needs a test.

While attempting to write the test cases for the issue, I noticed a few things:
- To resolve current failures, I had to fix multiple test cases so it passes existing tests. Mainly those are related to expected strings only.
Is it the right approach? I am not sure if there can be additional regressions.
I need some inputs from someone.

- I added a test case to validate the string normalization. Is it sufficient or we need to render and check string over there as well?

Keeping "Needs tests" tag as it is until we have conclusion on above points.

The logic has changed in 9.3. Updated patch.

This might be a slightly different issue, but I want to post this because it might help folks with a problem that looks a LOT like this problem if you are trimming content in a views rewrite field.

Check the "Field can contain HTML" option to fix it.

reroll Patch for 10.1.x