Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.For a first time reader,
it is not clear that the 'webprofiler' directory is a submodule.
PSR-4 makes this semantically obvious by insisting that we place webprofiler under a module directory, within the module.
Response 3 from the following link makes this clear.
https://drupal.stackexchange.com/questions/142248/sub-folders-and-how-to...
I am about to move the following submodule
devel_generate
kint
webprofiler
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | rename-2812935-2.patch | 52.92 KB | martin107 |
| |||
Comments
Comment #2
martin107 CreditAttribution: martin107 as a volunteer commentedThis patch is nothing more that a series of renames.
This patch will will be disruptive...
for example it will cause a conflict with
https://www.drupal.org/node/2841689
Please email me and I will we be available to reroll any patches that get affected by this issue.
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedMeh. Dont see much benefit to to further nesting. Seems to contradict https://www.drupal.org/docs/develop/coding-standards/composer-package-na.... I do know that a few modules nest as you have proposed.
Comment #4
martin107 CreditAttribution: martin107 as a volunteer commentedI will lets others makes the decision - I just want to provide a few more perspectives.
I admit the benefit is small - I just want to push everything in the direct of the PSR complaint way to doing things - it will take time to see the benefits.
it is just I want every php developer to immediately feel familiar with a new project.
I dont want to comment about performance gains, without hard evidence, but Drupal8 and hence Devel can be viewed a symfony apps.
So Symfony performance tips and tricks can be applied.
The article below suggest there are benefits to preventing the autoloader from iterating over all configured namespaces to find a file - by running
http://symfony.com/doc/current/performance.html
The flag module did something similar - To speak against my position - It was pre alpha when we decided to move the sub modules into this directory structure. ( Flag still is pre-alpha! )
#2812935: move submodules to a /modules folder
Comment #5
willzyx CreditAttribution: willzyx commentedI don't see an hard evidence of the contraddiction in the linked documentation.. and a lot of modules are doing that. Here some examples from the top installed modules: ctools, redirect, paragraphs, display suite, features, entity browser and so on..
+1 on moving all submodules in the /modules folder. IMHO it is a good thing and give to the project a better organization. I thought many times to do so... but probably moving modules around is not a good idea for BC and we cannot commit this patch in the 8.1.x branch. I think that this is Devel 8.2.x material
Comment #6
lussoluca+1 also for me in 8.2.x
Comment #7
martin107 CreditAttribution: martin107 as a volunteer commentedI am not ignoring the fact that we do not have 100% consensus.
but IF we do decide to do this delaying until 8.2.x seems like a good idea.
In other projects a "Release 8.2.x blocker" tag would be appropriate here, but I am relatively new to this project.....
1) I am just linking to the 8.x-1.0-beta2 plan - just because, in the fullness of time., that seems a useful measure of when a 8.2.x version might become a reality
2) For me the all submodule can be enabled without problem - but I am starting a test run - just because I want to identify problems early.
Comment #8
moshe weitzman CreditAttribution: moshe weitzman commentedAn alternative (if drupal allows it) would be to put the main module, devel, in a subdir too. This isolates devel better and fixes https://github.com/drush-ops/drush/issues/4044. The layout would be:
PROJECT
- devel
- devel_generate
- webprofiler
We are about to open 3.x branch to is a good time for this.
Comment #9
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedAs this comes under coding standards and best practice I've added it to the parent issue #3081785: [meta] Devel 8.x coding standards messages
Comment #10
fgmFWIW, the upgrade path from one layout to the next in the case of such a change would be problematic and involve uninstalling/reinstalling.
That may not be too bad since devel and its submodules are dev tools anyway, which shouldn't remain enabled, but still.. if a release changes its file locations, core will try to look for it in its previous location and won't by default find the new one correctly, throwing errors during the upgrade.