6

I've been trying to find a smart way of exporting content type and all its fields from one installation of Drupal to another. The core "Configuration synchronization" export only export the content type, but not its fields and configuration.

So far I have not met anything applicable for Drupal 8. All I can find is mentions of this functionality is possible in Drupal 7 module called Bundle Copy, which was never ported properly for 8.

I've also tried this, however I cannot find any good documenation on how the "drupal config:import" or "drupal config:import:single" works.

Is it really so hard to export and import content types between environments or have I missed something essential?

2
  • 1
    What do you mean with "between environments", the same Drupal site on dev and prod or two completely different sites?
    – 4uk4
    Jan 10, 2019 at 13:03
  • 1
    I usually use drush cex to export the config in my local enviroment and drush cim to import this config in other enviroment. I do not know if it's what you're looking for, you can export content types, fields, forms...
    – SilviaGDLR
    Jan 10, 2019 at 14:04

3 Answers 3

5
+500

Configuration management

Deploying content types, fields, views, site settings (everything that is not content) from one environment (local) to another (stage, prod etc.) in Drupal 8+ works by exporting the currently active configuration (stored in the database) into YAML files. The most common approach is to simply export all your site's configuration at once. Drupal takes care of that. You just specify the folder where you want these YAML files to be located in your project (at best outside the Drupal root). Then you uploaded all these YAML files or git push and git pull them to another environment and import the whole config there into the database. The export and import can be done by either using the UI or by using Drush.

Now when you add new features to your site locally (a new content type with fields for example) you simply export the whole config again. With some version control system like Git you'll then see that most of the already existing YAML files didn't change and only some new YAML files have been added. Simply upload/push the changes or the new files into another environment where you import the config again. The new content type with the fields now should have been created.

Configuration split/ignore

Of course, things can get more complex than what I described above, especially when working with lots of people on feature-rich and content-heavy projects. Then it can become necessary that you want some config to be ignored from getting exported or imported. Let's say you want to prevent that some API keys get exported. Or you want to prevent that some setting on the live site gets reset when you import the config again. Or maybe you always want to have some additional modules enabled only locally during development. Then there's the Config Ignore and the Configuration Split module to cover that.

Exporting/importing isolated config

This basically has been the way how you used to deploy configuration in Drupal 7. Now this approach can be used during local development to sync for example only one isolated content type or paragraph type and its fields across many multi-site instances. Of course you could rebuild the content type in every single instance manually yourself, but you can also use the Features module to have it create a module for you which only contains the config of this isolated content type and its fields. Then simply enable this feature module in all other multi-site instances to have the content type created there as well. And finally export the config on all instances for deployment as described under "Configuration management".

When you now change the content type on one instance, Features will recognize these changes and lets you recreate the feature module which then also contains the changes. These changes will be recognized by Features in all other instances where this module is enabled and you can re-import the changes into every instance's database; after which you finally export every instance's global config again, for deployment. Since every feature module actually is simply another Drupal module you can also use them to bring a certain isolated feature like a content type and its fields to any other unrelated Drupal 8+ site.

4
  • This doesn't work. Drupal checks the UUID. For some reason it has to be the same in both environments. It is not. Mar 17, 2022 at 6:48
  • @DonaldWinston – What exactly doesn't work? All you need is to set the site UUID. Google the error. It's a 1 minute fix.
    – leymannx
    Mar 17, 2022 at 7:05
  • I have to figure out what the UUID is, untar the config file, edit the appropriate yml file, tar it back up, and then import it. Ugh. But even then after it imports successfully it doesn't do anything. I get nothing under the Synchronize tab other than a message saying there's nothing to synchronize. Mar 18, 2022 at 11:24
  • @DonaldWinston – That's a whole new topic and I'd suggest reaching out for help at Drupal Slack and describe what you just described to me. Normally you use Drush for all these tasks. Set the site UUID of the site from where you export the config to have the same UUID as the site where you will import the config later: drupal.stackexchange.com/a/190282/15055. When your site doesn't recognise the changes to import you either didn't flush cache or uploaded it to the wrong destination. Find out where your site expects these files to exist and flush caches.
    – leymannx
    Mar 18, 2022 at 11:35
5

You're on the right track with the configuration export but I am guessing you did the single export option for the content type. Each field on your content type has several configuration items that should be exported too.

An alternative is using the Features module. This will allow you to select your content type. It will also automatically gather up all the required configuration items for exporting them.

3

The best way in my opinion is to use git work flow. What we do to export content type configuration with fields between the environments is we take a git feature branch and create content type and it's corresponding fields in our local environment and make a drush cex. Now in the git branch we have only the configuration related to the particular content type.

Once config is exported we create a custom module and include those config in config/install directory in the module and enable that module on all the required sites.

Here is the example of such config export

https://git.drupalcode.org/sandbox/Bhanu951-3103712/-/tree/8.x-dev/card_content

If the exported config is dependent on other modules. We define required modules in info.yml. So that you won't be having issues while enabling that module in different site.

1
  • 2
    The best way in my opinion is to use git work flow Agreed, here is a tip: Use Configuration Read-only mode to prevent someone from using Drupal's configuration management UI.
    – No Sssweat
    Oct 25, 2020 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.