>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3323723. --> Reported by: [jurgenhaas](https://www.drupal.org/user/168924) >>> <h2>0&#65039;&#8419; Who is here today? Comment in the thread below to introduce yourself! We&rsquo;ll keep the meeting open for 24 hours to allow for all time zones.</h2> <table> <tr> <td>jurgenhaas</td> <td>J&uuml;rgen from LakeDrops :clap::skin-tone-4:</td> </tr> <tr> <td>mxh</td> <td>Max from OpenCampus :wave:</td> </tr> <tr> <td>Daniel Speicher</td> <td>Daniel from LakeDrops</td> </tr> <tr> <td>rkoller</td> <td>ralf :wave:</td> </tr> </table> <h2>1&#65039;&#8419; Do you have any topics to propose for the meeting today? Post in this thread and we&rsquo;ll open threads for them as appropriate. Or you can post them directly in the channel with the next number as an icon. That topic will then turn into a thread for the comments.</h2> <table> <tr> <td>Cyril</td> <td>I think documentation could get a look at.&nbsp; As a frontend guy I can't help much with development, but I could help out with this.</td> </tr> <tr> <td>jurgenhaas</td> <td>@Cyril have created thread 7&#65039;&#8419; in the channel, let's dicuss this there</td> </tr> </table> <h2>2&#65039;&#8419; ECA positioning - for the last 1.5 years we described ECA as a rules replacement for Drupal 9 and beyond. This is not good enough as ECA is more than that and we'd like to discuss, how to best describe it otherwise.</h2> <table> <tr> <td>jurgenhaas</td> <td>Some proposed ECA framing ideas:- ECA provides no-code capabilities to fully automate Drupal sites.- ECA empowers you to fully automate your Drupal sites with no code.- ECA empowers you to fully control the automation of your Drupal sites with no code.- ECA empowers you to fully automate your Drupal sites without any code written.- ECA empowers you to fully control the automation of your Drupal sites without one line of code written.</td> </tr> <tr> <td>jurgenhaas</td> <td>We're open for more, or would like to hear what you all think about the given ideas?</td> </tr> <tr> <td>Daniel Speicher</td> <td>I think we should integrate the &ldquo;no-code&rdquo; explicitly into the name. For us, it is more than just a buzz word. I prefer the second</td> </tr> <tr> <td>rkoller</td> <td>i am still not satisfied with the suggestions from yesterday. i like to start with empower. but appending &ldquo;with no code &rdquo; or any of the other variants doesn&rsquo;t sound perfect :/&nbsp; but i agree to have a statement that there is no need of any code is mandatory</td> </tr> <tr> <td>boinkster</td> <td>As a developer, in many situations ECA replaces the need for custom modules. "automation" doesn't convey the breadth of what you can do.&nbsp; Maybe "leverage Drupal Core and Contrib to fully automate...</td> </tr> <tr> <td>jurgenhaas</td> <td>Good point, never thought of that this way. How about ".... automate and customize ...."</td> </tr> <tr> <td>rkoller</td> <td>how about &ldquo;orchestrate&rdquo; to combine that it is automated and customized?</td> </tr> <tr> <td>rkoller</td> <td>ECAA no-code solution that empowers you to orchestrate your Drupal site.</td> </tr> <tr> <td>jurgenhaas</td> <td>Like it, let that sink in - and see how it feels after a good night sleep :wink:</td> </tr> <tr> <td>Cyril</td> <td>ECA is no-code automation for your Drupal site.ECA is a no-code automation UI for your Drupal site.</td> </tr> <tr> <td>jurgenhaas</td> <td>Really like the 2 keywords "empower" and "orchestrate", the longer I think about it. So, Ralf's suggestion really is my favorite:ECAA no-code solution that empowers you to orchestrate your Drupal site.</td> </tr> <tr> <td>radzi ismail</td> <td>orchestrate is too advance meaning for non english speaking people. i can understand but i suggest a simpler word</td> </tr> <tr> <td>radzi ismail</td> <td>"ECA is no-code automation for your Drupal site." is a nice and clear phrase to describe ECA. IMO</td> </tr> </table> <h2>3&#65039;&#8419; 1.1.0-beta1 Release</h2> <table> <tr> <td>mxh</td> <td>Looks like all blockers are fixed, which may give a good time to switch from alpha to beta. I'm currently working on a small addition for eca_render, which is the ability to create a lazy render element. If I get this done today, maybe this can get into it before beta too. But other than that, I currently don't see any leftovers.</td> </tr> <tr> <td>mxh</td> <td>Here's the feature request for the lazy render element, ready for a review: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3323413" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3323413</a></span></td> </tr> <tr> <td>jurgenhaas</td> <td>Reviewed and merged. Getting ready for the beta1, probably tomorrow, again on a Friday :wink:</td> </tr> <tr> <td>jurgenhaas</td> <td>Just wondering if it were possible to provide a couple of sample models to demonstrate the render and endpoint and form features? Very simple stuff should easily do and get people on a track to experiment with these by themselves.</td> </tr> <tr> <td>mxh</td> <td>:partying_face:</td> </tr> <tr> <td>mxh</td> <td>Yes definetly makes sense to create some sample models. Hope I'll find some time for this. Was also thinking about creating some small tutorial videos for this topic. For the models I'll create according MRs on ecaguide's repository - just a mattoer of time resources :wink:</td> </tr> <tr> <td>jurgenhaas</td> <td>I know ...! If it makes things easier for you, just send sample models to me directly and I get them cleaned up and included into the guide.</td> </tr> <tr> <td>mxh</td> <td>perfect, will do</td> </tr> </table> <h2>4&#65039;&#8419; 1.2.0 Roadmap</h2> <table> <tr> <td>mxh</td> <td>Last time I suggested to focus on a11y issues. Not sure whether this idea still holds up, or is there another topic we should take a look at?</td> </tr> <tr> <td>rkoller</td> <td>well i&rsquo;ve tested eca and in particular bpmn in a first run through. only problem i had too many things in parallel lately and private things as well. difficult to juggle. :(&nbsp; and it is also quite tricky to report all those issues found. there was the consensus to report them upstream but problem is bpmn is split up in several subprojects (the properties panel, bpmn in general, the task panel). that way makes it not easier when auditing the subprojects together on the drupal within eca: what to report, where to report and how to chop it up. juergen suggested i should open several isolated highly focused issues about particular problems and maintainers could move them to the correct issue queue in case they were filed in the wrong place. but still challenging and head spinning how to communicate all the different issues the best way.&nbsp; and few days ago, during the a11y review call of project browser, i&rsquo;ve also learned about the fact that the windows high contrast mode is also available for edge on macos as well for a few months now. that opened another rabbit hole with several issues necessary to be opened.and back to your initial question. for sure focusing on a11y would be a good thing. but the two main problems i see. most work would be upstream (and it would be in the pace and timeframe of the camunda people).&nbsp; and for a few parts i am not sure if there will be a satisfying solution. for example how to communicate a model with more than 4 or 5 elements. how to announce the interconnections how to enable navigation with just the keyboard and just by announcing everything with a screenreader. a complex problem. as i already mentioned a few weeks ago someone brought my question over to the a11y slack. there there wasn&rsquo;t also a satisfying and practical answer yet. meaning there aren&rsquo;t any. i&rsquo;Ve also taken a look at miro and how they accomplish things. but that is based on their blog posts also more a work in progress. will be interesting when apple will be releasing freeform for ventura in the coming weeks. they have certain a11y requirements. will be interesting how they will approach the work in freeform with the keyboard and voiceover. and i&rsquo;ve also asked a few week ago in that issue <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/bpmn_io/-/work_items/3300252" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/bpmn_io/-/work_items/3300252</a></span> if the user who opened up the issue would have time and interest to have a video or audio call. just to get an idea what a practical and useful approach would be using an interface like bpmn. meaning what would be helpful and what would have to be introduced and or changed to enable the usage with keyboard and assistive tech like voiceover, jaws or nvda.&nbsp; complex over all :/.&nbsp;(edited)</td> </tr> </table> <h2>5&#65039;&#8419; How to deal with eca:update</h2> <table> <tr> <td>mxh</td> <td>This issue that is part of 1.1.x will break existing configuration that use queue events, unless the site owner executes "drush eca:update" as a part of the upgrade process. We'll note that in the release notes, but we're wondering whether site owners will be aware of it. It is the responsibility of a site owner to look what's coming in the updates by reading release notes IMO, however it might be that the majority in fact doesn't read the notes in detail.&nbsp;(edited)</td> </tr> <tr> <td>mxh</td> <td>As an alternative, we could include the eca:update logic in a update hook. There is a risk of damaging existing configs with this approach though, as we haven't used it much yet and in the early alpha/beta phase we did experience some problems with it.</td> </tr> <tr> <td>jurgenhaas</td> <td>Well, I'm using it quite frequently, i.e. every time there is a config update for one of the plugins.</td> </tr> <tr> <td>jurgenhaas</td> <td>Never had any issues, and the early problems came from significant other changes and a related bug, if I remember correctly.</td> </tr> <tr> <td>mxh</td> <td>ok, sounds good, shall we include it in an update hook then, maybe when it reaches RC1?</td> </tr> <tr> <td>jurgenhaas</td> <td>We can do that, just one additional consideration before that: we could end up with lots of similar update hooks over the years, every time we have a config change of a plugin, we have to have the same update hook. As that eca:update doesn't do anything, if nothing had changed, we could execute it every time, when updatedb is run. Is there a hook that would allow us to do that, i.e. running every tim even without an explicit update hook?</td> </tr> <tr> <td>mxh</td> <td>I don't know of such a hook / event, maybe someone else does?</td> </tr> <tr> <td>mxh</td> <td>besides that I'm not sure whether it's a good idea to run this everytime on updb, as this may unnecessarily consume resources.&nbsp;(edited)</td> </tr> <tr> <td>jurgenhaas</td> <td>There is hook_post_update_NAME but I'm uncertain if this is called only once too. The wording in the comment states something like that, but this could mean it runs only once per update session. There is another one hook_removed_post_updates which declares removed named hooks and if they won't be used repeatedly, I wonder why that second one would be required.</td> </tr> <tr> <td>jurgenhaas</td> <td>I wouldn't be worries about resource consumption. It just goes through all the ECA models and checks, if anything has changed and only if so, it updates that and save the config entity back.</td> </tr> <tr> <td>Cyril</td> <td>I am guilty of typically not reading release notes when updating unless it's a major version upgrade.</td> </tr> </table> <h2>Getting an error when navigating to /node/add/session</h2> <table> <tr> <td>mherchel</td> <td>I have a rule set up on content entity creation to send an email.The PHP error isDrupal\Core\Entity\EntityMalformedException: The "node" entity cannot have a URI as it does not have an ID in Drupal\Core\Entity\EntityBase-&gt;toUrl() (line 161 of /code/web/core/lib/Drupal/Core/Entity/EntityBase.php).</td> </tr> <tr> <td>mherchel</td> <td>if I remove the [node:url] token, I do not get that error message</td> </tr> <tr> <td>jurgenhaas</td> <td>The "Create entity" event is not what it seems to be. You may want to use "Insert entity" instead.</td> </tr> <tr> <td>mherchel</td> <td>Thank you!</td> </tr> <tr> <td>jurgenhaas</td> <td>The create entity event is triggered by Drupal core when PHP initializes the Node object to then fill it with values. So that's very early in the process and no real values are available at that point.</td> </tr> <tr> <td>jurgenhaas</td> <td>We've seen this issue many times and I wonder how we can prevent that event from being used by accident.</td> </tr> <tr> <td>mherchel</td> <td>yeah. It is confusing from a site builder's perspective</td> </tr> <tr> <td>mherchel</td> <td>to me, a relabeling should do it. Relabel it to something like "programmatically create node object"</td> </tr> <tr> <td>mherchel</td> <td>:man-shrugging:</td> </tr> <tr> <td>mherchel</td> <td>its working now! :raised_hands:</td> </tr> <tr> <td>jurgenhaas</td> <td>Yeah :tada:</td> </tr> <tr> <td>jurgenhaas</td> <td>Relabel it to something like "programmatically create node object"Just checked, we have access to that label from ECA and can indeed rephrase that. We'll handle that in an issue.</td> </tr> <tr> <td>mherchel</td> <td>Also, is there a way to set the from field in the email address?</td> </tr> <tr> <td>jurgenhaas</td> <td>The mail action from Drupal core doesn't allow that (yet). But with the upcoming Symfony Mailer integration, that will become possible.</td> </tr> <tr> <td>jurgenhaas</td> <td>AFAIK there is some discussion to also enhance the core mailer action, but I'm not sure when that's going to happen.</td> </tr> <tr> <td>mherchel</td> <td>Thank you!</td> </tr> <tr> <td>jurgenhaas</td> <td><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3323432" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3323432</a></span></td> </tr> <tr> <td>jurgenhaas</td> <td>Hi @rkoller if you had a minute, the above issue could benefit from your expertise :sunglasses:</td> </tr> <tr> <td>rkoller</td> <td>that i understand things correctly. the problem is the startevent Create content entity and that is the label in question here?</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes. "Create" is just PHP internal, whereas "Insert" and "Update" are triggered after the entity has been written to the database.</td> </tr> <tr> <td>jurgenhaas</td> <td>Also note, that we have the labels, visible in the UI, and we have hook identifiers, that all Drupal developers are aware of. Currently, the UI label and the hook name do match.</td> </tr> <tr> <td>rkoller</td> <td>hmmm the suggestion in the issue and in here was Programmatically create content entity that wouldnt be that clear to me either as a novice user. when i read that i think that is an order to programmatically create a content entity. but it is a start event. i&rsquo;ve revisited the draft for the micro copy changes. there i&rsquo;ve had create content entity&nbsp; changed to Entity created&nbsp; ( i have to add&nbsp; the general category is ECA Content therefore i&rsquo;Ve shortened my suggestion and removed content cuz the context content is already clear). but by going with entity created an event is described? would that be clearer? i ask because the other way around with programmatically create content entity wasn&rsquo;t that clear to me either therefore i am not sure if the other way around it might be unclear as well?</td> </tr> <tr> <td>jurgenhaas</td> <td>I think that "Entity created" suggests also, that this is the event, when the entity is completely ready for further processing. But it's not. At that point, just a "blank" object in memory is available, not very useful in most cases. However, it has some value, so dropping that event entirely, isn't an option either.</td> </tr> <tr> <td>rkoller</td> <td>ahhhhhh to clarify and that i understood things correctly. with createa node is created and &ldquo;prepared&rdquo; in memory. at this point a token for urls ([node:url]) ) like make tried to use is not available yet. that would become available as soon as the node was &ldquo;inserted&rdquo; aka written to the db? does that sum things up correctly in laymans terms?</td> </tr> <tr> <td>jurgenhaas</td> <td>Exactly right.</td> </tr> <tr> <td>rkoller</td> <td>then tbh i doubt that either programmatically create content entity nor entity createdwould fix the situation mike ran into. cuz the event is correct. meaning the entity was created. but there arent all options and actions available in that state. and by only reading each of the label suggestions would explain that imho :/ have to think about it. one option that would come to mind is &ldquo;if&rdquo; it would be possible that the token browser in drupal would be integrated into bpmn and be context aware which tokens are available then the error would be prevented. one problem is still people going with the create content entity startevent would be confused why the token wouldnt be available. and on the other hand the way bigger problem is that the integration is a way too big of a task. tricky. as i said have to think about that one for a bit tonight what other options there might be.</td> </tr> <tr> <td>jurgenhaas</td> <td>The danger zone is not limited to tokens, unfortunately. That said, I think we need to create awareness at the event selection - like big warnings: "do you really want to use this? It's very unlikely this is the correct one" kind of thing.</td> </tr> <tr> <td>rkoller</td> <td>to provide some sort of disclaimer might be a good thing. just stating that in the state the created node is in not all functionality is available until it had an insertion event?</td> </tr> </table> <h2>7&#65039;&#8419; Next steps with documentation</h2> <table> <tr> <td>Cyril</td> <td>I think with the screencasts that are available and ecaguide.org there is enough to get started and start exploring the module. Once I got my head around how it works and seeing it action, it becomes a bit intimidating over how powerful this module can be.</td> </tr> <tr> <td>jurgenhaas</td> <td>The documentation is hosted at <a href="https://ecaguide.org">https://ecaguide.org</a> and there is a link in the top right corner to a git repository with the source, which is mainly markdown.</td> </tr> <tr> <td>jurgenhaas</td> <td>I wonder if we should start planning the next steps in issues over there in that GitLab project. Once we have drafted the next steps we should take, everyone who wants to contribute can take on issues there.</td> </tr> <tr> <td>Cyril</td> <td>That sounds good. I think filling out the Plugins definitions would be important.&nbsp; And adding a line that states what the event is called in the ECA files would help with the examples in the Library.</td> </tr> <tr> <td>jurgenhaas</td> <td>what the event is called in the ECA files would help with the examples in the Library.What do you mean by that?</td> </tr> <tr> <td>Cyril</td> <td>Going through the files from the examples in the Library section it's not immediate obvious from&nbsp; some of the plugin labels what event is being used. For example, the condition 'eca_route_match' doesn't match any condition in the UI.&nbsp;(edited)</td> </tr> <tr> <td>jurgenhaas</td> <td>Got it. Do you know you can download each of the examples and import to your Drupal site?</td> </tr> <tr> <td>Cyril</td> <td>Yes, I imported a few and some I just looked at the files. Also the above example is no good, because there is indeed a route_match condition in the UI, but there was one example where I had trouble matching the right event based on the plugin label. I can't seem to find it right now, but I'll update if I do.I suppose it's not really a big deal though. Better to spend time getting the plugin defined.&nbsp;(edited)</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes, a lot to do there, but also I'm convinced we can move quickly and get gerat result in a short period of time - we just need to get around it</td> </tr> <tr> <td>Cyril</td> <td>Right. So moving forward should discussion happen in Slack, drupal.org, or the gitlab repo?</td> </tr> <tr> <td>jurgenhaas</td> <td>I think, planning of tasks and assignments should happen on GitLab. Discussion can happen here in Slack</td> </tr> <tr> <td>Cyril</td> <td>Understood. And besides the plugins definitions what are some priorities for documentation?</td> </tr> <tr> <td>jurgenhaas</td> <td>The idea is to go through the issue queue and put everything into documentation that had been resolved in the support category, this seems to be valuable knowledge.</td> </tr> <tr> <td>Daniel Speicher</td> <td>Good idea. In December I have time again to continue writing docs.</td> </tr> <tr> <td>radzi ismail</td> <td>few thoughts:first - the library section of drupal guide is good for a beginner but not enough examples for advance usage of ECA. example on loops, queues, tokens and many others still not enough to take advantage of ECA capabilities</td> </tr> <tr> <td>radzi ismail</td> <td>second - no example (or maybe i cant find it) on ECA third party modules like tamper, flag, VBO and many others</td> </tr> <tr> <td>radzi ismail</td> <td>third - its not clear on how to contribute example ECA models to ECA guide library and to submit video tutorials done by ECA users. my suggestion is to instruct user to create a new issue under documentation category/component when people want to submit their work or tutorial on ECA. from here ECA maintainer can select which model and which video can be publish at ECA guide</td> </tr> <tr> <td>jurgenhaas</td> <td><a href="https://ecaguide.org/#how-to-contribute">https://ecaguide.org/#how-to-contribute</a></td> </tr> <tr> <td>radzi ismail</td> <td>forth - every demo done in public or for private audience should be recorded and link back to ECA guide</td> </tr> <tr> <td>jurgenhaas</td> <td><a href="https://ecaguide.org/videos/?h=contribute">https://ecaguide.org/videos/?h=contribute</a></td> </tr> <tr> <td>radzi ismail</td> <td>thanks for the reply. most people will go to <a href="https://www.drupal.org/project/eca">https://www.drupal.org/project/eca</a> to get information regarding ECA and only some people will go to ECA-guide.org to read information. i can see the instruction on how to contribute to documentation on the last part of ECA page on drupal.org on "Join The Team" but its still a bit simple and the only link at the "join the team" section is to ECA slack. i hope there will be more emphasis on how to contribute on documentation as a lot example posted on issue queues still stay on there.</td> </tr> </table>