If you're trying to trim a string to a specified length within a Winter CMS (or even just plain Laravel) project, don't use
It doesn't support multibyte characters (such as unicode and emojis), and while you're unlikely to test with multibyte characters; users have a funny way of using emojis all over the place. This can cause additional headaches beyond just mangling emojis on display, since using
substr() on a multibyte string will cause it to mangle the string, and then PHP will internally change the type of the string to a binary string (represented by being prefixed with a
b when dumping the string, so it becomes
b"""string content""" instead of just
"string content"). Once you've got a binary string on your hands, you're primed and ready to have all sorts of other problems.
The biggest of these potential problems would probably be that
json_encode() will fail with
"Malformed UTF-8 characters, possibly incorrectly encoded" if it encounters a binary string. This is then made even more difficult to debug if you are returning this malformed string in an AJAX response, as the response object has to be JSON encoded before being passed to the underlying Symfony Request object; and prior to Laravel 8.34.1 the exception thrown would simply be that
$request->setContent() doesn't allow booleans, which doesn't make sense; until you realize that
json_encode() will return
false if it fails by default.
Long story short, don't use
Str::limit($string, $length, [$appends]) if you're trying to limit the length of a string, and
Str::substr($string, $start, $end) for any other use of
substr(). These methods are multibyte aware and will be a lot cleaner and more readable than throwing
mb_substr($string, $start, $end, 'UTF-8'); all over the place in your codebase.