Config Ignore Auto: How To Change Drupal 8 Configuration (Without Bugging A Developer)

Don’t you hate having to call a developer when you can’t update your site by yourself?

After all, that’s one reason you paid to have a new site developed in the first place—so you could make changes on your own.

Drupal is known for being flexible and scalable (read: lots of buttons and knobs on the backend), which is why the majority of our projects use it. Once you get familiar with Drupal, you quickly realize how powerful it can be.

That power and flexibility can come with a downside, though.

With great power comes great…problems

When you have that “aha” moment with Drupal, you want to begin modifying Drupal’s more advanced and powerful configuration options (such as blocks, views, or webforms).

While this supercharges your productivity, it creates issues for developers working on the site. Often, developers may ask you to go through them to make configuration changes—or at least notify them when you do so.

Understandably, this can be frustrating because as the client you are restricted from the most advanced features of your site—often, the very same features that make Drupal so powerful in the first place.

To address this problem, Brooks Digital funded the development of Config Ignore Auto, a Drupal 8 module created by our Drupal Lead, Ariel Barreiro.

To explain what this module does and why we contributed it to the Drupal community, let’s briefly discuss Drupal’s configuration management system and why it matters to the average Drupal user.

Drupal 8 configuration management (and why it matters to you)

Drupal has a lot of admin settings (configuration) on the backend ranging from checkboxes and text fields to more advanced settings such as views, which control the display of collections of content like blog posts or programs:

These settings are stored independently from the content of your site, such as the text on your About Us page.

Drupal 8 has a configuration management system that allows developers to import and export all your site configuration to code. 

This is useful because developers spend a lot of time tweaking settings on a development site when preparing a piece of work. When it comes time to finally deploy that work, it’s time-consuming to remember and repeat all those steps on the live site (plus, they better not forget a checkbox somewhere, or things will break!).

It’s like spending hours painstakingly writing a blog post in Word and then having to manually type it all over, word for word, into your website when you want to publish it (no thanks).

With Drupal’s configuration management system, developers can essentially copy and paste all the site settings from a development site to your live site, without worrying about forgetting a field here or checkbox there.

Where configuration management breaks down

This is all fine and dandy until someone decides to change configuration on the live site.

For example, let’s say you have a developer create a newsletter signup form and a donate button in your sidebar, and later you want to swap their order so one appears above the other.

No big deal—you just go into Drupal’s block configuration, drag the donate block above the sidebar block, and save your changes. Done.

Except there’s now a problem.

Drupal is smart and knows that, according to the saved settings originally placed in code, the newsletter and donate blocks should be the other way around. It still lets you make your change, but marks that particular setting as overridden in the configuration management system.

Now, this doesn’t cause any immediate problems. But imagine the next day, the developer deploys a different piece of work.

If they don’t happen to see that you changed some settings that are now overridden, they will import the original site settings (which are still saved in code) and undo all your changes.

The result: your newsletter and donate blocks are suddenly back to the way they were before, and you are confused and slightly annoyed. (Thankfully you didn’t make any more substantial changes, or you would have been really frustrated!)

The workarounds (to this point)

To get around this, there have been a few strategies employed by developers and clients working together on a site where configuration is modified on a regular basis:

#1: Have developers make all configuration changes

The most foolproof strategy is to simply not make configuration changes on the live site and ask a developer to do it instead. That way, they can write the configuration into code and it won’t run the risk of being reverted.

• Pros: None of your changes ever get reverted—and your developers are probably happy.
• Cons: …you can never make any changes to begin with. 🙁

#2: Be really paranoid about configuration

Another option is to train developers to closely watch for overridden configuration on the live site, and make sure they write those changes into code before they deploy any new work.

• Pros: You can make changes without them getting reverted…most of the time.

• Cons: Developers are human and they will occasionally forget. (Plus, they might be annoyed at having to be on high alert for overridden configuration all the time.)

#3: Ignore specific configuration options

The generally accepted best practice (to this point) has been to use the Config Ignore module to define specific settings that are ignored by Drupal’s configuration management system—meaning you can change them without them appearing overridden (or being reverted).

• Pros: You can make changes and be certain they won’t be reverted. Developers are also happy that they don’t have to watch for overridden configuration.

• Cons: You need to specify what configuration should be ignored beforehand, which isn’t always practical. And developers can’t write ignored configuration to code (remember, this is their copy/paste)—meaning that for workflow purposes, it’s not practical to ignore wide swaths of configuration without closely considering the tradeoffs to developer productivity.

Enter Config Ignore Auto

We didn’t particularly like any of these options, so we released Config Ignore Auto.

Under the hood, Config Ignore Auto uses the Config Ignore approach, but with a twist:

Any time a piece of configuration is edited, it’s automatically ignored from that point forward.

This keeps all the benefits of Config Ignore, while ensuring that only the settings that you modify are ignored. And this all happens automatically, so there’s no need to agree with a developer on what gets ignored beforehand.

Of course, there still may be situations where a developer needs to put ignored configuration into code, or remove certain configuration from the ignored list. But on the whole, these are relatively specific situations that can be handled on an as-needed basis.

Ultimately, Config Ignore Auto allows you to be more autonomous and empowered on your website without feeling like you need a developer’s permission before touching things. 

After all, if you have a Drupal 8 website, shouldn’t you be able to use it to its full potential?