I'm not about to pay to check out Mijoshop's code, but what I will suggest is that if their startup.php file means that they have an entry point into Joomla without routing through the normal index.php file, they need to ensure they are including libraries/import.legacy.php and libraries/cms.php files in their bootstrap (the CMS bootstraps all include snippets similar to this - https://github.com/joomla/joomla-cms/blob/staging/includes/framework.php#L32-L41 - to include those files).

Why am I suggesting this? My immediate thought is that they have code that is launched separate from a normal Joomla request that routes through the index.php files. Those files properly bootstrap the application and ensure all the needed tools are loaded into place. I'd venture to guess that they aren't including at least the libraries/cms.php file which handles loading up all of the Composer libraries, in which case there should be other issues in their code too (like being unable to find the \Joomla\String\String or \Joomla\Registry\Registry classes). In 3.4, the phputf8 library is no longer loaded from libraries/phputf8 by the core platform but rather from libraries/vendor/joomla/string/src/phputf8 by the Framework code (and JString was refactored to extend \Joomla\String\String which loads the phputf8 library).

Closing

So just to give a little more detail into the inner workings (all this is based on a front-end request cycle)

In 3.3.6, in the application constructors JApplicationWeb::loadSystemUris() is called upon which makes use of JString::parse_url(), so the phputf8 library inherently got loaded while the application class is constructed.

In 3.4.0, it is actually possible (with a fresh install) for JString itself to not be called. Its new "parent", the Framework's \Joomla\String\String class does not get called until within the JApplicationSite::dispatch() method, specifically the call to its getParams() method which triggers \Joomla\Registry\Registry and within that makes a call to the String class.

For the backend on the dashboard, the first JString call is via JHtml::_('string.truncate'); within the Isis template itself (which would be after the component is processed IIRC). The namespaced class doesn't get called upon until com_cpanel manually renders the quickicon module position.

So, there is a change between 3.3 and 3.4 in that the JString and \Joomla\String\String classes are not used in the application construction and that it appears it is possible to go a complete request cycle without loading those classes, which inherently means they won't load the phputf8 library. There are two options for this:

1. The code can itself ensure the library is loaded with checks similar to https://github.com/joomla/joomla-cms/blob/staging/libraries/vendor/joomla/string/src/String.php#L38-L49. Either the libraries/phputf8 or libraries/vendor/joomla/string/src/phputf8 path can be used to load the library; it is the same code in both places (the former is kept for B/C)

2. Where practical, call methods from the library via JString. In this case, a call to JString::substr() will ensure the phputf8 library gets loaded and will properly call the utf8_substr() function.

Thank you Michael! I posted the link to this Issue tracker to Denis Dulici of Mijoshop so he knows what to do I assume

Thanks for caring!