1

I'm using the config_split module to split configuration to an installation profile, that I use in multiple Drupal sites.

I have 2 sites using the same installation profile, both using the same config split settings.

Here's a list of configuration that I have split to the profile.

  • The content type (article)
  • Taxonomy vocabularies
  • Media types
  • Media library views and settings

I have 4 content types on one of the sites, but I only want to split the article content type.

The problem is that some fields from the other content types are automatically split because they depend on either media or taxonomy.

This is the node configuration that I'm splitting:

  • core.base_field_override.node.article.*
  • core.entity_form_display.node.article.*
  • core.entity_view_display.node.article.*
  • core.entity_view_mode.node.article.*
  • field.field.node.article.*
  • field.storage.node.article*

All fields from the article content type are all named article_FIELD_NAME.

How can I avoid that config split also splits depending configuration?

  • You want to prevent the necessary dependencies this split needs to work properly gets provided? Sounds a bit like an unorthodox requirement. How should these dependencies provided then? Your approach made me think of Features. Maybe try using a Features module for the article content type. Or provide the article completely from your own custom module. – leymannx Aug 29 at 17:23
  • Hi @leymannx Thank you for reaching out. I know that what I’m trying to do doesn’t really make sense at some point, but I’m just being told to use the config_split module so hoped that there was a way to solve my problem using that module. Thank you for suggesting features, even though it’s a bit against Drupal 8’s way of managing configuration it might be the only way possible. – Jdrupal Aug 29 at 17:34
  • @leymannx Do you know if configuration files are removed from the sync directory when exporting it to features? – Jdrupal Aug 29 at 18:49
  • Features and configuration mgmt work independently from each other. In one site change a field, re-export feature, in other site re-import feature to apply these changes, and finally on both sites export configuration as usual to be used for deployment. – leymannx Aug 29 at 19:14
  • But in the end you still might have dependencies across features. I usually solve that by permissions then. Let's say when I have two content types, one used on site A, the other used on site B, I still might have both content types on both sites, but on site A simply let no one access the content type that's supposed to be used only on site B. Sure I have an unused content type hanging around on both sites, but this never affects performance negatively. It's just there, and no one uses it. – leymannx Aug 29 at 19:20
1

I solved that problem using Features for Drupal 8 as suggested by @leymannx.

I have exported media, taxonomy and the article content type to one feature that I can now use across multiple sites.

The cool thing is that configuration still lives in the config_sync directory, so other content types that depend on media and taxonomy don't need to be exported to features as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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