Add a way to truncate HTML strings without counting or damaging HTML elements (and use it in Views) - Html::truncate()

How each function works currently:

Unicode::truncate() features:

• doesn't use legacy procedural code
• uses a real ellipsis character and not just "..."
• ability to truncate the ellipsis if $max_length is small (questionable utility now that ellipsis is just 1 character)
• ability to disable "word safe" if the string is under an optional minimum length
• knows to remove any "." characters from the end of the trimmed string if an ellipsis is added

FieldPluginBase::trimText() features:

• Removes "scraps" of HTML entities from the end of trimmed strings
• Optional toggle to ensure that any HTML tags left in the trimmed string are normalized (closed off) automatically

Common functionality:

• ability to toggle the visibility of an ellipsis
• ability to enable "word safe" which will only trim on word boundaries

Based on the above, I could see Html::truncate() looking something like something as simple as:

function truncate($html, $max_length, $word_safe, $add_ellipsis, $min_wordsafe_length) {
  $value = Unicode::truncate($html, $max_length, $word_safe, $add_ellipsis, $min_wordsafe_length);

  // Remove scraps of HTML entities from the end of a strings
  $value = rtrim(preg_replace('/(?:<(?!.+>)|&(?!.+;)).*$/us', '', $value));

  if (!empty($alter['html'])) {
    $value = Html::normalize($value);
  }
}

and then trimText() looking like:

function trimText($alter, $value) {
  if (!empty($alter['html']) {
    $value = Html::truncate($value, $alter['max_length'], $alter['word_boundary'], $alter['ellipsis']);
  }
  else {
    $value = Unicode::truncate($value, $alter['max_length'], $alter['word_boundary'], $alter['ellipsis']);
  }
  return $value;
}

So, Views isn't great because, unless I've read the function wrong, truncating the following to 10 characters:

<strong>foo bar baz foo</strong>

Gives:

<strong>fo</strong>

Which is technically correct I suppose, but I'm sure not many people's *intention* when dealing with HTML.

Woah http://alanwhipple.com/2011/05/25/php-truncate-string-preserving-html-ta...

From IRC:

https://ideone.com/5Gbe5J
https://ideone.com/u0cd9c
https://ideone.com/gm7Zgb
https://ideone.com/0fZUBk

more reading - http://www.pjgalbraith.com/2011/11/truncating-text-html-with-php/

This is sort of a feature request... I guess...

More things wrong with the Views approach... Because of the regex being run, an existing malformed HTML entity inside a chunk of text will cause the whole thing to be chopped right back to the entity.

sometext &nbsp more text

becomes:

sometext

This is also sort of a bug report because Views seems pretty buggy (or at least naive) at the moment.

No, I don't think this should be something in Views!

This functionality should be lower level than that, and Views should simply use it.

I suspect that the only reason it was ever in Views in the first place is because Core has never provided something decent to achieve this totally normal functionality.

I've been thinking about it on and off. Not sure the best way yet...

I put the start of a sandbox up at https://github.com/thedavidmeister/html_truncate_sandbox

The bit I'm wondering about atm:

Say you have 'foo bar' and you want to truncate it at 5 characters, what you want to see is "foo b" without word safe, and "foo" with word safe.

If we move the cursor to "foo&n", which is 5 characters, we can't easily know that "&n" is actually the start of   (which we'd count as one character).. this messes with our counting.

This is basically where I assume the Views people got to, which led to what I was complaining about in #8

well not exactly that, because some html entities are longer than that, like ¤.

I was actually thinking using get_html_translation_table(), then getting the length of the longest entity from that and doing something similar to what you suggested.

What about if in every string we just used html_entity_decode to convert them to single characters, then we calculated the maxsize, before finally adding back in the entities with htmlentities.

That could potentially work, would have to write some more tests to see if we can break that.

If you have any HTML tags in the input...

Well that's exactly what Views claims (and has claimed for years) to handle.

No "grand claims" for sure, but from the D7 interface, I'll show you where the confusion comes from, for me:

Trim this field to a maximum length
Enable to trim the field to a maximum length of characters

and also

Field can contain HTML
If checked, HTML corrector will be run to ensure tags are properly closed after trimming.

I certainly expect, after reading this in the UI and not reading the code, the following:

- Views is aware of HTML (not limited to HTML entities, it just says "HTML")
- The characters being counted for determining the maximum for trimming wont include invisible characters inside tags, after all, we've told Views that this is an HTML string and there's no caveats listed in the UI
- Views won't do anything at all to my HTML entities, it didn't mention HTML entities once in the UI, why would it be damaging those?

I stand by #17: there is only one case truncating HTML is doable, and it's when there is no tags whatsoever. In that case, just convert to plaintext, do the truncation there and convert back to HTML.

What's wrong with the DOMDocument approach - using that to normalize the string, then getting the inner text of tags? That looks like it would work to me.

At the very least can we move the Views truncation functionality to \Drupal\Component\Utility\Html?

You're probably right, this issue could benefit from being broken into two parts - improving the organization/centralization of some decent existing functionality, and then improving said functionality.