/core/lib/Drupal/Core/Plugin/Discovery/AnnotatedClassDiscovery.php converts module names to lowercase in getProviderFromNamespace(), which causes any modules named with uppercase characters to not match the file system name on case-sensitive file systems.

Our test case has been using blocks. When the module name uses uppercase characters the block will not load. Once renamed to all lowercase it loads. Hooks in the .module file work fine regardless of case. This issue only applies to code that relies on the annotation discovery.

What I've seen so far is that this was added in https://www.drupal.org/files/issues/2294177.1.patch for issue https://www.drupal.org/node/2294177 . The issue is discussing the need to change "Core" to "core" in entity config, however this patch affects all modules and not just the places in core that needed to be changed. The final comment mentions that it is a hack, but was approved to get to beta.

I propose adding an if to check for "Core" and only changing that to "core", while allowing all other modules to retain their proper casing. I've been testing with this change since 8.3.x and it has been working for us.

Comments

ASA DBank created an issue. See original summary.

cilefen’s picture

Title: Custom modules only partially functional with uppercase characters in module name » characters in module name
Category: Bug report » Feature request

Is this about the machine name having different letter casing from the module directory name? If so, what would the use-case be?

cilefen’s picture

Title: characters in module name » Custom modules only partially functional with uppercase characters in module name

Whoops

cilefen’s picture

Machine name requirements are documented, if that’s relevant: https://www.drupal.org/docs/8/creating-custom-modules/naming-and-placing...

ASA DBank’s picture

"Note that it is not necessary to use the same name for your module's folder as your machine name. You could, for example, use the folder name HelloWorld instead. "

We've always named the files to match the folder, and so the .info.yml file had uppercase characters. The module itself is listed and can be enabled, even when using camelCase naming of the files. Changing the file name to all lowercase did allow the block to show up to be added. If the info file was misnamed, then we would not have expected the module to be in the module list nor to be enabled without any errors.

"Important note: Be sure to not use upper-case letters in your module's machine name as Drupal will not recognize your hook implementations."

In my testing I had hook functions working, even with uppercase characters in their name ("myPrefix_myExampleModule_form_alter"), as long as the .module file was all lowercase.

I'm also very curious as to the reason for the switch to requiring all lowercase naming. What I have tested all works fine with uppercase characters, once I removed the line that converted all names to lowercase (note: all above testing is done on unaltered core, separate testing was done with this change). I have not been able to find any explanation for why Drupal is now requiring all lowercase naming.

The reason we are questioning this is that we have hundreds of custom modules to convert to Drupal8, all of which have been named with a mix of camelCase and underscores ("myPrefix_myExampleModule"). All of the custom code follows this naming convention. Having to follow different naming for these files and hooks is likely to lead to typos from habit. I doubt we are the only ones using camelCase and it seems like there would need to be a really good reason to add such a limitation.

Berdir’s picture

There was no switch really, non-lower-case module names never worked 100%, one example is update functions. Maybe you didn't have that use case for your custom modules but it's a pain.

I don't really think we should introduce support for that, if anything, we should more strict in validating it and disallow to enable such modules, but I guess that would break existing sites. Maybe log a warning message or so and hard break for 9.x?

ASA DBank’s picture

No, we have never seen any issues due to camelCase naming of modules before D8. D8 is the 1st I'm seeing this listed, though it has been a while since I read over all the D7/6 docs and we've used camelCasing throughout, so it is possible we missed it and it just worked.

D8 could definitely use with better validation and notifications throughout. If file naming does require all lowercase to function, then those not following this should not have been listed or allowed to be enabled and warnings being generated would be very helpful for now. I agree that implementing a change to completely block these would need to wait for a later version to not break existing sites, but displaying warnings on the list of modules would be good to ensure it is seen before any new modules with the uppercase characters are enabled. We had several fully functional modules using camelCasing before we ran into this issue with the 1st that used blocks. I can confirm that if the info file is named with camel casing, then the module file can use it as well and all the hooks we have used do work in that file with camelCased function names. The Extend page does list the machine name with uppercase characters for these.

Personally, I'd prefer the bugs related to uppercase characters be fixed, rather than removing support for them, but it sounds like this has been an ongoing issue for some time and that is not likely to happen. Since the code we are working with uses camelCasing, that is what we are used to, and it is likely we will have some camelCased names slip through. Better validation and warnings about any modules that have machine names with uppercase characters would be a major help in catching these.