I'm working on a project where all of the site configuration is managed in code. This means that on production, ContentHub should not be creating or updating config on subscribers.

Our code workflow is like this:

  1. When there's a config change on a site, we make that change on a local development environment, export the config (drush cex), and commit the changes
  2. When the code is pushed, a CI server runs a test suite to ensure that the config change doesn't break features that we have tests for
  3. Once the tests pass, we can merge and deploy to an Acquia environment

Our content workflow is like this:

  1. Content is created on our publisher site
  2. The subscriber site receives a CDF
  3. When the CDF includes config entities that already exist on the subscriber (based on the ID), ContentHub should use the existing config as its dependencies
  4. If the CDF includes new config entities that do not yet exist on the subscriber, ContentHub should stop the import before modifying any content or config

Finally, when we DO need to create config on the subscriber based on the publisher (because certain config is required in order for the subscriber to receive the full entity data), our desired workflow is:

  1. Temporarily allow ContentHub to create config on a copy of the subscriber running on a development environment
  2. Manually import content that requires the new config to the subscriber
  3. Export the config (drush cex), commit, and push the changes for testing

I have working code that I'd love to share, since this code-based workflow is typical among the sites that I work on. I will post it here as soon as I can credit the proper organization!

CommentFileSizeAuthor
#3 acquia_contenthub-3083430-prevent_config_syndication-3.patch10.64 KBbecw
#2 acquia_contenthub-3083430-prevent_config_syndication-1.patch1.88 KBbecw

Comments

becw created an issue. See original summary.

becw’s picture

becw commented
StatusFileSize
new acquia_contenthub-3083430-prevent_config_syndication-1.patch1.88 KB

Step one for this issue is to include config entity IDs as a new attribute in the CDF for config entities -- this is necessary in order to see if an overlapping config already exists on the subscriber.

Here's a patch for to do that, based on code from @EclipseGC.

becw’s picture

becw commented
Assigned: becw » Unassigned
Status: Active » Needs review
StatusFileSize
new acquia_contenthub-3083430-prevent_config_syndication-3.patch10.64 KB

Here's the full code we are using to manage config syndication. This patch adds a new submodule, acquia_contenthub_noconfig, that prevents syndication from updating existing config, and allows administrators to control whether new config entities are created or whether the syndication that requires the new config should fail instead.

dpalmer’s picture

dpalmer commented

Unfortunately, this patch is not working for me. I have a similar use case:

I have an ACE Drupal 8 site that is aggregating a bunch of data thru migrations. This is the primary content hub publisher. This site, has all teh content types and fields that I want, with some additional fields.

I have a site factory environment that has its own drupal 8 distribution, with the same content types and many of the same fields, but not all of them.

Unfortunately, content hub keeps syndicating the configurations and data for these additional fields. I was able to omit the data from going to the hub with an EventSubscriber on the 'DependencyCalculatorEvents' from the depcalc module.

@Eclipsegc had recommended this patch to omit the configurations themselves, but unfortunately, those configurations keep coming over (without any of the data which is good).

Any advice?

Thanks,
Donovan

becw’s picture

becw commented

Sorry for the late response, @dpalmer -- this patch adds a new module, acquia_contenthub_noconfig, so it won't change your contenthub syndication behavior until you enable that module.

If you had already enabled the acquia_contenthub_noconfig module and config was still being syndicated, then I'd be curious if you were getting any log entries or error messages.

lpeabody’s picture

lpeabody commented

An alternative to this approach you can deregister all Dependency Calculator event subscribers which calculate configuration.

Example of a service provider removing these:

<?php

namespace Drupal\bax_contenthub;

use Drupal\Core\DependencyInjection\ContainerBuilder;
use Drupal\Core\DependencyInjection\ServiceProviderBase;

class BaxContenthubServiceProvider extends ServiceProviderBase {

  public function alter(ContainerBuilder $container) {
    // We do no want to calculate config dependencies.
    $config_calculators = [
      'entity.config_entity.dependency_calculator',
      'entity_view_display.dependency_calculator',
      'entity_form_display.dependency_calculator',
      'workflow.dependency_calculator',
      'entity.language.dependency_calculator',
    ];
    foreach ($config_calculators as $calculator) {
      if ($container->hasDefinition($calculator)) {
        $container->removeDefinition($calculator);
      }
    }
    parent::alter($container);
  }

}

One thing to note, you want to make sure that the module that controls this service provider is weighted higher than the depcalc module, otherwise you may run into the service provider of that module trying to inject a service which doesn't exist into another service.