Extend cache actions beyond ECA

This MR keeps all the ECA related cache actions in place and adds 3 equivalent actions for "raw cache" operations.

Back then we had a discussion on what scope ECA should support when dealing with certain backends (cache, state etc.). It's somewhere in the issue queue where I implemented all these actions. We agreed on the limited scope, so that we don't get into unforseen trouble. I advise to not support "just everything". Touching raw data of other components outside of ECA is a high risk on opening a Box of Pandora.

Since, a developer could access them by creating a custom module anyway.

For such a case, it makes sense that a developer takes care of it, either with a custom module or a specific custom action that takes care of it properly.

The discussion was at https://www.drupal.org/project/eca/issues/3277898#comment-14516498 → back in May 2022:

Q: This is caching in an ECA "sandbox", i.e. we do not grant access to other caches in the Drupal instance, correct?

A: Yes correct, this mechanic is supposed for ECA-related stuff only. Affecting other caches can quickly break a site's performance which may lead to downtimes etc. Touching other caching parts of Drupal should be a developer's task.

I'd think that we've learned a lot ever since. ECA is here to replace custom code for those who prefer to do that. And most of the stuff in ECA is capable enough to break sites. Especially because it allows to switch to user 1 where it is possible to delete in fact every entity without limitation.

That said, it might become a requirement to introduce some sort of permission system to protect the usage of certain plugins during the modelling phase, i.e. to only grant access to certain plugins for users with special permissions. Very much like the restrict access: true property on permissions.

Agree @jurgenhaas.

@mxh It seems like we'd be limiting ECA's scope just for this use case. If a vision for ECA is to indeed empower non-developers and alleviate custom development, then this would be extremely powerful. Personally, ECA has already allowed me to eliminate 30-40 modules. But also realize the project needs some guardrails.

That stated, ECA is life-changing without this capability...and completely respect both of your pov's. Just my $0.02.

For me, the features are very helpful.

Taking this one carefully and being fully aware of the responsibility we take, I think it's reasonable to accept this MR with 3 pro and 1 con advice.

One test is failing.

Furthermore, no tests were added to the new actions yet. In general, adding automated tests to new plugins is always recommended.

Having a look at this.

MR303 fixes the failing test, as the trait had a wrong copy-paste from the previous logic. I had to adjust that accordingly, otherwise our cache configured actions behave differently when using 1.2.x branch (cache invalidation currently doesn't work at all).

#16 still remains open.

Oh, I see my mistake. Thanks for finding and fixing this. I've merged this after a small adaption in \Drupal\eca_cache\Plugin\Action\EcaCacheTrait::getCacheKey for better readability.

Assigning the issue to myself for work on the missing tests.

Tests for the extended cache actions are ready for review.

Test was added, which is pretty nice.

Great, thanks a lot. This is now also merged and closed.

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

Can we merge this into one of the newer dev branches?

@eswiderski this got merged into the latest dev release back in February already. As it is a new feature, it won't go back into 1.1.x, though. If you need to make it available in 1.1.x for one of your installations, you needed to patch your installation.

Ok, was it merged into 1.1.x-dev and 1.2.x-dev? I'm not seeing any difference behavior in 1.1.x-dev.

No, it's only merged into 1.2.x (which is now 2.0.x) and won't get into 1.1.x because it's a new feature and not a bug fix.

Ahh, ok thank you! I was still using 1.2.x-dev.