Installing a site with existing config has been a bit of a moving target in Drupal 8. At different times, I've recommended at least three different approaches. I won't go into too much detail, but basically we've used the following at times:
Under certain circumstances, it might be necessary to build a specific version of Lightning with dependencies exactly as they were when it was released. But sometimes building older versions of Lightning can be problematic. For example, maybe the older version assumes an older version of a dependency, or a patch no longer applies with an updated dependency.
The second of two major migrations this quarter is complete! Lightning 2.2.4 will migrate you off of Workbench Moderation and onto Core Workflows and Content Moderation. (See our blog post about Core Media, our first major migration.)
The migration was a three-headed beast:
This post was originally published on Medium.
Ah, the config system. Crown jewel of Drupal 8, amirite?
Well, yeah, it’s fantastic and flexible (as is most of Drupal). But if you have advanced use cases — such as building a system that alters config dynamically — there are traps you should know about.
- UPDATE 2/2/2018 -
See: Using the Configuration Installer with Lightning
Throughout the development and support lifecycle of a site, it is often necessary to install a fresh version of your application in a new environment with all of the existing site's configuration. For example, a new developer might need to set up their environment for the first time or your CI system might want a fresh install for tests. Basically:
Lightning 2.1.7 includes a new top-level component: Content API. Its purpose is to provide a very basic server-side framework for building decoupled apps using Lightning as a backend. It has no strong opinions about how the "front-end" of such an application is implemented -- out of the box, it merely provides tools to deliver Drupal entities according to the JSON API specification.
We started receiving reports of broken Lightning builds due to the release of doctrine/common:2.8.0 and/or doctrine/inflector:1.2.0 which require php ~7.1 and php ^7.0 respectively.
Lightning actually doesn't have a direct dependency on anything under the doctrine namespace. The dependencies come from drupal/core. So should drupal/core constrain doctrine/common to <=2.7.3 so that it continues to support php 5.6? No.
If you follow the dependency tree for what happens when you run composer update for a Lightning project in a php 5.6 environment, it looks like this:
In Lightning, Editors have always been able to choose a specific Image Style to use when embedding images in content with CKEditor, but it required quite a bit of setup by the site builder. Specifically, the site builder needed to create a view mode for each image style and then configure the view modes so that they would display the appropriate image style. Those view modes were then exposed as display plugins to Entity Embed. So the site builder then needed to configure the Media Browser embed button to allow those display plugins.