Add content dependency information to configuration entities

I'd expect custom block to be easier to implement than the other two, actually.

a) It's static, we know what we're dealing with
b) We might not even have to care about the custom block type because we only need to worry about direct dependencies? If the custom block exists, then we can safely assume that the custom block type exists too? It's also not directly relevant for the block.

On the other side, the field default value and various views arguments and the default handling stuff are plugin-specific, and while there was already work done to convert content entity default values for fields to UUID's, this does not exist for views (which exports them as ID's), so we need to solve that problem first.

Already noticed this when trying to have default views with arguments and default values.

How close is the related with #2278017: When a content entity type providing module is uninstalled, the entities are not fully deleted, leaving broken reference , maybe even making that one other one duplicate ?

I think they're different issues.

This one only covers configuration entities that have an explicit dependency on particular content entities, and it's open mainly because without this we can't validate deployment of configuration between instances of the same site (right now you could break a production site by deploying configuration without the requisite dependencies in place).

That issue deals with any data that has a dependency on content entities - which might well not be a configuration entity and isn't necessarily data that gets deployed (i.e. comment statistics table) - mainly for the case where modules are uninstalled.

Austin discussion notes:
https://docs.google.com/document/d/1i56Ss99rzxeSuEkThQAXi5osX9f74-9x4AX9...

reroll

looks good to me to, some minor nitpicks.

1. +++ b/core/lib/Drupal/Component/Plugin/ConfigurablePluginInterface.php
   @@ -47,11 +47,11 @@ public function defaultConfiguration();
   -   *     'entity' => array('user.role.anonymous', 'user.role.authenticated'),
   +   *     'config' => array('user.role.anonymous', 'user.role.authenticated'),
   

   should we add a content example here as well ?

2. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigDependencyManager.php
   @@ -151,17 +157,17 @@ public function getDependentEntities($type, $name) {
   +      if ($type == 'module' || $type ==  'theme' || $type ==  'content') {
   

   nitpick, two spaces before 'theme' and 'content'

3. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigDependencyManager.php
   @@ -151,17 +157,17 @@ public function getDependentEntities($type, $name) {
   +      // If checking content, module, or theme dependencies then discover which
   

   maybe a comma after 'dependencies' ?

perfect!

we can have entity types that are neither content nor config

Are those "grey area" entity types something we really need to be able to specify dependencies on ?
If it's "grey area", it means there is no generic mechanism to handle those dependencies anyway ?

Agreed with yched in #19, I don't see why we'd want to generically handle unknown types of entity types here. Even content dependencies in config have a relatively limited use case in field API/Views.

Didn't review whole patch yet.

Committed/pushed to 8.0.x, thanks!

I think a change record for the changed entity key in the config files would be in order.

+1 to change notice - changes to config keys is an API break for anyone with a module containing default config - should have had change notice before it was RTBC in my opinion.

Re-opening for change record and change record updates.

Ok thanks, that looks good enough to me for this, will publish. Not the fault of this issue that we have nothing else, maybe we should, but no need to keep this issue open.