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

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Issue summary: View changes

Updated issue summary.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Issue summary: View changes

Updated issue summary.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Issue summary: View changes

Updated issue summary.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Issue summary: View changes

Updated issue summary.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

I clarified the impact of CMI on install profiles (in proposal B).

FWIW, I'd strongly prefer proposal B, since it allows us to remove tons of hacks and keep the architecture clean.

Essentially, proposal B degrades an install profile to a simple "pointer" to a (site) directory in which further modules/themes may be found. If that pointer or the directory happens to vanish - e.g., because the subdirectories have been moved into sites/all/* - then nothing bad happens — the system remains to stay functional and operable.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Issue summary: View changes

Updated issue summary.

catch’s picture

catch
he/him
Primary language English
commented

I added two more issues to the summary.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Turning installation profiles into modules in D7 was an important DX improvement, IMO. They were special "thingies" in D6 and earlier and really difficult to work with. They need a way to declare dependencies, to perform tasks on install, to alter the forms during registration and add/change/remove fields, etc. All of which are things modules do. Why should I have to learn two different ways to do the same things?

At the very least, if we're going to go with option B, an analysis should be done of the top 20 or so distros and find out if it's actually true that "almost all PHP code in an install profile's hook_install() will move to configuration files in a ./config/ subdirectory." I have my doubts.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Well, we can happily inject some special code like the following into the Drupal installer:

// Allow the install profile to participate as fake module during
// the installation process.
$modules[] = //...
$modules[] = array('name' => $profile, 'filename' => drupal_get_path('profile', $profile));
module_list(NULL, $modules);

... or even more custom and less hacky:

// Invoke hook_form_alter() in the install profile.
$profile = $install_state['profile'];
$function = $profile . '_form_install_configure_form_alter';
if (function_exists($function)) {
  $function($form, $form_state);
}

... plus probably a dozen other possible ways to achieve the same.

But the important part is:

That's a one-time hack/operation for a clearly defined scope. — We do not continue to support a hack that's an architectural disaster for the entire lifecycle of a Drupal site.

catch’s picture

catch
he/him
Primary language English
commented

At the very least, if we're going to go with option B, an analysis should be done of the top 20 or so distros and find out if it's actually true that "almost all PHP code in an install profile's hook_install() will move to configuration files in a ./config/ subdirectory." I have my doubts.

Everything that can't, can go in a profile-specific module that ships with the distribution no?

There are many, many places in core, where we have special casing of profiles to avoid them actually working like modules, those need to go.

dkl4’s picture

dkl4 commented

For background, see the following issue which I believe changed profiles into "full modules" :

Install profiles should be modules with full access to the Drupal API and all it entails(.install files, dependencies, update_x)

http://drupal.org/node/509398

dkl4’s picture

dkl4 commented
Issue summary: View changes

Adding two issues to summary.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Component: base system » extension system
Parent issue: » #2186491: [meta] D8 Extension System: Discovery/Listing/Info
andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue tags: +Needs issue summary update

needs update about current state of modules storage and hook invocation

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.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Version: 8.3.x-dev » 8.4.x-dev

Beta is too close

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 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.

quietone’s picture

quietone commented
Related issues: +#1356276: Allow profiles to define a base/parent profile, +#562042: Search for install profiles in sites/[all|site]/profiles folders, and move core profiles into /core/profiles, +#1242956: Allow install profiles to be switched, +#689396: The install profile is sometimes referred to as a module during installation, +#820054: Add support for recommends[] and fix install profile dependency special casing, +#1170362: Install profile is disabled for lots of different reasons and core doesn't allow for that

Happened to find this after looking at one of the related issues in the IS. Adding those issues to related issues.

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.

quietone’s picture

quietone commented
Issue summary: View changes
Related issues: +#2595663: When installing a profile module it incorrectly gets added to the module list with type module, +#3266057: Allow profiles to define a base/parent profile [continue of #1356276]

Found another related issue

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.

smustgrave’s picture

smustgrave commented

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

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.

taggartj’s picture

taggartj commented

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."

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

nicxvan’s picture

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

Although this is older the other issue has a patch.

I think we should close this one as the duplicate.

#2595663: When installing a profile module it incorrectly gets added to the module list with type module

I'll leave this open for a bit in pmni in case others think we should close the other one.

smustgrave’s picture

smustgrave commented

Makes sense to close this one to me.

quietone’s picture

quietone commented

After reading the comments here I am not sure this should be closed as a duplicate. The implementation in the patch in #2595663: When installing a profile module it incorrectly gets added to the module list with type module goes against what is recommended in #5. Also, this issue has provides some history, and links, to why profiles are treated as modules.

nicxvan’s picture

nicxvan commented

Thank you @quietone, I'll take a closer look.

I am not sure what you mean by 5 do you mean not removing the special casing?

We do want to do that and preserve the info, I think the goals are pretty close in the two issues.