TYPO3 Core

Change was introduced with https://git.typo3.org/Packages/TYPO3.CMS.git/commit/0f953132194ace4926e2daa23499c9c51d1cbe23

The function ucwords transformed all class names to uppercase

--- a/typo3/sysext/core/Classes/Core/ClassLoader.php
+++ b/typo3/sysext/core/Classes/Core/ClassLoader.php
@@ -337,9 +335,7 @@ class ClassLoader {
                        } else {
                                $classesPath = $this->packageClassesPaths[$extensionKey];
                        }
-                       // Naming convention is to capitalize each part of the path
-                       $classNameWithoutVendorAndProduct = ucwords(strtr($classNameWithoutVendorAndProduct, $delimiter, LF));
-                       $classFilePath = $classesPath . strtr($classNameWithoutVendorAndProduct, LF, '/') . '.php';
+                       $classFilePath = $classesPath . strtr($classNameWithoutVendorAndProduct, $delimiter, '/') . '.php';
                        if (@file_exists($classFilePath)) {
                                return array($classFilePath, $className);

Hi Jonas,

Jonas Renggli wrote:

old behavior:
both kind of references (e.g. in userFuncs) were possible:
'tx_myext_myclass' and 'Tx_Myext_Myclass'
there's no ext_autoload.php necessary

In old behavior you specified the class path (e.g. in userfunc) so the class loader (previously named autoloader) was not triggered at all.
Since getUserObject or callUserFunction required the class file manually and then instantiated the the class everything was fine, as class names
in PHP are case insensitive.

It also worked (and still works) in ext_autoload.php as a class path is directly specified for a class name.

new behavior:
the class has to be referenced as 'Tx_Myext_Myclass' in uppercase

New behavior is, that you do not need to specify a path to a class if you follow the naming conventions.
Naming convention is, that you need to specify your class correctly (in the same casing as the file path).

If you don't like it, you can still require files manually or provide a ext_autoload.php
Then you can use arbitrary casing as you like.
Alternatively you can use a case insensitive filesystem (more below)

Change was introduced with https://git.typo3.org/Packages/TYPO3.CMS.git/commit/0f953132194ace4926e2daa23499c9c51d1cbe23
The function ucwords transformed all class names to uppercase

True. This basically reverted the commit done here:
https://review.typo3.org/26999

The real cause of Xavier's problem, however was different and was fixed later on with https://review.typo3.org/27079

Let me explain why I think that automatic class loading without specifying a class path cannot work on case sensitive file systems:

1. Think of a class named Tx_MyExt_MyClass (which is btw. the convention, not Tx_MyExt_Myclass as class and ext are new words). If you now try to instantiate the class name tx_myext_myclass, two important parts of the information is lost:
   1. The extension key is in fact "my_ext" not "myext". The class loader however cannot "know" that and searches for an extension/package "myext" and fails to find the class
   2. The class file of this class has the following relative path "typo3conf/ext/my_ext/Classes/MyClass.php" How should the class loader "know" that the file name of the class is "MyClass.php" and not "Myclass.php" or "MycLAsS.php"? The class loader can only assume that it is myclass.php as it is the last part of the class name. This would still work on case insensitive file systems (while the above case with the wrong extension key would not)
2. Think of a class named \Vendor\Myext\MyClass
   1. This is a totally different issue, which I don't see how it can be easily fixed as looking for a class named tx_myext_myclass would correctly find and require the file on case insensitive file systems and also require the file again, when looking for the real namespaced class name with correct casing (this is what Xavier ran into) and I filed a bug for it: #55418

Without scanning all classes directories of all active extensions and parsing the php class files in there, all these issues are not fixable, at least I do not know how. If you have an idea I would greatly appreciate it.

Why did I revert https://git.typo3.org/Packages/TYPO3.CMS.git/commit/0f953132194ace4926e2daa23499c9c51d1cbe23 ?

I reverted it, because it only "fixed" one edge case and not all the cases I mentioned above. I think it is better to be consistent in enforcing naming conventions for every single class than to fix some edge cases automatically but fail in other relevant cases. Besides that, it has always been like that (afaik, if you can show me a different example for older TYPO3 versions, I might reconsider some things).

This is my reasoning. Although I find it quite logical, I'm still interested to be challenged on that. So if you have more or other information than presented here, or have good arguments why and probably also ideas how to change the current behavior, I would be very interested to hear about.

No feedback within the last 90 days => closing this ticket.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.