Hi there,
I ran into an 'issue' today that gave me a "that can't be right" feeling. I know starting a module name with numeric characters is bad practice since a valid function name starts with a letter or underscore. I don't see why this should also be the case for a package name as this is (as far as my knowledge goes) only used for administrative purposes. I also know that this key should be used for grouping related modules together. In real-life i have encountered multiple projects where the package key was used to group all custom modules for a customer and the customer name was used as it's value.
As we are using Yaml files in D8 there is a difference in the usage of 007 or '007' and the second notation should not lead to any issues.
Steps to reproduce:
1. Create a custom module and set package key to '007'
2. Visit the "admin/modules" page (enabling the module is not needed)
3. See a WSOD or Error message depending on your error level
InvalidArgumentException: $string ("007") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct()
I haven't had the chance to dig deep into the code but as far is i can see now the string value from the Yaml file is presented to TranslatableMarkup->construct() as an integer, thus failing the is_string() check.
- Add 007 as the package in a test module (see system/tests/modules for many to chose from)
-
- Upload a test + patch version
- Needs review
Closed: outdated
11.0 🔥
It would make a good project for someone who is new to the Drupal contribution process. It's preferred over Newbie.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I tested this on Drupal 11.x, standard install. I used drush to generate a module with a package key of 007, as is used in the issue summary. The module successfully installed with drush and from the UI. This may have been fixed by 🐛 Module and theme names are not filtered on output. Fixed