Drupal 8 - use sed to strip uuid line from exported config files

sed-to-strip-uuid-from-yaml-config-files--osx.md

[Drupal 8] use sed (on OSX) to strip the uuid line from exported config files being used for module default configuration; i.e. [module_name]/config/optional|install

NOTE: this can also by bypassed in the export by using Drupal Cnnsole and including the --remove-uuid flag. Also using the --remove-config-hash flag can help prevent additional headaches.

Ex: drupal config:export --directory=”[full-path-to-location]” --tar --remove-uuid --remove-config-hash

The UUID should never be included when using when using these exported config yaml files as the default configuration pagaged with a custom module. This is suppoedly not to be a thing in the exported yaml files at some point, but until then stripping the uuid line out is a manual process which can be a pain as there can be a lot of files.

To automate this, run the following sed command in the directory containing the yaml files:

sed -i.bak '/^uuid: /d' ./*

The i.bak arg will create a backup of the affected file. When satistifed with the results, you can safely get rid of the .bak files:

rm *.bak

References:

• https://drupalcommands.com/console/config/config-export/
• https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/sed.1.html
• https://stackoverflow.com/questions/5410757/delete-lines-in-a-text-file-that-contain-a-specific-string

Thanks for the clarification. I think we are on the same page.

I'm trying to follow Drupal's best practices for my module. The module is creating some resources in Drupal: a content type with a few new fields and a view. Those resources are likely to change over time. I have created modules for Drupal 7 in the past, things always changes. I don't want to be stuck in a situation where I need to change my resource's YAML file but Drupal can't recognise the resource it created, and instead of updating it, decide to create a duplicate (or something like that).

It works perfectly fine when installing the module, when the resources doesn't exists on the website. I'm concerned about the future. How will the update process works and how Drupal find out what needs to be updated.

I tried to simulate a module update, to see how I can write an update method and understand how Drupal would update the resources created by the module. I could not even get Drupal to find out the modifications I have done to my YAML file. I'm starting to think the config/install folder simply creates resources on the website, then leave it to the user to manage them. That's not what I had in mind. I wanted a module which is able to create and maintain its own resources (content type and view).

I agree with you that the UUID should be universally unique, but that doesn't mean that's how Drupal is using them. Just open the registry in Windows to see how "not to use" UUID. I was just trying to understand why those UUIDs were there and how Drupal uses them. I'm still unsure what they are used for. Are they only used to prevent someone from exporting / importing config from a website to another website which is not a clone? That feels like an overkill ugly patch. Surely they are there for something more fundamental.

@gaellafond

Config included in /config/install is default config. When you import config from a module, a UUID gets generated for that config and the config from the module you installed is never used again unless you uninstall and reinstall the module. At which point, another UUID will be generated.

When you export site config - drush cex - the config that was installed from the module will be exported into your config sync directory with the UUID intact. Default module config doesn't need a UUID to behave correctly and for Drupal to know what needs to be updated because once it's initially installed, the config in /config/install is never looked at again and that module config is handled in the config sync directory.

@DavMorr is correct in saying that module config should never include a UUID. I'd be surprised if the module actually installs correctly if it does.