I have a custom module. I created a content type and added some fields to that content type. I also enabled the layout builder on the manage display of the content type

Then I run drush -y cex to export the config files.

Then I copy all the config files related to my content type to the module's config/install director

Now if I make some changes to content type, their config files should be added/updated/exported in/to the module's config/install directory and should not be added to the site's default sync directory.

Is this possible?

  • But why do you want to do this?
    – leymannx
    Jun 12, 2020 at 11:03
  • I want a content should be in one module. It is installed on a site the content type will be there when the module is not installed that content type should not be there. I have multiple sites which shared codebase.
    – Ahmad
    Jun 12, 2020 at 11:34
  • The same codebase is no problem, but you seem to have shared configuration if that's what happening.
    – Marcel
    Jun 12, 2020 at 11:54
  • Yes the configurations are shared that is why I do not want the content type should be there
    – Ahmad
    Jun 12, 2020 at 11:57
  • @Marcel What I should do in this case? I do not want that content type on every site. While the code is shared. There around 300 sites. If the configurations are there in the sync directory, it will create the content type and its fields on every site when import runs. Therefore I wanted it to be in a module.
    – Ahmad
    Jun 12, 2020 at 12:01

4 Answers 4


You can use a Drupal Console command:

drupal config:export:content:type page \
  --module="demo" \
  --optional-config \
  --remove-uuid \

Source: https://drupalconsole.com/docs/en/commands/config-export-content-type

  • I checked this but the drush -y cex still export the config to the default sync directory
    – Ahmad
    Jun 12, 2020 at 9:24
  • You have to use this instead of drush and also notice the other options the console command provides which drush doesn't..
    – 4uk4
    Jun 12, 2020 at 9:36
  • I'm running drupal config:export:content:type application but it fails with the error: // config:export:entity and [ERROR] The bundle application does not exist. Any idea what's going on here? The application content type has a bundle application_type
    – theuni
    Sep 16, 2020 at 11:29

You can do exactly this with the Features module.

Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it contains additional information in its info file so that configuration can be checked, updated, or reverted programmatically.

While ignoring the related config from configuration management with Config Ignore at the same time. Which also takes wildcards so you don't have to enter every single config object by hand.

  • I will use feature for that module config and will use configuration management for all other configs?
    – Ahmad
    Jun 12, 2020 at 10:16
  • @Ahmad – You additionally need config_ignore to exclude it from configuration management.
    – leymannx
    Jun 12, 2020 at 10:59
  • I will list all the config files of my module in the config ignore one by one?
    – Ahmad
    Jun 12, 2020 at 11:00
  • @Ahmad – You can use wildcards.
    – leymannx
    Jun 12, 2020 at 11:01
  • OK and If I have created a feature with the config and is installed on the site. Then when I change the config files of that module, How it will be imported? with hook_update_N?
    – Ahmad
    Jun 12, 2020 at 11:03

You maybe misunderstand the drupal configuration workflow. A modules config files will only be installed when installing the module. At that moment the configuration will be imported in the database, and so, when you export the sites configuration your modules config will also be part of that. Subsequent changes to configuration of your own module can be done in update_hooks, but it's easier to make changes on the site self, export that, and have it versioned in that site's repo. If your module only holds config, you could also uninstall it immediately after you installed it, because it doesn't serve a purpose anymore.

So doing this, exporting config to a module, makes sense when you need that same configuration on another site that doesn't already have that configuration. Its a quick way to setup parts of the site the way you like. If a customer wants events where users can register to, and you created that before, you could create a module for that, that when enabled on the site sets up the basics for it. Further customizations to the clients wish on that particular configuration will be versioned in its own repo, when exporting the sites configuration.


After installing the Configuration Split module, the configuration can be exported in one or more "splits", enabling you to target different configurations for different environments or situations.

  1. Install the Configuration split module :

    composer require drupal/config_filter drupal/config_split && drush en -y config_filter config_split

  2. Using the Backoffice create 2 splits one will export your module configurations to config/install and the other will export other configurations into standard sync folder, a split enables you to :

    • Specify the exportation directory ex (config/install).
    • Specify what module configuration to export (your module).
  3. just run drush csex -y and the code will be exported according to the split setup.

you may find these videos useful: https://www.youtube.com/results?search_query=Configuration+split+module+

  • I used this method but there were some other config files also exported to that new location i-e views.view.content.yml
    – Ahmad
    Jun 12, 2020 at 10:08
  • Isn't it drush -y csex SPLIT_NAME? Or does drush -y csex simply export all active splits?
    – leymannx
    Jun 12, 2020 at 11:01
  • 1
    drush csex -y will export all active splits that have been enabled in the setings.php Jun 12, 2020 at 11:30

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.