Recently I have been test driving some Drupal 8 development to get a feel for some of the new concepts and APIs that have been introduced. I find the best way to learn and get motivated about a new technology is to dive right into a fun side project, where you can be free to experiment and break things at your own leisure. You also have the advantage of selecting a set of features which touch a variety of APIs.
In this post I’ll go over the approach I took to building a Drupal 8 install profile and some of the issues I faced.
I decided to write an install profile in an attempt to keep HEAD up to date. This would allow me to replace core and reinstall my website and be more resilient to upgrade issues.
I decided to fork standard and rename it to something I could customise and build on top of. I did encounter a difficult to track down bug early on. When installing Drupal the following is copied into settings.php:
$settings['install_profile'] = 'PROFILE_NAME';
If you change profile from “standard” to “your custom profile” and you don’t delete your original settings file, your new profile will install successfully, but after installation core will have a strange mixture of behaviours around which profile is referenced (in my case, modules were being loaded from the old profile, but the new profile was installed).
I updated my build script to delete ‘files’ and settings before rebuilding which fixed this issue.
I had a look at “Drupal Console”, which automates a lot of the boilerplate code generation for a bunch of different tasks. I noticed there was no support for creating install profiles and logged a feature request (https://www.drupal.org/node/2392825).
The tool seems to only support a few tasks currently, but I’m sure as adoption of Drupal 8 increases, so will the features of this tool.
It is inevitable that using Drupal 8 during beta will cause you to maintain a bunch of homegrown and issue queue sourced patches during development. I had to apply 5 or 6 issues from the issue queue and write a few myself to get certain features working. As usual, it’s good practice to keep these well documented, in a folder and referencing any relevant issue numbers.
Hopefully I will be able to gradually reduce the patches to zero, however there seem to be quite a few non-critical issues which block day to day features you may have taken for granted in Drupal 7. For example core date fields are lacking a good views integration (https://www.drupal.org/node/1838242). These could a while to fully resolve.
I have been using config_devel to manage which modules are responsible for which config. The workflow is similar to features, but with much more bulletproof exports/imports. Simply use drush config-list to see a list of config and then add the relevant keys to your info file. After that a simply drush config-devel-export-module module-name exports all of the relevant config for you.
This worked really well, but there were a few cases where I had missed some config items after a few hours of site-building and had to retrace my steps to get things working. I started taking database snapshots to ensure I could retrieve config I had forgotten to export after rebuilds.
Default content by larowlan is a content export/import solution which works kind of like a “CMI for content”. My use case involved a variety of field types, such as files and dates. I was also using an early version of flag (https://github.com/socketwench/flag-drupal8). There were lots of issues with being able to cleanly export and import content. After digging around I discovered that the serialization and rest components of core are mainly to blame for issues with this approach. After these issues stabilise this should work well as a default content approach.
In my case, I needed to cover all of the website’s content with this solution in order to be able to provide a true reinstallation of content and config after go-live.
If you want to use drush, you will need to check out master from github. If you are still doing regular Drupal 7 work day-to-day a few aliases to switch between versions makes life a lot easier. The structure of how drush commands are written hasn’t changed much between versions from what I can tell.
The structure of themes is very familiar and twig is easy to transition to. I didn’t use a contrib base themes, opting to use classy as a base. I’m sure there will be base themes which provide an enhanced set of tools for front-end development, but classy was easy enough to work with.
I tried to automate all common tasks using phing. Amongst the tasks that ended up in my project, I had:
- build: reinstall the profile.
- db:dump and db:restore: easily dump and restore the db for debugging installations.
- export:config: export all of the config tracked by the modules in the profile.
- export:content: export content to reinstall when rebuilding.
- upgrade:core: redownload and commit HEAD.
- deploy:live - send the website to the remote server.
I decided to deploy my entire git project to the remote server so I had access to the same local tasks on the server. This allowed me to export the live content on the remote server, commit the result, pull locally and rebuild. This seemed pretty flexible, however deployment and devops best practices will probably undergo a lot of work as more people adopt Drupal 8.