Lightning as a Base Profile - acquia/lightning GitHub Wiki

If any of the following are true, you should create a sub-profile of Lightning:

  • You want to prevent some component or subcomponent of Lightning from being installed.
  • You want to enable additional modules, themes, or configuration during install.
  • You want to customize the look and feel of the installation process.
  • You want to build a distribution that offloads things like Media, Layout, and Workflow to Lightning.
  • You previously used lightning.extend.yml to accomplish any of the above.

Generating a new sub-profile

For simple use cases, where you just want to exclude some of Lightning’s components or include a few of your own, you can use the Lightning-provided sub-profile generator. The generator is also a good starting point for more complex sub-profiles.

To run the generator:

$ drupal lightning:subprofile

Requirements:

  • DrupalConsole
  • Core patch (included in Lightning 2.0.4)
  • An installed instance of Lightning or Drupal

Converting lightning.extend.yml into a sub-profile

$ ./vendor/bin/lightning-subprofile /path/to/your/extend/file/lightning.extend.yml name_of_subprofile

Note: The path to your bin directory is set in your root composer.json file and might be different.

Requirements:

  • DrupalConsole
  • Core patch (included in Lightning 2.0.5)
  • An installed instance of Lightning or Drupal

Switching an existing site’s install profile from Lightning to a sub-profile

Generally, there isn't a need to do this once a site is installed. But for some cases, especially where legacy sites are running on the same codebase as new sites, or where the developer wants to take advantage of packaging their modules into a sub-profile, it might be desirable to switch to a sub-profile.

Switching an existing site’s install profile from Lightning to a sub-profile

Generally, there isn't a need to do this once a site is installed. But for some cases, especially where legacy sites are running on the same codebase as new sites, or where the developer wants to take advantage of packaging their modules into a sub-profile, it might be desirable to switch to a sub-profile.

  1. Add/update the install_profile in settings.php:

    $settings['install_profile'] = '[SUB-PROFILE_NAME]';

  2. Run the following command to enable the profile:

    drush cset core.extension module.[SUB-PROFILE_NAME] 0

  3. If you use CMI/have the core.extension.yml exported, export the updated extension listing to file.

Architectural differences

Previous versions of Lightning (ones that included the lightning.extend.yml file) installed modules in a specific order: core modules, lightning modules, extend module. And extend modules were always installed in the order that they were listed in the extend file.

Lightning now defers to the core install system to determine when modules get installed. So you cannot rely on all of Lightning’s modules being installed by the time your additional dependencies are installed. Furthermore, by design, optional config isn’t installed until the very end of the installation process. So any attempt to modify optional config should come in hook_ENTITY_presave rather than hook_install or similar.

A quick-fix for this is to remove the dependencies from your subprofile.info.yml file, and move them into an install hook in your sub-profile’s install file. For example:

$modules = [
  'mymodule',
  'foo',
  'bar',
  // ...
];

foreach ($modules as $module) {
  \Drupal::service('module_installer')->install([$module]);
}