PHP 8.6 - Functions mb_regex_encoding() and mb_ereg() are deprecated

Thanks for opening this! Was confused why this test was consistently failing.

I did some Git archeology. These lines were added to core/modules/views/src/Plugin/views/field/FieldPluginBase.php in commit 4a9fbaf2150a #1912476: Move views_trim_text to FieldPluginBase.

That issue simply moved the code from views.module. If you blame earlier versions of views.module, this code goes all the way back to the initial commit for Views in core: commit a626abb24fa "Add the 7.x-3.x Views branch." (for which there's no issue NID in the commit message 😢).

Anyway, I pushed an initial commit to simply remove those, and use the fallback of preg_match() instead. This passes locally (still on 8.5):

./vendor/bin/phpunit -c core/phpunit.xml core/modules/views/tests/src/Unit/Plugin/field/FieldPluginBaseTest.php

Opened an MR about it. Let's see what the bot says.

Bot is happy. Just a random fail in Nightwatch (which I can't re-run, "thanks" to #3576458: [regression] Subsystem and Topics maintainers require access to re-run, trigger, or view tests). Any other changes needed here before RTBC/commit? Would be great to get back to all-green pipelines by default.

Thanks!
-Derek

Re-ran the nightwatch tests, and they're green now.

Looked at the MR and it's straightforward. Looking at the old commits referenced in #6, there's definitely existing test coverage. LGTM.

This was added to views by #513396: Trim field to a maximum length - Multibyte encodings

I'm not an expert on multi-byte strings but this removal leads to a what looks like a regression. I was assisted by an LLM in finding this regression.

As you can see on https://git.drupalcode.org/project/drupal/-/pipelines/810759 - the test only pipeline passes but the non-test only pipeline fails because we've removed the mb_ereg() function.

Ah, okay. I'm not a multibyte expert either, and it looks like existing test coverage was insufficient.

I did check the deprecation RFC yesterday and there were no suggested alternatives or replacements.

Just did some searching: I'm not sure if anything suggested in this stackoverflow thread is relevant or actually works, but maybe a thread worth pulling: https://stackoverflow.com/questions/1725227/get-multibyte-character-coun...

Reading the RFC it looks like there is a replacement - https://packagist.org/packages/mb_onig/mb_onig - which adds back the old functions without deprecation. It feels wrong to remove support for this when nothing is currently broken other than a new deprecation message being emitted. The current MR is not mergeable as it includes the test coverage I've added to show the different behaviour - I've asked a hindi speaking friend to confirm that the preg_match behaviour is incorrect and confirm whether or not this change leads to a regression.

FYI this functions just been fixed in latest security releases and the most of distros adopted it as a patch but as the library is not supported I bet it's wrong way to use totally untested extension (mb_onig) and archived library

Refs:
- https://github.com/php/php-src/security/advisories/GHSA-wm6j-2649-pv75
- https://github.com/kkos/oniguruma

Moreover https://github.com/youkidearitai/mb_onig extension require to build it using pie or bundling into PHP itself.

So the most of end-users will be unable to install it without GCC&co

Added another approach and it pass locally

Oh, whoops, moving to RTBC back in #12 was not intentional. Sorry about that!

I have a nit on the MR to go with a ternary, but this is fine for RTBC.

Agreed with the nit. Applied that suggestion. Bot is still happy. Closed my original MR in favor of the new one. No complaints. Leaving RTBC.

Thanks!
-Derek

Committed and pushed e69457653ca to main and 6db7de3daef to 11.x. Thanks!

Filed follow-up to promote PHP 8.6 for upcoming release #3590237: Add PHP 8.6 polyfill