Plug-in based config not correctly identified on config forms (e.g. text editor/CKEditor)

While working on ✨ Expand ConfigResolver tests to cover all config types we support Fixed , I discovered that ConfigResolver::getPluginConfigEntityNames() was not identifying any forms as having a plug-in based config on forms that definitely had them, so looked through the commit log and found this issue. Did a bunch of dpm() calls in that function and discovered that it was doing

if ($data instanceof ConfigEntityStorageInterface) {
  ...
}

but things like \Drupal\editor\Entity\Editor don't implement that interface, but rather \Drupal\Core\Config\Entity\ConfigEntityInterface. One way to fix this is to also check for that interface like so:

if (
  $data instanceof ConfigEntityStorageInterface ||
  $data instanceof ConfigEntityInterface
) {
  ...
}

Alternatively, we could drop the checks for interfaces and instead check if the method exists:

if (\method_exists($data, 'getConfigDependencyName') {
  ...
}

but I'm not sure if that will result in false positives. Anyone happen to know the exact reasoning for checking for the interfaces that I'm missing?

Hmm, that doesn't actually fix it in the sense that the editor config does now show up in ConfigResolver but it's getting removed somewhere before it can actually be displayed on the form. Doing a bit of a dive into the code to figure out where this might be happening.

Changing the issue name to be more descriptive of the underlying problem.

Alright, so after a bunch of head scratching, I had a hunch that Config Enforce Devel might be the culprit because I was getting deja vu to #3225119: Call to undefined method EnforcedConfigRegistry::createEnforcedConfigs() → and guess what? Uninstalling Config Enforce Devel fixed it, in that the Config Enforce container is now correctly showing the text editor config. I'll have to figure out exactly what the issue is, but I get the feeling it's something to do with instantiating the ConfigResolver multiple times under slightly different conditions. Having that as a service rather than a class that's instantiated every time might fix it, but that's for 2.0.x due to the major changes required.

Holy shit I fixed it. Okay, so here's the thing that eventually stood out to me: the Config Enforce form alter seemed to be running after Config Enforce Devel's, which I thought was odd, so I took a look at the module weights and discovered that Config Enforce has this:

/**
 * Implements hook_install().
 */
function config_enforce_install() {
  // Assign a high weight to ensure our implementation of hook_form_alter() is
  // run among the last ones.
  module_set_weight('config_enforce', 1000);
}

but Config Enforce Devel doesn't have a counterpart that also sets its weight to be one higher (i.e. 1001). I assumed that Drupal core would take care of this for us but apparently not? Anyways, opened 🐛 Ensure Config Enforce Devel's form alter runs after Config Enforce's Fixed and pushed a commit to its issue fork.

Opened merge request and setting as needs review. Should this check not single out nodes but apply this behaviour of ignore all content entity add/edit forms?

@spiderman I'm fairly certain there are a few. I'm assuming media entities are one of them, but I'd have to check.

Opened ✨ Hide Config Enforce container on all content entity add/edit forms, not just for nodes Fixed as follow up.

Automatically closed - issue fixed for 2 weeks with no activity.