SEO Tools recipe should automatically reapply itself every time a content type is created

thejimbirch → credited jurgenhaas → .

This is awesome @narendrar! I made some minor suggestions.

I assume this will have to wait until the action is in a full release of ECA, and we'll have to update all the spots that are marked dev in this MR to the new release.

I assume this will have to wait until the action is in a full release of ECA, and we'll have to update all the spots that are marked dev in this MR to the new release.

I've just tagged ECA 2.1.2 that contains those new features.

Some minor dependency stuff, but otherwise this seems great. It will need test coverage; in SEO Tools' ComponentValidationTest, all we really need to do is create a new content type and then assert that it got the appropriate SEO fields attached.

This issue is NR for further feedback. Thanks

Postponed on the forthcoming 2.1.3 release of ECA.

thejimbirch → credited tim.plunkett → .

We met with @alexpott, the lead maintainer of the Recipes initiative. The long term goal of of recipes is that they are unpacked and removed from Drupal in the application process. The fact that the recipes are remaining in Drupal CMS, and this issue to forever re-apply them may lead to the recipes getting updated and havoc unleashed when reapplied.

Instead of re-applying the recipe, could there be an ECA action to apply config actions? So rather than re-applying a whole recipe, we only list the config entities and config actions we want to apply in the ECA.

@thejimbirch we can certainly build an action plugin that applies a config action. That may probably even make sense outside of the context of this issue. For the purpose of reapplying certain config actions following some events, we would have to find a way to identify and extract those from recipes when they initially get applied and keep them somewhere so that we can refer to them when needed. Maybe we should either build ECA models manually for that? It would be much easier to implement, but it certainly requires more work and coordination by the recipe author to build and maintain that.

For the purpose of reapplying certain config actions following some events, we would have to find a way to identify and extract those from recipes when they initially get applied and keep them somewhere so that we can refer to them when needed.

I don't think it is necessary for ECA to identify and extract what config actions it wants to re-apply. I think the recipe should leave behind the ECA with the config actions it wants to apply on events. We should put that on the recipe author to create and maintain since we won't want all actions in a recipe to be re-applied.

So given upstream changes in core (soon to land in 11.1.3), I think the way to proceed here is not for ECA to try to be smart about detecting things.

Instead, let's take advantage of the new extra section of recipe.yml. Recipes with this in them:

extra:
  eca:
    auto_reapply: true

Should cause ECA, when it intercepts the RecipeAppliedEvent, to extract only the config actions from the recipe -- all of the config actions, not a subset -- and smush them into a new model that runs every time that same recipe is reapplied.

The ECA plugin should be pretty dumb -- it should simply take a serialized(?) array of config actions and run them mindlessly through the ConfigActionManager::apply() method.

This will obviously require upstream changes in ECA but I think we're not far from being able to do this.

I agree with #15 that we don't want ECA to try and be too smart here. For our immediate needs, it is totally fine if the recipe author has to build the ECA model manually.

So really, all we need here is an ECA action plugin that can take an array of config actions and apply them (ConfigActionManager::applyAction()), pretty much as dumbly as possible.

The thing Jim and I agreed on with @alexpott is that we don't want the ECA model to just reapply the recipe wholesale, since the underlying config (i.e., the imported stuff) could change and possibly break things. And we don't want to freeze the recipe in time, for the same reason. The config actions are the main event -- they are also idempotent by design. What they say to do, is what happens. That seems like the correct fit for ECA.