Problem/Motivation

Quite a number of config things that we have can/do reference content entities:

  • Blocks of Custom Blocks (required, per block instance)
  • Default values of image/file/term/entity reference fields (optional)
  • Aggregator feed blocks (required, per block instance, reference feed ID)
  • Views...

To reproduce this problem in the most "awesome" way that core can offer:

1. Create a new custom block type
2. Create a custom block of that type
3.. Place that block somewhere.

There is now a block config entity that depends on a custom block content entity which depends on a custom block type config entity.

Now, go and deploy this. Good luck.

Proposed resolution

I have no idea :) We have no system in core for syncing content.

Remaining tasks

User interface changes

API changes

Comments

xjm’s picture

Title: How to deploy configuration that depends on content » [meta] How to deploy configuration that depends on content
Issue summary: View changes
Priority: Normal » Major
Issue tags: +Configuration system, +Configurables, +Block plugins, +VDC

There are examples of this all over core, yep. In addition to the cases in the summary it is all over the place in Views.

xjm’s picture

larowlan’s picture

Custom block uses uuid instead of serial ID. Fwiw This was by design.

Berdir’s picture

Yes, that is OK (only problem is that loading by uuid is slow as it requires a entity query + load, I think default values store both somehow?), feed is wrong, but that doesn't help in bringing custom blocks to your production site :) And you can't do a separate content sync before either, because your content depends on part of the configuration :-/.

catch’s picture

Priority: Major » Critical

Nothing to add but we should answer the question, even if the answer is not very nice, before a release.

xjm’s picture

I think we sort of know the answer already, that we decided from the beginning that it was contrib's problem to solve. However, we do need to make sure we're at least relying on UUIDs everywhere so contrib has something to work with.

catch’s picture

I'm not sure we can punt this to contrib if we have configuration entities referencing content entities in core.

If someone creates a custom block or entity reference field instance on their site, does an export and stage of their configuration, then it should not blow up. The person creating the custom block or whatever has absolutely no way to know this isn't supported.

catch’s picture

OK here's a proposal, two parts:

1. Custom blocks, that feels like a PHP error/broken site situation, we can't ship like that.

What we can ship with though, is without custom blocks in core at all. Just drop it and bring it back in 8.1.x or leave it in contrib once the problem is solved.

2. Things like default filter values in Views, entity reference allowed values etc., we can probably silently ignore entity IDs that no longer exist. We already do this on entities when a referenced entity is deleted, and it's not especially different from that.

When you need that to work, you can create the content on production, create the configuration entities that depend on it, then sync the configuration. That's an existing problem that we have now too.

It would be nice to do better than this, not sure we can without solving content migration.

larowlan’s picture

Added #2249303: Implement fallback plugin for Block plugins which should make missing custom blocks fallback more gracefully - basically borrowing the 'broken/missing handler' concept from Views.

alexpott’s picture

I've been thinking about this for sometime too - it came up when I was looking at importing configuration during a site install since the standard install creates 2 shortcuts and a menu link.

I agree that this problem is not solvable nicely without content migration. There might however be an alternative. Perhaps we could add content entities to the dependency system and then if they are not met fire an event or hook. If they are still not met after this then warn the user - this way we make it easier for contrib to solve and inform the users that configuration has this dependency.

chx’s picture

We faced the same problem in migration because we wanted to provide two steps with migrate configuration and then migrate content and they way we "solved" this was to move blocks into content. Clearly the situation is untenable. Looking at #2219129: Identify content vs. configuration I can't see any other config entity under the content umbrella, however.

catch’s picture

I marked #2249303: Implement fallback plugin for Block plugins as a duplicate of this issue for now, since it's possible (although very clunky) to deploy custom blocks in the same way as other content entity-dependent configuration (i.e. create the content entity without placing it on production, sync database back to dev/staging, place the block, deploy the configuration change).

andypost’s picture

I think one of 8dot release we can re-use default_content module to ship content, related #2344517: Consider merging github.com/larowlan/default_content as Drupal 8 solution

Wim Leers’s picture

Wim Leers’s picture

… or at least pave the way?

effulgentsia’s picture

Re #14, right, that was the last critical child issue of this meta. The only remaining child is #2361423: Add a step to config import to allow contrib to create content based on config dependencies, but that's Major, not critical. Does that mean it's time to close this meta? Or time to add new child issues?

alexpott’s picture

Status: Active » Fixed

It is time to close the meta. We support content entities dependencies in add and we're adding them where we should apart from Views but Views and config dependencies has its own critical issue that this does not need to keep track of.

xjm’s picture

Title: [meta] How to deploy configuration that depends on content » [meta] Deploying configuration that depends on content
Status: Fixed » Active
Related issues: +#2341357: Views entity area config is not deployable and missing dependencies, +#2372855: Add content & config entity dependencies to views

Why was this closed when there are still outstanding issues in the problem space? It just makes things harder to find.

xjm’s picture

Category: Bug report » Task

Switching to task, but there are still critical issues related to content dependencies in config.

xjm’s picture

Priority: Critical » Major

Discussed with @webchick, @effulgentsia, @alexpott, and @catch. Per #18 this should stay open, but the critical part of this meta has been resolved.

xjm’s picture

Category: Task » Plan
xjm’s picture

Tagging for a summary update. The event is in now, so we should document the current state in the summary and then gather remaining related issues.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

heddn’s picture

This is a dumping ground for a couple tough problems. Each one is solved in a different manner.

Blocks:
One possible way forward for blocks is to allow the construction of the configuration in dev/local development as a "promise" of what is to come. Build the config, then allow the storage of the reference to the content at a later point. This is kinda what pane module does in D7.

Default values:
I tend to use alters and use the friendly name and vocabulary id, etc to search and set the default value. I'd propose that the solution for this is a checkbox to allow "loose association" to store the name and vid or whatever is the most common "lookup values" for the default value. With appropriate help text and warnings, it should solve 80% of the problems. The remaining 20% is going to have to revert to code altering in the configuration.

Views:
I don't think this is as much of a problem. We are already using the views machine names I think to place things so this is pure configuration.

Aggregator:
I don't know much about these because I don't use them. But it seems like we could do similar to views and place by machine name in a pure configuration scenario.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nerdstein’s picture

We have experienced this issue a number of times.

My team and I are attempting to explore this within the following sandbox project: https://www.drupal.org/sandbox/nerdstein/2820449

We just started, so please bear with us as we begin to understand the problem. Please feel free to populate known issues and suggest general solutions that will have utility.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.