jdleonard → credited freelock → .
Hi,
You're right, I get the same thing from the parent getPropValue method.
Cheers,
John
Oh sorry, looking again, we're not subclassing that method -- we're just calling it. As a private function we cannot use it -- it needs to be protected so we can call it from our subclass's getPropValue() function.
You can see our usage here: https://git.drupalcode.org/project/megamenu_sdc/-/blame/1.0.x/src/Plugin...
... we could create another copy of this code, but much easier to call existing...
Hi,
Ok, I see that method returns the result of getMenuItems(). We can definitely extend that instead, if that's the only place it gets called.
Cheers,
John
@dalemoore that's exactly what I was trying to do. It uses a plugin to get child items, which is not currently part of UI Patterns.
I've gone ahead and bundled it up into a module - MegaMenu SDC → . There is a bug in UI Patterns that currently requires a patch - ✨ Cannot subclass MenuSource plugin due to private method getMenuItem() Active .
As discussed at DrupalCon, we found a different approach to solving our particular issue -- @pdureau created a MenuContentSource plugin extending the MenuContent plugin which could then provide the link content we were missing.
So our need was solvable using UI Patterns plugins instead of a preprocess function.
Updating status.
MR created.
freelock → created an issue.
Just curious -- for people still affected by this, do you perhaps have ECA Form module enabled? I'm wondering if it's related to this: 🐛 ECA Form breaks complex IEF widget Active
Hi,
I'm hitting a need for something like this now, trying to create a menu_item SDC for a megamenu.
Using Menu Item Extras, you can add fields to menu_item_content entities, and then use layout builder on top-level menu items to manage the contents of each megamenu pane (as fields on the top level menu items).
We've done this without SDCs. But now trying to make an SDC, we've created a menu_menu SDC and a menu_item SDC, and placed the menu_menu SDC using UI Patterns, as a block. So far so good, we have our menu. But no menu_item_content entity.
Menu Item Extras makes use of preprocess functions to render child links as appropriate -- but these never get called when you hand off to an SDC, and I'm really struggling to figure out how to get them in there. The items do have a "below" array of child items, and each item does have an "original_link" value that returns a plugin -- not the entity, but just a plugin. That does have an id of "menu_item_content:" so what I'm currently doing is extracting that UUID, and then using Twig Tweak's "drupal_entity" to render the actual link.
I think I can get this to work -- but it feels a bit nasty and introduces other dependencies (Twig Tweak). The "drupal_entity" call goes back to the theme layer, calls the theme hook, which then needs the child SDC added to the template.
I would much rather simply call the child SDC (menu_item) from within the parent, but I don't have any access to the menu_item_content entity!
A preprocess function of some kind would allow me to add a reference to the actual entity inside the items array, and then this wouldn't have to jump out to the theme layer and back for each item.
Is there a better way to solve this? Was also thinking I could possibly decorate whatever is building the menu tree to add those references.
Awesome!
teknorah → credited freelock → .
Would love to participate! Not a whole lot of time.
Oh wow, looks like the code I wrote for commerce_membership (name on Drupal.org) is implemented in the site as "membership_commerce". It's not very big -- ~260 line .module file with several hooks, a service with some convenience functions, and two PriceResolver services.
It also looks like these aren't written in a portable way -- field names are hard-coded instead of looked up from config. Went ahead and pushed what I have up to Commerce Membership → .
Membership entities do require an owner, but we have used it on sites where the owner is the only user, and additional members I think used Profile → entities -- at some point on a D7 site we made some custom code to allow an existing profile to be associated with a new user... we've managed membership sites for families with children that do not have email addresses or logins but still needed to be distinct (a sports academy that had open field time as well as lessons).
If Commerce License requires a user, that would be why we didn't use it...
Architecture-wise, I fully agree -- only one of our sites used Group with memberships, and having different entities for Users, Profiles (or Contact), Memberships, Membership Terms, Payment subscriptions makes a lot of sense, especially with ECA now available to build actions to sync data to whatever entities your site needs.
As for no-cost memberships, easiest was to set the membership term to "lifetime". I don't think that is correctly built in the membership module -- I think we set a date 20 years in the future as a short-term placeholder behavior -- I haven't had a customer yet that wanted a membership that didn't expire. (We did hit the Unix Y2K/2038 bug doing this!)
I have used Commerce Recurring for automatic renewals. I forget exactly why we didn't use Commerce License -- we had a reason at the time, but maybe whatever it was is no longer an issue. Could Commerce License be used to purchase a group membership, instead of a site role?
I've built 3 sites using Membership module -- unfortunately none are active anymore. I did a fair amount of refactoring to make that more clear -- the current maintainer had different goals, but the overall structure can be part of the solution.
The most recent site was for a company that was selling subscription access to its services, and its customers were businesses that typically bought 5 or more seats -- they had a couple different pricing tiers based on number of logins. It was essentially a domain-specific SaaS. I ended up using both Membership and Group to make this work. And it did work, with some glue code (this was before I was a big user of ECA).
Membership provides two entity types:
- "Membership" which was a permanent entity for a particular account -- might be pending, active, expired, or in some cooldown period -- you can set different state machines to allow grace periods for renewal. So this contains the current status, along with any number of members. You can have different bundles here for different levels of access.
- "Membership Term" - this uses a special plugin so it can connect directly to external membership providers, at first. I created a general "membership_term" plugin so you could manage memberships entirely within Drupal. This entity represents the current active period, with the plugin defining details around how to handle fixed vs floating membership periods, handling pro-rating amounts for partial periods, triggering automatic renewals if connected to Commerce, and renewal notices at various points (I made a "Scheduled Message" module just for this reason, but none of our active sites still use it, we've replaced that with ECA). You make different bundles of this for different membership lengths.
I had also created a Commerce Membership → module, and we did have it working, but the client pulled the plug on the whole project before we had that wrapped up -- I can find and post that code.
On this project, we used Group to enforce access. The custom code was simply keeping the various modules in sync -- sending people to buy more seats if they tried to add more users than they had in their agreement, pro-rating additional memberships so we could use the same membership term with a new quantity, making it easy to invite new users to your membership, etc. All the app's functionality was inside the group, so without group membership, authenticated users couldn't do anything other than purchase a membership and browse some help pages.
I did find myself refactoring a lot of the membership term code, and sent a bunch of patches to the maintainer, most but not all are in the Membership module.
Created new branch rebased on 2.x -- previous branch no longer applied.
freelock → changed the visibility of the branch 3377609-implement-token-replacements to hidden.
Merged.
It looks to me that this action plugin replaces the existing image, instead of generating a derivative image?
That's not what I'm looking for -- I want to just generate the derivative image. For content created programmatically, the derivative images don't exist until somebody visits a page that renders the specific image style you want. When posting images to social media, you might have an image style that isn't rendered when you want to send that image, and this can cause errors/failed posts.
Also check out Membership → module. This module creates two custom entities: one for the actual membership, and another for the "membership term".
I built out 2 sites using this, one of them tied membership terms to commerce -- unfortunately the client pulled the plug and went an entirely different direction. That was built in Drupal 9. I do have some code in github and elsewhere to assist with this.
Membership uses state machine → , which provides a nice form for transitions, and has decent support for ECA, so would be fairly easy to add/remove particular roles based on membership term start/end. We've also used this model to send reminders before a membership expires, sending only to people who have not yet renewed.
Closing as duplicate of 🐛 Parameter "arg_0" must match "[^/]++" Needs work .
Ok, the problem is, the default branch is 8.x-1.x -- I had to manually change the target branch to 2.0.x.
freelock → changed the visibility of the branch 3508587-conflict-with-ai to hidden.
freelock → changed the visibility of the branch 3508587-ignore-non-http-exceptions to active.
freelock → changed the visibility of the branch 3508587-ignore-non-http-exceptions to hidden.
Wow, not sure what happened with this MR -- it's a lot more than the 2 lines I changed. Trying to get an accurate branch here...
freelock → changed the visibility of the branch 3508587-conflict-with-ai to active.
freelock → changed the visibility of the branch 3508587-conflict-with-ai to hidden.
freelock → created an issue.
No, my time got taken up, probably won't be able to spend any time on this until DrupalCon or later...
Hi,
Unleash got my attention recently, as a more generic solution here. It's open source, self-hostable, plus there's a paid service that can be used... and Symfony support.
With a separate feature flag solution, flags can be enabled per environment, making it much easier to move databases around, supporting A/B testing, and a bunch of other scenarios. I'm wondering if something like this should be considered as an optional core service...
See 🐛 Whitescreen in Layout Builder when a data feed icon with argument is attached to a block Active for an example case using Views Data Export. The patch in this issue fixes that for me.
My site uses "field_image" for the image field name in Media. Before applying this patch, I could generate an image, but after saving it was lost entirely, and the media item had no thumbnail or anything.
After applying this patch, it works as expected -- after generating the image, it's properly attached to the media item.
Looks like an instance of 🐛 Parameter "arg_0" must match "[^/]++" Needs work .
freelock → created an issue.
That issue does sound very similar. One difference is that we were seeing the issue with limited cardinality, too -- although a cardinality of 6... but I'm guessing if ECA is replacing the form_state for some reason that might do it...
We are hitting this issue on a bunch of sites -- or rather 🐛 Integrity constraint violation when trying to add multiple blocks in a complex IEF field Active , which I did not think ECA had anything to do with until someone left a comment there about ECA. All of the affected sites have ECA enabled. Here's the gist of what we're doing:
1. Install IEF, ECA Form modules
2. Create a "featured block" entity reference field on a content type, e.g. "Basic Page", referencing content blocks.
3. Set the field to use the complex IEF widget
4. Create a new page, and create a new block using the IEF widget.
If you save now, everything is fine. If you edit the page and add another block, it works fine -- so long as you only ever add one block at a time.
5. If you add a second block without saving the node, it appears correct -- it adds another row to the IEF widget, and you can keep adding more.
6. But if you save, you get the Integrity Constraint Violation, duplicate entry 'xxx' for key 'node__field_uuid_value'.
This is affecting node and taxonomy term references as well as block references -- anywhere the IEF complex widget is used with multiple cardinality, if eca_form module is enabled. Doesn't matter if there's an ECA model using it.
Turns out it's a known issue of ECA - 🐛 ECA Form breaks complex IEF widget Active . Leaving this open in case the fix is better handled here in IEF.
Oh interesting, we're using ECA on the affected sites -- we're hitting this issue on at least 4 different sites, and ECA is active on all of them.
Commented in Slack #ECA channel with a link to an old blog post where I created a custom price resolver.
So what I'm wondering now is if it's possible to alter a price resolver's priority -- or have a price resolver derivative that allows a price resolver instance (or multiple instances) to get created with a specified priority. Wondering if this might be possible with a Symfony Decorator, if there's not a more Drupal-specific way?
As discussed in #ECA slack, I think we could implement a PriceResolver service with a high priority, that would return the desired price. This could then be set through an ECA plugin.
@ankondrat4 sorry to miss this, our client that we built this for hasn't been all that active. I'm not sure I'll be in here much, so I've added you with some basic roles -- if you're active on this, I can increase those, reach out to me on Slack!
Committed, thanks!
Fixed. Thanks for the contribution!
Fixed.
freelock → created an issue.
It's not the first time I've hit circular stuff with commerce -- all the way back to Ubercart, seems like commerce events fire a lot more often than I would think necessary. My answer is idempotence -- make sure if it's called multiple times, the result is always the same.
This is why there's a quantity field in the plugin -- each time the plugin runs, if the item is already in the cart, it updates the quantity to whatever value is in that field (which accepts a token), so you if you create a token for quantity based on other products in the cart, it can always do the right thing -- set the correct quantity on one order item.
If the "right thing" is to add additional order items with the same sku, this plugin won't do that. It won't even detect if there is more than one order item on the order -- it just sets the quantity on the first matching one it finds (but you can specify elsewhere that multiple order items with the same sku should always be combined).
@nicxvan what circular logic do you see?
freelock → created an issue.
Merged -- not fully tested, so making an Alpha release. Any issues found should be created as new issues!
Hi,
This action requires either a sku or a purchasable entity (product variation) to add, and an order (which is what a cart is under the hood). So you do need to load an existing order/cart to pass it in.
I used this event: https://ecaguide.org/plugins/eca/commerce/events/eca_commerce_cart_entit... which provided a cart (order) and a product variation entity. I could then check details for the product, and if it matched, add a different product to the cart by sku.
It does require the commerce cart and commerce order modules to be active, and the order -- so you need to get that somehow. Loading it by entity type/id should be fine -- is the one you're loading owned by the user who's executing your model? You often need to switch users if you're trying to run from drush or cron...
Cheers,
John
Hi,
The best way to send an Easy Email programmatically is to use ECA → . Both Easy Email and ECA are in Drupal CMS, so this is getting a lot more widespread use.
On the linked issue in #7, I had started a "Scheduled Message" module to do this, but we've switched over entirely to ECA.
Three of my recent Advent Calendar posts include this:
https://www.freelock.com/advent/2024/remind-customers-abandoned-carts
https://www.freelock.com/advent/2024/automatically-track-documentation-r...
https://www.freelock.com/advent/2024/send-roster-event-attendees-staff
... the gist is, create a view that collects the people you want to email. In ECA, you use a Views Query to get all of them, and send that list to a custom event (entity aware), which ECA will then call for each person on the list. From that event create a new entity of type easy_email, and the email template you want to send. You can then associate entity reference fields to your email with the views result, and use tokens in your template as appropriate.
Yes, it's working for us...
Added new action plugin.
Note that during testing, the "Add entity to cart" event got executed multiple times (twice) -- so in my initial cut, it was adding the extra product twice.
To avoid this, I made it check the existing cart for a matching order item, and if found, it sets the quantity of that item instead of adding a new one.
This works fine for my needs. I'm not sure if there is a good way to avoid this problem otherwise.
freelock → created an issue.
Similar question on the ECA queue - 💬 A honest comparison / contrast of ECA vs Rules? Active .
I Just turned most of my response into a blog post, here: https://www.freelock.com/blog/john-locke/2025-01/ask-freelock-eca-vs-rules ... would love any comments people have on that, especially from people who have used Rules recently.
Comments there are now auto-moderated by AI -- if you leave a relevant comment, it should get automatically published within 5 minutes!
@w01f I wonder if you could get a reasonable starting place on a comparison table by asking Claude or something for one...
Just turned most of my response into a blog post, here: https://www.freelock.com/blog/john-locke/2025-01/ask-freelock-eca-vs-rules ... would love any comments people have on that, especially from people who have used Rules recently.
Comments there are now auto-moderated by AI -- if you leave a relevant comment, it should get automatically published within 5 minutes!
Hi,
Not sure there's a good person to comment on this -- I just became aware that Rules had a stable release earlier today, answering a client question. I used Rules extensively in Drupal 7, but found it too buggy and cumbersome to use broadly ever since Drupal 8 -- one of the key bugs we hit is still not fixed, after I created a patch for it 8 years ago: https://www.drupal.org/project/rules/issues/2816033 🐛 Rules registers no listeners on rare occasions. Needs review
... that said it looks like there's a decent amount of activity on Rules in the past 6 months, after very, very little for most of the past 8 years.
I started using ECA a little over 2 years ago, and I have not found anything I could do in Rules that ECA doesn't do, and it usually does it better. ECA has the advantage of starting in the Drupal 9 architecture -- Rules seems to still have a legacy architecture that requires info hooks to register plugins, and a lot of refactoring to do to be as streamlined, effective, and powerful as ECA.
This means ECA plugins are really simple to create. ECA also supports just about every event Drupal dispatches, and supports core action plugins as well as ECA action plugins -- this means there's a lot of existing code that "just works" with ECA even though they were built with other systems in mind. That means you can do more with ECA!
Aside from code, I see one significant architectural decision that seems different: Rules seems tightly integrated with Typed Data, whereas ECA is tightly integrated with Token. I see on the Rules page that they changed their tokens from Token module syntax to Twig syntax, calling out that this allows them to leverage the TypedData system to support any data property on the various objects involved, as long as the TypedData is set up correctly -- and point out that Token is generally limited to strings.
ECA on the other hand has expanded its use of tokens to include objects and lists, as well as wrapping them in "DTO" - Data Transfer Objects. So this basically means the two systems have made a very different decision on how to solve the same problem -- passing structured data around. Both of these seem legitimate to me -- the typed data approach might lead to better (or at least easier) validation of data objects, but less flexibility. So that means it might be easier to find the data elements you need when working with Rules, compared to ECA where you're using the Token Browser which doesn't always show exactly the token you need.
That said, I think there's a lot more support for tokens than TypedData, so that's another area where ECA might have the edge in terms of pure breadth of available "stuff" you can do with it, while possibly being harder to discover exactly how to hook it all up.
The other differences that come to mind, take my feedback with a grain of salt -- we've been all in on ECA for over 2 years, and I have not looked at Rules since we switched over -- but here are my informed opinion of ECA vs uninformed opinion of Rules:
- Lists -- ECA has a "list" token built in that allows loops, entire subroutines acting on each item of a list (or row of a view). Loops in Rules are cumbersome and confusing -- and "Rules Components" which allow you to do subroutines are on entirely different admin pages
- BPMN -- I would not minimize how powerful it is to be able to visualize the flow of events, particularly when talking with stakeholders and less involved people.
- Documentation -- there's still a lot of room for improvement here, a lot of stuff that's missing -- but Jurgen has done a fantastic job of setting up a documentation site, making it so all actions/events/conditions link to a doc page that lists tokens, etc. and is full of examples. He also did a series of videos that walk through a lot of different scenarios. But it's not just documentation of ECA -- in the BPMN modeler, it's easy for you to document your models. This is huge, particularly when you come back years later to change some functionality. There's a documentation field in each action, flow, and event where you can put notes, and you can attach freeform notes anywhere you want in the model. The Rules documentation seems woefully out of date -- but on the other hand when I last looked at it it was quite similar to Rules in Drupal 7, so maybe there's some old docs that still apply?
- Performance - original versions of ECA might've carried a small performance penalty because it had code called for every event in the system which had to then check if there was any ECA model to execute. That's why there are so many submodules so you could turn off swaths of functionality. Now that's no longer the case -- ECA manages its event handlers so they are only run if the event exists in a model. I haven't seen any benchmarks of either ECA or Rules, and I don't know what sort of performance impact Rules 4.x has.
Regarding stability, the move from 1.x to 2.x was a bit rocky -- a bunch of our models broke, silently. 2.x does have a lot better validation, and the event performance improvements which I think were really the cause of the breakage -- in 2.x the event registration is centralized and standardized, which meant a lot of the tokens that were defined in the original event plugins now need to be properly declared. These were easy to fix, but caught us by surprise. On the other hand, I'm seeing lots of issues in Rules that still seem to block a bunch of scenarios, and it wasn't marked stable for nearly a decade -- is it really stable, or just enough pressure to declare it so that it (finally) starts getting security team coverage and enterprise adoption (which is not meant as a slam, that seems totally legitimate to me). I think ECA has had so much more attention and excitement from the active Drupal community than Rules in the past couple years.
So all in all, I think ECA wins in just about every category - the one thing Rules has that ECA doesn't is that tight integration with Typed Data.
I'm quite curious to hear what others have to say...
Proposed fix in MR.
We hit an issue where we had multiple events that use the "Determining Entity Access" plugin, and hit this issue. After reviewing, I think the solution proposed by @ergonlogic is incorrect -- I do think the result should get initialized with AccessResult::neutral(). However, if there is more than one of these events in your site, the last one wins because of this reset.
In our case two access checks applied to a particular action:
node:application, update
node:*, view,update
The first was setting an AccessResult::allowed, the second AccessResult::neutral. After processing the ECA event, AccessResult::neutral was the final result, and access ended up being denied.
I think the correct solution is to make use of AccessResult::orIf(). In the event plugin, setAccessResult() method, I think it should see if it already has an access result set, and if it does, replace it with $this->accessResult->orIf($result).
This allows all the access rules to get checked, and reasons are available for all of the models.
The logic for the orIf() call is to return AccessResult::forbidden if either the existing or new accessresult is forbidden; return AccessResult::allowed if either the existing or new result is allowed, and return AccessResult::neutral if both are neutral.
The previous solution is still subject to the "last check wins" if multiple checks return something other than neutral.
freelock → created an issue.
I think Key module is the appropriate place for it. It is a plugin, so it can live really in any module -- was putting this out as a feeler for whether you'd accept it here.
Will work on this when I get a chance...
Finally got a chance to test this, and spent hours trying to figure out why it didn't work.
I'm not exactly sure why, but the "data_yaml" config form setting is not saving correctly on my instance. It always comes up blank, and if I set it to "yes" it remains 0 in the underlying config.
I'm trying to track this down, because I don't see any obvious issues -- the form element is set to be a checklist but it's rendering as a select with yes/no values, so I think something is overriding the form rendering for this element for some reason. Will file an issue when I know what it is...
@dbdrupal that seems like a good new issue to create -- make the ckeditor dependency optional, so you can still use the views functionality?
Merged.
freelock → made their first commit to this issue’s fork.
Merged.
Merged into 2.0.5.
Thanks for the report!
freelock → changed the visibility of the branch 1.0.x to hidden.
freelock → made their first commit to this issue’s fork.
freelock → created an issue.
Fixed.
freelock → created an issue.
Options doesn't work for files, at least not binary ones.
If there's unrecognizable characters, the Yaml parser throws an exception, and you're done.
Guzzle takes one of:
- A file pointer (created by fopen)
- A stream wrapper
- The raw file contents
I don't see any way of getting the first 2 into a token, and the third chokes the Yaml parser.
Ok, I'm not exactly sure how I messed up the MR, but you can at least see the direction I'm going. With this, I'm setting the data value to:
file: "[entity:field_door_image:entity:path]"
description: "[entity:field_door_image:alt]"
and it's successfully posting an image.
For more, see the post that's automatically publishing in a few hours: https://www.freelock.com/advent/2024/automatically-post-mastodon-or-othe...
freelock → created an issue.
All that needs to happen for this is creating some plugins -- and probably not many.
Event plugin -- Webhook received
Action plugin -- Send webhook
... since Webhooks are entities, much of the normal entity ECA plugins should already work. Are there any other plugins we need?
New action plugin -- this is working on a site in a custom module -- only difference is updating the namespace to eca_cache and updating the plugin id.
I'm a bit rushed at the moment, but I created an action module for a client to get this done:
namespace Drupal\eca_cache\Plugin\Action;
use Drupal\Core\Access\AccessResultInterface;
use Drupal\Core\PageCache\ResponsePolicy\KillSwitch;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Drupal\Core\Session\AccountInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Drupal\eca\Plugin\Action\ConfigurableActionBase;
/**
* Provides a Page Cache Kill Switch action.
*
* @Action(
* id = "page_cache_kill_switch",
* label = @Translation("Page Cache Kill Switch"),
* description = @Translation("Kill the page cache for this page")
* )
*/
final class PageCacheKillSwitch extends ConfigurableActionBase {
/**
* {@inheritdoc}
*/
public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition): static {
$self = parent::create(
$container,
$configuration,
$plugin_id,
$plugin_definition
);
$self->KillSwitch = $container->get('page_cache_kill_switch');
return $self;
}
/**
* {@inheritdoc}
*/
public function execute(): void {
$this->KillSwitch->trigger();
}
}
freelock → created an issue.
Unfortunately the code in the MR is not working for me...
Regarding 4th level menu items, if you add them as a 4th level do they just not show up? If so, seems like that would be the right solution -- they are there when the upstream adds that functionality...
Cheers,
John
freelock → created an issue.
Hey I upgraded a ckeditor module that had a dialog in it, it's a bit of setup to do but not too hard. I have other priorities and don't have a client to fund this (yet) but I'd be willing to work on this in the next month or two...
+1 to this -- our media image bundle has a field for "source" meant to be a link to the image source, and copyright notice. I think this should be part of any media automation.
This automator is really cool! But I have no idea who shot the specific images it selects...
freelock → created an issue.
+1 on this -- please make the 2.x version have a bigger number than the downgraded 3.x version!
Ok this just bit me again... the fix does not fix my installation, at least not under PHP 8.1. The DependencySerializationTrait does not appear to be adding the Time service to the _serviceIds[] property of the serialized object, so it does not add it back to the rehydrated Task object.
This has led to thousands of unprocessed queue items...
Can we re-open this issue? The original MR did fix it on my installation -- reapplying that as a patch is fixing it for me. DependencySerializationTrait did not fix it. A simple __unserialize() or __wakeup() method that adds this back might also work -- although it loses any benefit of dependency injection (if a different class was injected in the first place).
freelock → created an issue.
@phenaproxima (#4) ECA is very easy to add support for, just need to implement plugins as desired.
For events, the easiest thing to do is just use the normal event system, and then an ECA event plugin can subscribe to that.
If everything is in config entities, there may not be anything special needed to work with ECA -- ECA has plugins for entity events, fields, etc.
For this proposal, are you thinking the entire checklist and its state is stored as a config entity? And it contains a list of "task" datatype? Or is there a separate place -- e.g. field data on a field attached to some content entity for the checklist state?
I like that second architecture -- I would like to have a "template" checklist that can be reused a bunch of times. However, I do want to be able to customize the checklist each time it is used. I'm thinking the ideal model for what I'm going for might look something like this:
1. Config entity for the base checklist, containing a set of default tasks
2. Field attached to an entity, which has a "checklist override", and "checklist state"
... the checklist override could suppress specific tasks on the checklist, and add additional as appropriate.
The checklist state would track each task's status -- checked or not, user who checked it, time it was checked, notes, link.
A task (without its state) should also have - label, help text, optional link to instructions.
Is that inline with what's being planned here?
Cheers,
John
I'm extremely interested in this. We have a custom "checklist field" I've been using for a while, which is currently a front end built in Vue.js that allows nestable checklist items, each item with the ability to have a note completed by the person using it, a link that may point to a reference page for more info about the task, the checklist state, as well as the "result" - (completed, not completed, not applicable), and the user who checked the box and the time it was checked.
Right now we load the entire thing in a custom field type, which has a single database column -- this serializes the entire checklist as Yaml, which the field formatter loads into the Vue widget, and then uses JSONAPI to update (right now with a save button that re-serializes the entire list and posts it back to the entity). The field widget is just a text area so we can copy/paste entire lists from one instance to another.
We use this for a QA checklist when reviewing new sites, as well as a launch checklist. I also have it on a personal site where I use it for a camping checklist.
The "edit checklist" functionality right now is just edit raw Yaml -- our current UI is ok for actually running down a checklist, taking notes as you go, and outputting a report...
Just providing some ideas of extra requirements to consider for the data model...
This would be huge -- and I see it as the single biggest advantage of Gutenberg over other Drupal solutions...
freelock → created an issue.
Yikes, this is extremely confusing -- is the 2.x branch going to get deprecated? That's certainly the impression from the project page... is there an upgrade path from 2 to 3? Should anybody upgrade from 2 to 3?
I think the smarts incorporated in 2 are a big improvement over 1 -- if 3 is just about adding Drupal core compatibility I wonder why it didn't stay on the 1.x branch?
Almost seems like there should be two different modules.
Ok addressed the issues with the test failures.
Regarding removing from the buildEventData, seems like we should do that -- I was wondering if the annotations in the PHP attributes should be copied up to the getData ones? Specifically it has classes, and properties on the flaggings annotation -- are these correct, things we should add?