Problems/Motivations

The lib/Drupal// convention is not suitable for everything, so the programmer has the option to change himself the namespace of its registered classes. This is easily done by the following snippet:

<?php
$loader = drupal_classloader();
$loader->registerNamespace('MyFancyNamespace', DRUPAL_ROOT . '/' . drupal_get_path('module', 'myfancymodule') . '/lib');
?>

This is pure glue code which is not fun to write and maintain, we could make it sexier, by allowing programmer to specify its namespace directly within the .info/yaml file.

Moreover, if you change all your modules namespace, it feels we are adding execution time because the original routine for registering namespace depends on module_list(). We can improve it.

Proposed resolution

Writing the namespace as following in the module's .info file:

name = My fancy module
description = My fancy description

namespaces[Drupal\user] = /lib
prefixes[SOME_PEAR_PREFIX] = /lib
namespaces[Symfony\Component\HttpFoundation] = /vendor

This make sense because we don't have to allocate a hook_init() for defining new classes. We can also re-factor the registering routing so that it register only the namespace needed and not the list of enabled modules, plus the custom namespaces which will overwrite default defined namespaces.

Comments

Sylvain Lecoy’s picture

My question is: Is there any variables/objects/functions storing/caching somewhere the .info content or this is something I have to imagine ?

Sylvain Lecoy’s picture

Following #1400748: Proposal for unified namespace organization's Crell comment on info files:

$moduledir/+ - A module may specify additional namespaces to register via its info file. These may map to any directory within the module except the $moduledir itself, $moduledir/lib, and $moduledir/tests.

I guess its a duplicate ?

Sylvain Lecoy’s picture

Also found in #1290658: Move all module-provided classes to PHP namespaces (PSR-0 or similar), and autoload them without the registry [policy, no patch]:

namespaces[Drupal\user] = /lib
prefixes[SOME_PEAR_PREFIX] = /lib
namespaces[Symfony\Component\HttpFoundation] = /vendor

What happened to this ?

Sylvain Lecoy’s picture

Trying writing a patch, I can see we are too early in the bootstrap to have the module enabled list, and that the gathering of enabled info files is expensive.

What about dumping then the autoloader or a sort of compiled version of all namespaces which is re-written on module update/disable ?

Sylvain Lecoy’s picture

While thinking about another problem, which is the declaration of a special dependency for a module. For instance, when a module depends on Services 3.x or Views 3.x, instead of adding the version dependency on the .info file (@see http://drupal.org/node/542202#dependencies), they do it by a hook. Usually something like hook_version_api(). I believe they are not doing it because of their lack of knowledge that this functionality exist but more because they need more functionalities (for specifying additional metadatas).

Because loading .info files on each request is not interesting, why not introducing some kind of .INFO APIs (read-only) which will allows more flexibility for the programmer, I think this issue can be a good use case, and the hook_api_version another good one.

Sylvain Lecoy’s picture

Issue summary: View changes

copy.

Sylvain Lecoy’s picture

Issue summary: View changes

Updated issue.

Sylvain Lecoy’s picture

Issue summary: View changes

.info/yaml

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.