Nine months ago, I was given the opportunity to work full-time on creating a new distribution for Drupal 8. I was also lucky enough to be granted a full-time developer to help me. (Incidentally, that developer turned out to be the most competent and creative php developer I've had the pleasure to work with.
It seems like an arbitrary timeline (29 June to 13 July) but I give my internal update every other Wednesday, so I thought I'd share it with the larger community.
Normal Workflow Most Drupal properties can be built iteratively and deployed as a living product. The workflow generally looks something like:
We have formalized the process we use to determine what constraints we put on the versions of dependency in Lightning. Or goal is to be flexible, but predictable and stable:
The Lightning and Demo Framework teams plus Acquia's Professional Services team have been spending some time thinking about how we expect site builders to extend Lightning.
We released RC4 yesterday in response to the release of Drupal 8.1.1. In addition to updating core, RC4 also includes the following:
Release notes Update core to 8.1.0 Update all contrib modules to their latest releases Certain modules and Drupal Core will now automatically update to the latest non-breaking release as they become available for composer-based installs. 2702009 - Fixed PHP notice about undefined title index. 2695727 - Fixed an improperly namespaced hook function. 2708609 - Fixed an issue where Entity Embed did not respect the Media Library button implemented by Lightning Media. 2688427 - Implemented a fix in Entity Embed where capti
Some webhosts won't let you run composer. Others don't give you command-line access at all. In these circumstances, you'll need to commit your dependencies to your VCS. To be clear, neither I nor the Composer docs recommend this. But if you must, these tips might help. 1. Remove everything from your .gitignore The .gitignore file that ships with Lightning Project intentionally ignores the folders that Composer uses for dependencies. You'll need to remove everything from that file with the exception of /docroot/sites/default/files line.
Release notes Updated core to 8.0.6. We also lowered the specificity on core releases for Composer-based installs. Core will automatically update to the latest Patch Release when composer update is issued regardless of whether there is a new release of Lightning.
In commit 6a23801 Lightning introduced a 710k (!) patch that we apply to Panels. What's more, the patch file itself doesn't live in the Panels issue queue - it actually lives in the Lightning's. I'm sure you're wondering why :) Background This all started when we discovered that Composer does not allow us to pull specific commit hashes in dependencies of dependencies. So, first: why would we want to pull specific commit hashes instead of tags?

Powered by Drupal Lightning