The following post is from the Acquia Lightning blog. Acquia Lightning, “the Drupal distribution for Enterprise Authoring,” is a Drupal starter kit that enables developers to create great authoring experiences and empower editorial teams. Lightning provides users with a lightweight framework for building working solutions in Drupal. For more information, including a product roadmap, and installation instructions, check out the Acquia Lightning site.
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.
# List of additional modules to enable after Lightning is installed.
modules: { }
# A system path to redirect to once installation is complete.
redirect:
path: ''
# Optional query string parameters.
query: { }
Simply, the `lightning.extend.yml` allows site builders to define:
-
A list of additional modules to enable after Lightning has finished being installed.
-
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.