Problem/Motivation

Given a namespace or class name (e.g., Drupal\Component\Foo\Bar, Drupal\Foo\Bar, Drupal\foo\Bar, or Foo\Bar), how do you know if it corresponds to a name within a Drupal extension's namespace (i.e., Drupal\$module as added in DrupalKernel::getModuleNamespacesPsr4() or Drupal\$theme as added in ThemeHandler::addTheme())?

A use-case for wanting to know this came up in #3120096: Support contrib database driver directories in a fixed location in a module, where given a Drupal database driver's namespace we want to know if it's within the namespace of a module (as opposed to within Drupal\Driver or Drupal\Core or elsewhere).

Proposed resolution

Add a public static method Extension::isWithinExtensionNamespace($namespace_or_class_name) (TBD: discuss name of method, name of parameter, and if it belongs in the Extension class or elsewhere).

Option 1

Implement the logic based on whether the second-level namespace is all lowercase, as extension names are expected to be. This distinguishes extensions from other kinds of things that can occupy the second-level namespace, such as "Core" and "Component", and reserves the ability to arbitrarily add more non-extension namespaces within Drupal\ so long as they start with an uppercase letter.

Option 2

Since PHP namespaces are resolved in a case-insensitive way, don't rely on case, and instead hard-code a list of names that are not extensions. This needs to include "Component", "Core", "Driver", and possibly others. Assume that everything else is an extension name, which means no one outside of Drupal core can invent new names within Drupal\ that don't correspond to what Drupal defines as an extension: a module, theme, theme engine, or profile.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

effulgentsia created an issue. See original summary.

effulgentsia’s picture

effulgentsia commented
Issue summary: View changes
effulgentsia’s picture

effulgentsia commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

Repeating some of my comment on #3120096-118: Support contrib database driver directories in a fixed location in a module because it's relevant.

I'm still not 100% convinced given I'm not sure we should add the API #3125476: Add an API for determining whether a given PHP namespace or class name is within the namespace of an extension - in an ideal world we would not have to any of this and use composer 100% for class loading. Doing composer require drupal/MODULE and that not affecting the class loader is very surprising to PHP developers coming from Symfony and other frameworks. But in order to fix that we have to revisit what installing a module is... so not a lot of appetite for that. But at least if this is private and we deprecate and then remove db connections as URLs we can inline this again.

I think before we add this we should identify at least one place in core that requires this functionality.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

Looking for preg_match.*Drupal in core...

  • We have \Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery::getProviderFromNamespace() that very interestingly does an mb_strtolower() on the module part. This is because we want the provider to be core when a plugin is located in \Drupal\Core\...
  • Only instances are test namespace manipulations that would not benefit from this API

The only instances of exploding on \\ seem to be in tests and not to do with modules.

I'm not sure that adding an API is worth it. However if it is I think creating a DrupalNamespace value object is the way to go. The constructor should take the namespace string and error if it doesn't start with Drupal\. And it should have methods like getProvider() and isModule() etc...

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

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.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.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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: 10.1.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, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

nicxvan’s picture

nicxvan commented
Status: Active » Postponed (maintainer needs more info)

Postponing because I agree with 4 and 5 and in 6 years there doesn't seem to be any new use cases identified.

I'll leave this open for a bit in case I'm missing something.

nicxvan’s picture

nicxvan commented
Status: Postponed (maintainer needs more info) » Closed (outdated)

I think this is safe to close at this point, if we decide it's needed later we can always reopen our create a new issue.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.