" " issue

I’m unable to reproduce the issue on my end; it seems to be working fine. Could you please check the “trim characters” setting? It’s possible that   is being counted as a character, which might cause the “More link” to appear unnecessarily.

@steveoriol,

I have fixed the issue related to ` ` causing the “More link” to appear unnecessarily.
Please review the fix here: [Commit](https://git.drupalcode.org/issue/smart_trim-3558917/-/commit/1d3cf42ae9a...)

Please confirm if the fix works on your end.

@steveoriol, Please find the patch that fixes this issue -

Hi, I Created a patch for 2.2.0.
Please review. Thanks

@steveoriol patch for version 2.2 , please review and confirm

@steveoriol patch for version 2.2 , please review and confirm

@steveoriol patch for version 2.2 , sorry for the above comment and fault patch . this is working one please review and confirm

Hello, can we move these patch updates into the MR please

@markie , this is MR , that fix the issue - https://git.drupalcode.org/issue/smart_trim-3558917/-/commit/1d3cf42ae9a...

I’ve tested the current MR and the issue is not fully resolved yet.
While testing NBSP cases, I also noticed the same behavior with multiple regular spaces.

with a trim length of 10 characters still causes the “Read more” link to appear, even though the visible text length does not exceed the limit.

This shows the problem is not limited to   handling.
The trim detection logic is still counting collapsed or normalized whitespace differently from what is actually rendered.

To fully fix this, whitespace normalization (including NBSP and multiple spaces) needs to happen before the trim-length comparison that determines whether content is considered trimmed.

https://git.drupalcode.org/issue/smart_trim-3558917/-/commit/26670d5ce0c... - @shubham_pareek_19 Please test, i have the issue you raised

Environment

• Drupal: 11.4.1
• PHP: 8.5.5
• Database: MariaDB 10.11.16
• DDEV: v1.25.2
• smart_trim: 2.x-dev (MR !118, branch 3558917-nbsp-issue)
• Browser: Chrome

Prerequisites

• smart_trim enabled.
• An Article whose Body field uses the Smart trimmed formatter with a trim length larger than the test content, and the More link enabled with "output the link only when the field is trimmed".
• A short body (well under the trim length) that contains a   (non-breaking space), e.g. Hello world, this is a short body.

Root cause

The trimmed output was decoded with html_entity_decode() while the stored original output kept its raw   entity. The "trimmed" comparison and the More-link condition therefore always saw the two strings as different when a non-breaking space was present, so the More link was shown even though no trimming occurred.

Steps

1. Apply the fix from MR !118: decode HTML entities in both the original and the trimmed string before comparing, and normalize non-breaking spaces / whitespace so the trimmed-state detection reflects the rendered output.
2. Rebuild caches: ddev drush cr
3. View the Article whose short body contains   and confirm whether the "More" link appears.
4. For contrast, view an Article with the same short text but no  , and an Article with a long body (over the trim length) that contains  .

Expected results

• A short body containing   is not treated as trimmed, so no "More" link is shown.
• A short body without   behaves the same (no "More" link).
• A long body that is actually trimmed still shows the "More" link, whether or not it contains  .

Actual results

Before the fix, a short body containing   was reported as trimmed and the "More" link appeared even though the content fit within the trim length; the identical text without   correctly showed no link. After applying MR !118, the   body is correctly treated as not trimmed and shows no "More" link, the plain-text body is unchanged, and a genuinely long body (with  ) still shows the "More" link — confirming trimmed content is unaffected.

Testing produced with the assistance of an LLM.

Still needs community review

I have updated this fork.

The changes to src/Plugin/Field/FieldFormatter/SmartTrimFormatter.php look good to me. Appreciate the effort.

But, the Smart Trim module maintainer have a policy of requiring tests for all changes (including bug fixes,) so I am setting this back to "Needs work".

-mike

Test added, thanks to Claude Code and attendees of DrupalEasy office hours for working with me on this.

-mike

Thanks for the update and the tests, @ultimike! I reviewed the fork at 0ff8bfc and the formatter change fixes the issue.
The unit tests for the helper method look good. In case you also want coverage of the rendered formatter output, I wrote a kernel test for this specific issue (attached, 'tests/src/Kernel/MoreLinkTest.php'): it fails on 2.x with the reported More link and passes with the fork, and a genuinely trimmed body still gets the link. Feel free to include it if you think it adds value.

Setting to RTBC, as the fix is solid. Thanks!

I'm setting this back to needs review because Claude and I have spent the last 90 minutes or so trying to get all tests (including "phpunit (next major)" and "phpunit (next minor)" to run cleanly, without any errors or dependency messages.

Unfortunately, I don't think there's any way to get around deprecation messages since "Using the SYMFONY_DEPRECATIONS_HELPER environment variable to configure test runs is deprecated in drupal:11.5.0 and is removed from drupal:12.0.0" (via one of the test run logs)

The important bit is this: all phpunit tests are passing in all tested versions of Drupal core. The only thing that is stopping us from getting a completely clean test run is deprecation warnings in future versions of Drupal core - we're going to have to live with those.

So, here's what I've done:

1. Added @peri22's kernel test (thanks) and updated it (and our .gitlab-ci.yml) so that it behaves in tests with other versions of Drupal core.
2. Updated the the db text fixture for the upgrade test (it had a bug.)
3. I updated the annotation to a PHP Attribute for the SmartTrimFormatter plugin.

Before merging, I would some eyes on the diff.

thanks,
-mike

Marking as "Fixed" - thanks, @markie!

-mike