I encountered a frustrating aspect of Drupal 8 this evening as I was building a site for a client and experimenting with deployment routines to other environments.
First, a bit of setup.
If you’re reading this, then you’re probably already aware of the much heralded refactor of Drupal’s configuration management system, which enables you to export site configuration to YAML files, so that you can version control the files and deploy them to other environments. Tools like drush make this an easy and effective way to migrate new content types, fields, views, roles, permission settings, and other common Drupal configuration items from environment to environment – for instance, from one developer’s machine to another, or from dev to staging to production.
Given that “Menus” are configurable under the “Structure” section of the Drupal 8 admin, I was expecting that my newly configured menu items would naturally export / import from environment to environment. But sadly, this is not the case.
What it seems to me, is that if a menu item is configured as part of a view, then it will be part of the configuration; but if you manually create a menu item – for instance, a link to an external resource or a defined path (e.g. /about-us) – then that menu item will not be exported as part of the configuration.
This leaves me with a conundrum: how to manage deployment of new and updated menu items across environments?!
During the initial site build, I suppose this won’t be too much of a trouble, as I could export the whole database and advise my developer colleagues to just import the new database every time they pull and notice a new one. However, once the site gets pushed out to staging or production, what’s going to be the best practice?
At this time, the only thing that comes to mind is to keep track of the additions and recreate them in each environment – but what a drag!
I wonder what the rationale is with the Drupal core team for not having all menu related items considered as part of configuration?
If you have a clue and would be willing to weigh in, or better yet, have a great development / deployment workflow idea, please contact us and perhaps we’ll post your input here for everyone’s benefit.