We’re a worker-owned agency that designs, builds and supports websites for organisations we believe in.

Drupalcon Dublin, Day 2 – afternoon sessions

Configuration management, theory and practice

Presented by guys from Nuvole, a Drupal agency based in Italy / Belgium / Czech Republic, this talk ran through all the good things in Drupal 8’s configuration management.

First challenge: how do we deal with fast updates, with multiple developers on a project and frequent deployment of config changes.

Exporting and deploying configuration in Drupal 8 is now possible. This is a tool built for a specific purpose, to export the whole configuration for a site, and it is perfect for this purpose. But new issues are emerging many of which are being addressed in contrib modules.

How do I start a site from existing configuration?

The default D8 config management allows us to export configuration but only import it to a copy of the same site. Enter: The idea here is that the installer will ask for config to import while installing a site: this is not in core yet, but hopes to be in the future

Can I override local config?

When developing it is often useful to override configuration locally for example API keys for local development or setting verbose logging on local machine but not in production. One way to do this is with local config overrides, such as:

$config['system.logging']['error_level'] = 'verbose';

BUT the settings in the UI will still look like the original setting not the overridden configuration. This is to prevent accidental export of the overrides.

Mutable vs immutable config: Drupal can load configuration which is either read only or editable.

Issues with this method of overriding configuration:

  • you can’t add new configuration
  • you can’t enable a module locally
  • you can’t unset configuration

How to exclude development modules from being exported with other configuration?

1. Drush

drush cex —skip-modules=devel

2. Drush drush_cmi_tools

drush cexy —ignore-list=modules_to_ignore.txt


3. Configuration split

This is a neat way to divide configuration into different folders.

Working on configuration with colleagues

As config is file based, git does a pretty good job of merging configuration changes and resolving conflicts, but we can still run into issues resulting in invalid configuration. 

Features for Drupal 8

Features in Drupal 8 is mainly for the automatic packaging of configuration; it is not for deploying changes to configuration! Features should now be considered a development module, and should never be committed to production environments. An interesting byproduct of configuration management and features is that generated features DO NOT depend on the features module! We can deploy and enable them on their own. Neat!

There are however a number of gaps in the features config packaging at the present time:

  • overrides
  • menu links
  • permissions

How can I handle a client messing with config on prod?

Changing configuration is an ACT OF DEVELOPMENT! So clients who change configuration become a developer that you cannot control. There are a number of ways we can address this.

$settings[‘config_readonly’] = TRUE;


  • Even a client with access to the UI to change config, will not be able to save any changes. Harsh, but clean.
  • Export to a dedicated branch
    • use a git workflow where changes on production are allowed and merged into another branch test deployment of new changes.
  • Config split.
    • define the subset of configuration that a client can edit, and use config split to export this configuration to this directory. We can then use git ignore to avoid committing and deploying such configuration (and overwriting changes made on the production site).

How can we deploying configuration that has dependency on content?

This module helps us to export content using drush, then include that default content with the module. This could include menu links, nodes, terms.

Or... we could use Deploy an amazing module, but quite heavyweight if we just need a few items of default content.


Related modules

Here is a list of modules that may be useful when extending configuration management. Who knew there were so many?

My key takeaways

  • Consider client side configuration allowances at the start of a project and clarify expectations within the team.
  • Try Configuration Split module.

See the video of this session:

Super Collaborative Design Processes.

Lewis Nyman has always had plenty to say about front end in Drupal. He used to live in Oxford and has worked with Agile Collective on User Experience, so it was great to hear his thoughts about collaborating more with clients on the design process. He now works at Convivio.

Collaborative Design

What do we need from a good design process?

  • consensus based on objectives (not opinions)
  • buy in from stakeholders
  • buy in from developers
  • good design – it is important that we all feel good about the design

With a show of hands, Lewis assessed the makeup of the audience in the room

  • mostly developers
  • 20% pm / project owners
  • 5% designers

Old process for UX design

  • research
  • go into a cave
  • decide what was best
  • present to the client
  • get feedback
  • iterate

