Contrib.social

Install profiles are registered as modules

Open on Drupal.org →
Created on 9 July 2012, almost 12 years ago
Updated 8 September 2023, 9 months ago

Problem

  • Install profiles can no longer be found, because they are registered as modules.

Goal

  • Properly separate modules and profiles.

Details

  • The install profile is registered as a module in {system}, so Drupal is able to invoke its hook implementations through the module system.
  • system_rebuild_module_data() manually enhances the list of all modules to tack the install profile on top of them (with a very high weight to sorta ensure that their hooks run last).
  • This makes it troublesome to look up/retrieve the install profile record/data, as well as to update it.
  • It disallows the system from having multiple profiles that inherit from others (like base themes).

Proposed solution A

  1. Instead of this hack, adjust module_invoke_all(), module_implements(), drupal_alter() and friends to check and invoke hook implementations in the install profile, and invoke them after the module implementations.

Proposed solution B

  1. Remove hook implementation support entirely for install profiles and turn them into own, first-class extension types, which do not participate in the system at normal runtime after initial installation.

    • Many people argue that install profiles should be nothing else than configuration in the first place.

      With the new configuration system, almost all PHP code in an install profile's hook_install() will move to configuration files in a ./config/ subdirectory.

    • If an install profile needs or wants to do something a module can do, then it should ship with a module.

      There's really no reason at all for why the code needs to live directly in the profile.

Related issues

🐛 Bug report
Status

Active

Version

11.0 🔥

Component
Extension  →

Last updated 3 days ago

No maintainer
Created by

🇩🇪Germany sun Karlsruhe

Live updates comments and jobs are added and updated live.
  • API change

    Changes an existing API or subsystem. Not backportable to earlier major versions, unless absolutely required to fix a critical bug.

  • API clean-up

    Refactors an existing API or subsystem for consistency, performance, modularization, flexibility, third-party integration, etc. May imply an API change. Frequently used during the Code Slush phase of the release cycle.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇺🇸United States smustgrave

    Wonder if this. ticket can be closed for 🐛 When installing a profile module it incorrectly gets added to the module list with type module Needs review as they have a patch over there.

  • Comment 9 months ago →
    🇦🇺Australia taggartj

    For me in 10.1.3

    I had to do something like this
    in Drupal\Core\Extension\ExtensionList ....

    was upgrading but drush cr was not working / throwing an error 

    
public function getPathname($extension_name) {
........
// If we make it here were not doing so good.
    if ($this->type === "profile") {
      //dump($this->getPathnames());
      $module_list = \Drupal::moduleHandler()->getModuleList();
      if (!empty($module_list[$extension_name])) {
        $ext = $module_list[$extension_name];
        if (is_object($ext)) {
          return $ext->getExtensionPathname();
        }
      }
    }
    throw new UnknownExtensionException("The {$this->type} $extension_name does not exist.");

    just incase you see "The profile X does not exist."

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024