I came here to ask for the same thing. I assumed I might be able to accomplish something like this by theming the views-view-collapsible-list.html.twig file, but all of the Views-supplied fields are grouped together there.
I'm seeing similar, but do not have the context_stack module.
User warning: Trying to overwrite a cache redirect with one that has nothing in common, old one at address "languages:language_interface, theme, user.permissions" was pointing to "url.path.parent, url.path.is_front, route", new one points to "url.path". in Drupal\Core\Cache\VariationCache->set() (line 138 of core/lib/Drupal/Core/Cache/VariationCache.php).
Drupal\Core\Cache\VariationCache->set() (Line: 92)
Drupal\Core\Render\RenderCache->set() (Line: 127)
Drupal\Core\Render\PlaceholderingRenderCache->set() (Line: 584)
Drupal\Core\Render\Renderer->doRender() (Line: 504)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 135)
__TwigTemplate_7933b1592f1978df929103e8f2b9cd6d->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 98)
__TwigTemplate_036e62bb102d1f6e378f9094f7809ad1->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
call_user_func() (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)
Thanks for your remarks - I'm hoping to get back to this within the week, but having trouble getting set up or understanding how/where I can see your comments in context. Keep getting "make sure you have the correct access rights and the repository exists" errors, despite generating and adding the necessary keys and being able to edit through the website. Will need some more time to fix that before I can work more efficiently, but to answer a couple questions:
1) I had it in the Content submodule because I wasn't having luck (yet) comparing anything other than simple arrays, which I expected (and my use case was specifically) from simple text (list) fields in entities, but as it grows, you're right, I could see it being useful elsewhere.
2) I don't have strong feelings about "first/second" vs "primary/secondary", and could very easily be more encumbered by being a native English speaker! Your perspective is appreciated, and I agree, "first" and "second" could be more easily understood by all. I was trying to imply a little more than just numbering, but rather that the "primary" array would be the one on the left side of the array_function - the one to be compared to others - if you want to know what's in one array but not another, it's like a "left join" where some importance is communicated by the first one being "more important", so I called that "primary".
3) Yes, this was all copied/pasted from a different iteration in which some of the language was project-specific. I'll make some adjustments when I can see your comments in context a little better.
Yikes. Sorry for all the cruft above. Fumbling my way through!
Done - thanks for the advice and patience. First time getting through the MR process on drupalcode.
This patch adds the described functionality but needs code review and testing.
Ive reported my two distinct issues at:
And one more comment to confirm that this seems like an upstream thing - I'll have to keep an eye out for CKEditor on other sites to try there, too, but when I visit https://ckeditor.com/ckeditor-5/demo/editor-types/ in my phone's Firefox browser, I got exactly the same results:
"Here's a new year" immediately becomes "Here's a new yearnew" in their own demo field.
All of that said, I think I DO see some issues in Chrome as well. Using that same filter-free version of CKEditor5 text, I tried some typing and while it isn't quite the same as the behavior I reported in Firefox, I try something like "I wasn't expecting this to work". No duplicate words happen. I hit the backspace key and it deletes the "k", but also jumps backwards over the "r" instead, leaving my cursor between the "o" and the "r".
For explanation purposes, I'll insert a pipe where my cursor ends up (in Chrome, NOT in Firefox):
1) Type "12345"
2) Hit backspace
3) read "123|4"
4) hit backspace
5) read "12|3"
6) On a new line, Intend to type "Here's some text", but accidentally get "Hers"
7) hit backspace, and the entire word disappears (common behavior)
8) re-try successfully typing "Here's some text"
9) hit backspace
10) read "Here's some te|x"
Found this issue because I'm just starting to develop a new site (Drupal 10.3.1, early stages, so very few additional modules or theme work done yet) and I found recently that while adding some test content in CKEditor5 fields, I get duplicated words while swiping/typing. I've repeated this on a second site, as well, too. In my observation, it's more a matter of words leap-frogging each other. For example, after typing a third word in a phrase, suddenly the second word reappears just after what I typed, and the effect is immediate - no additional movements to copy/paste or select any auto-suggestions.
I don't experience this in plain text (long) fields or plain text fields, so the CKEditor5 involvement was my first guess. I can't say for sure what behavior reliably recreates this issue, but safe to say that when adding and editing my first node with a Body field, it became so frustrating that the dummy text I was typing became ABOUT how annoyed I was.
This 10.3.1 site is not upgraded from a previous version, I'm on Android and using Firefox. Typing something like "I just want" and hitting the space bar to type the next word, suddenly the text in my field reads "I just wantjust", and interestingly enough, the cursor remains at the end of "want" before the duplicated "just" as I would expect in normal circumstances. This keeps happening as I try to add more text, making it a constant two-steps-forward, one-step-back affair.
To test this further, I then opened the same node from my phone in Chrome and added more text. While I had plenty of frustration with words improperly being "recognized" from my swiping, this word duplication issue seemed not to happen.
I saved the node, switched back to Firefox and typed "Back to Firefox" which immediately changed to "Back to Firefoxto".
I would love to find a solution to this!
Android 14
Samsung Galaxy S22 Ultra
One UI version 6.1
Firefox 128.0.3
Chrome 127.0.6533.65
Thanks for all the recent work on this. Juggling multiple projects, but just today implemented your newest release (2.0.1) and so far, everything is working well - though at this point, that means that other tasks are all running smoothly: clearing cache, running update.php, etc. I don't have more work to do on the primary project that has to do with ECA and/or eca_vbo, but this is promising.
Promising enough that I also updated to 2.0.1 on a separate project with many more eca_vbo-related ECA Models, but THAT site had still been on ECA 1.x and eca_vbo 1.x, and as you said, had never experienced any such issues (not the performance issues with infinite recursion, nor the other issue I opened about disappearing checkboxes). I implemented the update along with everything else to get up to Drupal 10.3.1 and will see how that goes, but again, promising!
I'll keep an eye on any other issues and report back, but the next two weeks include a lot of away-from-keyboard time, so I might not be able to have much else soon, except to say that my colleague - while downloading our latest code base with MR !2 still implemented above - also experienced the disappearing eca_vbo checkboxes in the site that only has one such view, but as I've noticed, only re-saving the related ECA Model cleared that up on the next reload. We'll see if it recurs with the latest commit.
If nobody else reports having the original infinite recursion issue here, then hopefully this can be closed!
@mxh - this may not be very helpful, but when I switch from applying MR !2 as a patch to MR !3, performance issues come back. I'm not sure I can reliably recreate the issue, but as @jurgenhaas described, it seems that pages (especially one where the View implementing eca_vbo functionality) take an excessive amount of time most often just after a cache clear. When I switch back to MR !2 instead, that problem disappears and everything appears to work well. No stack traces or watchdog entries to help, unfortunately.
Too early to say if my other issue (the disappearing checkboxes) remains with either of those patches because THAT problem was only intermittent, as well, and in the process of developing my model (using MR !2), I discovered that I was in fact overthinking my Model workflow, and that I could remove the "Entity Load" Action that I had been testing, so for the other issue I've opened, there may be something completely different going on having to do with my own assumptions and choices there.
For now, I'll keep MR !2 in place to continue building out the functionality we need, but am hoping for a stable solution to be found soon. Thanks for your help on this!
@mxh - I have not tried MR !3 yet, no.
Only MR !2, but with that, plus your hints from #13 already in place, I was getting the issue I reported separately.
I'll be able to try MR !3 next week. That should be done as a separate test from the changes in MR !2 (reverting those changes first), correct?
Thank you, mxh, my ECA model does include the "VBO: Custom access for Views bulk operation" (I've done this with several other models on other sites successfully) and my view does include the "Global: ECA bulk operations" field". The proposed code edits by jurgenhaas allowed me to move forward on development for now, but I'll continue to test the other issue that I opened, as even with those pieces above, I see the bug of the disappearing checkboxes every once in a while. I'll report back more on that thread if I can offer anything more.
So far, so good! I've opened another issue that has come up now, but I don't know if it is related to these specific changes. The good news is that by using the adjustments to static variables as in your MR, I have been able to move forward without re-experiencing the resources issues that had been plaguing this project after enabling eca_vbo.
The new issue is here: https://www.drupal.org/project/eca_vbo/issues/3464059 🐛 Edits to model appear to break configuration in View Active
I'm not sure this is completely fixed.
Building out a new D10 site (currently 10.3.1) where we use Webform as a per-entity registration form and ECA to handle various automated tasks, we got to a stage where we want to start building models that can get triggered in bulk when viewing a the webform submissions attached to a node.
This site is still very much in early stages with fewer than 10 such event nodes and/or webform submissions to list, and there are only 6 or 7 ECA models built; just one single model and one single View which implement the VBO functionality so far.
After adding and enabling the vbo and eca_vbo modules (2.0.0), we immediately began noticing resource issues, mainly "allowed memory size... exhausted". This is true on both local development (DDEV) and test server environments where we tried increasing settings such as "memory_limit" in our .user.ini file, but with not much improvement. Occasionally pages will fail with a white screen and short message to help, and finally one of the messages appeared with more detail:
ECA ran into error from third party in the context of "Collecting all available actions": Allowed memory size of 536870912 bytes exhausted (tried to allocate 126976 bytes) Line 113 of /var/www/html/web/core/lib/Drupal/Core/Database/StatementWrapperIterator.php
To attempt some basic troubleshooting, I modified the /eca_vbo/src/Plugin/Action/Derivative/VboExecuteDeriver.php file to wrap one of the foreach loops with an artificial limit:
$i = 100;
while ($i > 0) {
foreach (($eca->get('events') ?? []) as $event) {
if (!in_array($event['plugin'], $plugin_ids, TRUE)) {
continue;
}
$operation_name = $event['configuration']['operation_name'] ?? '';
$action_id = strtolower(preg_replace("/[^a-zA-Z0-9]+/", "_", trim($operation_name)));
if ($action_id !== '' && $action_id !== '_') {
if (!isset($this->definitions[$action_id])) {
$this->definitions[$action_id] = [
'label' => str_replace('_', ' ', ucfirst($operation_name)),
'operation_name' => $operation_name,
] + $base_plugin_definition;
}
$this->definitions[$action_id]['eca_config'][] = $eca->id();
}
}
$i--;
}
Not knowing exactly how this is SUPPOSED to exit cleanly, I wanted to see if functionality returned, and it did. Without the artificial limit above, I quickly get errors that begin like the following trace:
The website encountered an unexpected error. Try again later.
Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '1000' frames in Drupal\Component\DependencyInjection\Container->hasParameter() (line 342 of core/lib/Drupal/Component/DependencyInjection/Container.php).
Drupal\Component\DependencyInjection\Container->get('string_translation') (Line: 197)
Drupal::service('string_translation') (Line: 215)
Drupal\Core\StringTranslation\TranslatableMarkup->getStringTranslation() (Line: 190)
Drupal\Core\StringTranslation\TranslatableMarkup->render() (Line: 15)
Drupal\Core\StringTranslation\TranslatableMarkup->__toString()
sprintf('%s %s', Object, Object) (Line: 70)
Drupal\Core\Action\Plugin\Action\Derivative\EntityActionDeriverBase->getDerivativeDefinitions(Array) (Line: 101)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) (Line: 87)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() (Line: 337)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 213)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 22)
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('entity:delete_action:media') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('entity:delete_action:media', Array) (Line: 83)
Drupal\Component\Plugin\PluginManagerBase->createInstance('entity:delete_action:media', Array) (Line: 178)
Drupal\eca\PluginManager\Action->createInstance('entity:delete_action:media', Array) (Line: 62)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->initializePlugin('entity:delete_action:media') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('entity:delete_action:media') (Line: 18)
Drupal\Core\Action\ActionPluginCollection->get('entity:delete_action:media') (Line: 88)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration(Array) (Line: 104)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->addInstanceId('entity:delete_action:media', Array) (Line: 55)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->__construct(Object, 'entity:delete_action:media', Array) (Line: 114)
Drupal\system\Entity\Action->getPluginCollection() (Line: 130)
Drupal\system\Entity\Action->getPlugin() (Line: 145)
Drupal\system\Entity\Action->getPluginDefinition() (Line: 72)
Drupal\eca\Plugin\Action\PreConfiguredActionDeriver->getDerivativeDefinitions(Array) (Line: 101)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) (Line: 87)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() (Line: 337)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 213)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 22)
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('action_message_action') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('action_message_action', Array) (Line: 83)
Drupal\Component\Plugin\PluginManagerBase->createInstance('action_message_action', Array) (Line: 62)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->initializePlugin('action_message_action') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('action_message_action') (Line: 88)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration(Array) (Line: 104)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->addInstanceId('action_message_action', Array) (Line: 55)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->__construct(Object, 'action_message_action', Array) (Line: 871)
Drupal\eca\Entity\Eca->getPluginCollections() (Line: 165)
Drupal\Core\Config\Entity\ConfigEntityBase->set('weight', 0) (Line: 163)
Drupal\eca\Entity\Eca::postLoad(Object, Array) (Line: 389)
Drupal\Core\Entity\EntityStorageBase->postLoad(Array) (Line: 319)
Drupal\Core\Entity\EntityStorageBase->loadMultiple() (Line: 56)
UPDATE:
Never mind. Egg on my face, as I discovered buried under the ECA Settings an indication that [session_user] might only be available if I configured ECA to always run under a specific account. I had not done that (yet), and found that indeed this worked as advertised.
Perhaps this could be highlighted a bit more in the documentation? Or else maybe make the [session_user] ALWAYS available (especially as a feature when the "Switch User" Action is used)?
My second test (triggered by a simple entity view) has a similar result:
event: machine_name: eca.content_entity.view
event:machine_name: eca.content_entity.view
session_user:
session_user:account-name:
session_user:uid:
session_user:id:
current_user: 7
current_user:account-name: harri740
current_user:uid: 7
current_user:id:
In this case, I'm actually logged in as user 1 and masquerading under my personal account, which is correctly reflected under the [current_user] tokens, but the [session_user] still is not. To do this "the ECA way", I further modified this model to switch user to my personal account before displaying the message and re-triggered it as user 1 again (not masquerading), and the results were identical to the above.
Update: Although we thought simply reverting to Token 1.12 fixed our issue with smart_date tokens, we're seeing continued odd behavior in a subset of cases.
The smart_date tokens ARE available for our needs as automatic entity labels, but since we're using a complex combination of moderation_state and a multi-step form, we do have cases where a user might save our form as as "Not Ready" (a published state we created to replace "draft") - call it "Save 1" - BEFORE editing the fields in which we use smart_date. If they do this, then return to edit, adding in the smart_date values, the node gets saved again (call that "Save 2") WITHOUT the smart_date range token values being included in the node title.
Many of our users stop there (they have completed the form and are satisfied marking it as "Submitted" - another published moderation_state). We see that the smart_date tokens do NOT get added to/replaced in the title, however, UNTIL the next save ("Save 3") of that same node (even without further edits to any field).
It seems as though the automatic entity label is using the smart_date tokens from the original node field values (dates still empty) on "Save 2", but everything is fine and the tokens are replaced as expected on "Save 3".
In contrast, if the user comes in and fills out the form completely (new entity being inserted, smart_date field values added on first save), then the smart_date tokens are replaced correctly in the title of the node.
We're seeing the same behavior using Drupal 10.1.5 and the latest version of Token Filter and Smart Date. Reverting to Token 1.12 fixed the issue for us (for now).
I had a need for this, too, so I wrote this submodule which seems to work pretty well. It could use some review and polish, however.
I'm not sure if it's necessary to pass the $entity to the execute() function, for example, and I'm not sure if this strictly depends on the drupal/node, they were carried over from how I had written this for Business Rules and/or other ECA submodules I was using as inspiration.
Patch attached.