Some of the feedback was often difficult and not that useful

  • 'can we make it green?'
  • 'I think it should like Amazon / Tinder / Uber'
  • '  ' – (silence, no feedback)
  • 'I don’t like it'
  • 'Hello, I don’t like it, Goodbye' – (swoop and poop) often by a HIPPO (Highest Paid Person’s Opinion)
  • 'I’ve brought my own wireframes'
  • 'Ooh that’s going to be expensive to build'

New ways of working include

Bringing everyone together to develop ideas and design decisions

  • designers
  • developers
  • product owners
  • stakeholders

Workshops help to

  • understand and define the problems
  • generate ideas
  • diverge
  • then focus on an agreed approach

Share information with everyone (get people to take notes)

Define the problem(s)

Start by agreeing on the problems that we are aiming to address. An example of this may be:

  • 'Students don’t receive enough guidance on how to develop the skills that will enable them to learn and flourish.'


Get started with pen and paper. Use exercises to warm people up such as 'squiggle birds' or '60 second portraits'.

Generate as many ideas a possible, and remember:

  • all ideas are equal
  • don’t judge
  • don’t analyse
  • ideas don’t even need to be feasible

Techniques that can help

It is important to get everyone past the first idea hump. Someone has usually been building an idea for a while and they become quite attached to that idea, shooting down other people’s ideas. Getting this out on paper will allow them to move past this and generate more ideas.

Present all ideas

Get all ideas up on the wall next to the problem statements. Talk through all ideas to build mutual understanding.


If everyone is facing the same direction this is less intimidating. Dot voting can be used to rate interest in each idea and help generate consensus.

More ideas

Generate more ideas!

Boil it down

  • identify any conflicting ideas, ideas that are either one of the other.
  • use 3-12-3 as an extension to the 685s, this can be used to develop three ideas in more detail.
  • extend ideas with more detailed storyboarding.


By engaging the client in workshops we will develop a better design and ensure more buy in at an earlier stage. By focusing on our ideas together in person we potentially get through two weeks of work in 6 hours.


  1. HIPPOS: any suggestions for how to deal with them in a workshop?

    They often feel like they've not been listed to, give them attention, get it out, then generate more ideas.

  2. This sounds like it is still very much at the wireframe stage of user experience. What about visual design?

    Still need to iterate on visual design, but it is more likely that we will have already agreed the structure of the pages / screens so this will be more efficient and will happen faster.

My key takeaways

  • Defining a collaborative UX and visual design workflow is important for efficiency and buy in.
  • Using new techniques within workshops such as 6-8-5s will help focus and encourage idea generation.
  • sounds like an interesting read.

See the video of this session

BOF – Does Drupal need a Platform Co-op?

Birds of a Feather (BOF) sessions at Drupalcon are ad-hoc meetings that allow attendees to discuss issues that crop up during the conference. This session was proposed by Steve Purkiss who wanted to discuss the idea of a Drupal platform co-op. There were representatives from three Drupal co-ops: Agaric Collective (US and Nicaragua), Agile Collective (UK) and Point Blank (Greece). A number of freelancers and people interested in the discussion also joined.

Steve Purkiss’s motivation for setting up a platform co-op: to be more in control of working environment and client relationships. To allow freelancers and single person companies to work with others to appear larger. When asked to define a platform co-op, the example given was 'a company like Uber which connects customers with suppliers, but one that was owned by the customers and suppliers'.  

We discussed whether this was different from the roles of the Drupal Association and and didn’t really get to anything conclusive. We explored the idea of a Drupal trade association (something mentioned by Robert Castello when discussing a national UK Drupal association) and I mentioned that other tech co-ops in the UK are getting together to discuss ways of working together in a similar manner.

In summary, those of us who already work in a worker co-op couldn’t really see the added value of a new Drupal platform co-op. Steve clarified that he doesn’t want to work in a company, but would like the opportunity to work on larger projects as part of larger teams. I’m not sure how these two can be resolved.

Meet the Authors
Back to blog