Lightning is a distribution of Drupal 8 developed by Acquia which attempts to deliver a preconfigured and optimized out-of-the box experience.
The installation via Composer is smooth and setting up the site with the default profile is all that is necessary. Nice.
You get a site which provides you with Panels via Panelizer, Media management via media and entity browser as well as moderation via Scheduled Content and Workbench Moderation.
On the other hand, I'm surprised not to see Paragraphs here and the reliance of media embedding in rich-text components seems inelegant. Also power-user essentials, such as Admin Toolbar, are lacking.
Lightning provides a very nice showcase on how you can easily upload and reuse assets with the entity browser.
I look forward to using that in future projects, though its still odd that there is barely any documentation on organizing or segmenting asset management there.
Apparently, Views will need to fill that gap, but I hope future improvements here will set a greater focus on image pools, as easily accessible as now but with more fine-grained controls, when you can't trust your editors to do the right thing.
Until the 8.2 merge of Workbench moderation as "Content Moderation" I was not certain which access control suite might come out on top for 8 but Lightning seems to have had the right idea.
What is surprising is that the experience of scheduled content is rather grim in terms of workflow states and publishing processes. The user does not have any good feedback what version is currently published, how to go about modifying them, nor do additional pending states seem to work at all out of the box. That needs lots of work and is a major weak point compared to the usual enterprise CMS offerings, which I had hoped Lightning would have a better answer to.
Lightning is a great demo case to show how Drupal 8 is in many ways a different ecosystem than 7 and what it can do but I would not necessarily choose it as a base distribution since it's not hard to take a look at their example and tailor your site to your actual needs.
When I got started on my migration to Spress I figured that I would just run the site on a generic hoster that also offers letsencrypt certificates. Turns out, there really wasn’t any hoster who came close to the $7 DigitalOcean VM. So, AWS it is.
Specifically, deploying to S3, letting it do the static site hosting and putting CloudFront in front (haha) of it to handle HTTPS.
I had a terrible time getting letsencrypt-s3front running on OS X, mostly due to problems with Python and build dependencies. When I ran it on a regular CentOS VM with a working letsencrypt setup, everyhting worked fine. When Docker finally runs half-way stable on my machine I plan on handing that off to an image to rerun without effort when I have to renew the certificate…
Apparently, CloudFront does not support HSTS in any way. While that’s not perfect, it’s a reasonable compromise for everything else this AWS setup can do.
If your homepage works without index.html but your posts do not, see this stackoverflow post and use the S3 endpoint URL (HTTP only) to avoid issues.
You don’t have to upload your build manually to S3, the AWS deployment plugin will do that for you. The Github documentation should suffice for setting it up (thanks to the maintainer merging my v2 support and documentation updates already).
The deploy suite is an interesting suite of modules, which makes it possible to revision content in such a way that it becomes deployable across different sites or workspaces.
Also, it makes it possible to move the CRUD model Drupal runs under into a CRAP model, which anyone will appreciate who has ever gotten a call from a customer who just deleted a dozen nodes.
To make all that possible, basically all entities need adjustments to their storage base. That is not a trivial task and especially with complex contrib modules such as ECK, Field Collections, etc. the list of problematic and complex cases rises.
Looking at the current dev state and the last release as of this writing (alpha10), many of those complex cases are not yet supported. Field collections seems broken, content translation has problems with taxonomy terms and many other minor and major bugs are present.
Also, you should beware from using multiversion since not only is enabling it tricky (migrate all content to a temp storage and back), the same applies to uninstalling and it can leave you stranded with a broken system.
This site was powered by Drupal for a full decade. It went through Drupal 5, 6, 7 and 8, but it’s outlived its usefulness in that form. I think it might have even begun as a 4.7 site.
My reasons for switching to a static site generator are quite plain but highlight my shifting needs:
Over 3/4 of posts here contain a code snippet, this is vastly easier to handle with Markdown or similar tools, than CKEditor.
The content is by all accounts static. The end-user is not rewarded through interactive features but rather burneded by the wait time of the CMS overhead. Even with the dramatically improved page cache in D8, it doesn’t come close to plain HTML.
I don’t have nontechnical users to support here.
I have enough other Drupal sites in my life to use for trying out new modules and experimenting.
I can stop maintaing a server to have things as flexible and speedy as I like, for a minor site.
And finally: All posts are revisioned in Git, without any intermediate systems.
My choice fell on Spress even though it’s not that prevalent (yet), since it uses the stack I’ve come to appreciate everywhere else: Symfony, Twig, Composer.
Converting data is straightfoward and easy. Just write a quick script to fetch all nodes and output their fields as desired.
League’s HTML-to-Markdown library easily converted CKEditor HTML with only minor corrections necessary afterwards.
Then just write it to a file with fopen/fwrite/fclose. Yes, of course that could be done more elegantly, but for a single migration it works fine.
Along the way I pruned the content back to what could still be considered tangentially relevant. I look forward to seeing if this will make posts here more frequent, as I expect, the opposite, or neither.
Today I want to highlight a solution that has become one of my favourite tools in web development over the summer: Gitlab with Gitlab CI.
I used to be a bit skeptical if a continuous integration solution would not be overkill for small projects but with configuration management in Drupal 8 and composer & composer-patches I’m a dedicated convert and would never want to go back to doing it by hand. You might think it’s just a git pull here or a cache-clear there but I'm certain that once you've tried it you don't want to go back.
Fire up a VPN and install the omnibus edition, then follow the instructions. Just make sure that you have at least 1GB of RAM and several GB of swap. I tried 512MB, you will run into issues that are not worth your time and effort.
Next you’ll need to actually define a runner, again, see the documentation for that. For my case it works perfectly fine to have the runner be a second user on that server. Since I’m using SSH later I’ll need to provide that user with a key-pair, since we need to add that to the authorized_keys of the production server.
First, you’ll need a .gitlab-ci.yml file in the repository root and that can be quite minimalistic. You can execute commands directly there but since most of what I’m doing for automated deployments is happening in an ssh session, I just wrap that in a deploy script:
set -e # We want to fail at each command, to stop execution
drush sql-dump --gzip > ../../somewhere-safe/db/`date +%Y-%m-%d-%H%M`.sql.gz
~/bin/drush updb -y
~/bin/drush cim -y
When you commit that CI file you will likely get a notification that the build is stuck. Just follow the prompts until you get to the list of runners so that you can enable it for the specific project.
Of course that could be done more elegantly in a variety of ways (maintenance mode, aliases instead of directories, etc.) but it actually works extremely well. I rarely have to touch the server anymore and adding additional steps such as unit testing and code standard validation is extremely easy with such a lightweight CI solution.