Extending OOTB experiences with Lightning

Normal Workflow

Most Drupal properties can be built iteratively and deployed as a living product. The workflow generally looks something like:

All configuration must be exportable, but the configuration doesn’t necessarily need to be enabled at the end of the install process.

OOTB Business Requirements

Sometimes, business requirements dictate the need to provide a specific, unique out-of-the-box experience. In other words, they need the ultimate result of the iteration loop above to be integrated into a repeatable build - often through the install UI. This is exactly what Profiles are for:

“Installation profiles provide site features and functions for a specific type of site as a single download containing Drupal core, contributed modules, themes, and pre-defined configuration.”

This poses a problem for users of Lightning and other distributions in that the Lightning Distribution provides its own profile - occupying the layer of OOTB customizations that Drupal provides.

The ultimate solution

Ultimately, many in the community (including me) would like to see Profiles behave in a way that is similar to Themes. Specifically, I’d like to have the hierarchical parent -> child relationships that are possible with themes. In fact, we’ve been talking about how we could “Allow profiles to provide a base/parent profile” for five years. But that issue is unlikely to be resolved any time soon. (Unless, of course, you’re a Drupal samurai in need of a project...?)

The interim solution

In the interim, Lightning has provided a way for Site Builders to “Extend” the OOTB experience via configuration contained in a `lightning.extend.yml` file, which Lightning provides in its codebase:

# Defines additional tasks for Lightning to perform during and after site
# installation. Place this file in your Site Path (e.g. /sites/default or
# /sites/SITENAME) or /sites/all directory for it to take effect.

# List of lightning Extensions enabled when Lightning is installed. The presence
# of this key will disable the Lightning Select Extensions form. If you want to
# allow users to choose which Lightning Extensions should be enabled during
# installation, comment out the following lines.
  - lightning_workflow
  - lightning_layout
  - lightning_media

# List of additional modules to enable after Lightning is installed.
modules: { }

# A system path to redirect to once installation is complete.
  path: ''
  # Additional options to pass to the URL generator.
  options: { }

Simply, the `lightning.extend.yml` allows site builders to define:

  1. Which Lightning Extensions should be enabled.

  2. A list of additional modules to enable after Lightning has finished being installed.

  3. A path that users should be redirected to after installation of Lightning and the additional modules is complete.

This allows Site Builders to do things like change the theme, define new content types or other entity bundles, and enable Feature modules. Basically, it gives site builders the ability to override, delete, and add to the configuration that Lightning ships with during the installation process. Much in the way that profiles allow Site Builders to do the same to Drupal Core via Profiles.

We’ve created an example implementation of Lightning Extend called “Acme Lightning Extend” which does the following:

  • Enables the Acme Custom module, which:

    • Sets a new theme

    • Deletes the content types that ship with Lightning

  • Enables the Features module and activates the following Features:

    • Lightning Settings: Disables Lightning's auto-creation of roles

    • Product: Creates a Product content type and associated taxonomy

    • Theme Settings: Defines some settings for the Acme theme

  • Redirects the user to a custom messaging page

We hope that this solution will enable Site Builders that have specific OOTB experience Business Requirements to still take advantage of all that Lightning has to offer.

Powered by Drupal Lightning