[meta] Deploying configuration that depends on content

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.

Couple of loosely related issues so I can find them.

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

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

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.

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.

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.

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.

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.

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.

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).

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

Didn't #2282519: Add content dependency information to configuration entities fix this? :)

… or at least pave the way?

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?

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.

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

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

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

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.

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.

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.

Somehow this issue slipped through the cracks of issue migration.

This also affects the Recipes Initiative: #2094481: Support default content entities. Tagging for that.