suport for @custom_field

I just found out that there is similar issue for "Entity:GET Value" which triggers :

event Drupal\eca_content\Event\ContentEntityUpdate: Property value is unknown..

so it seems also standard ECA module needs to handle this first...

It looks like neither eca_tamper nor eca can do much about it here, this seems to be an issue with the custom_field module.

The code, that being executed here is this:

      if ($data instanceof ListInterface) {
        $item_definition = $data->getItemDefinition();
        $main_property = $item_definition instanceof ComplexDataDefinitionInterface ? $item_definition->getMainPropertyName() : NULL;
        $data = $data->getValue() ?? [];
        array_walk($data, static function (&$item) use ($main_property) {
          if (isset($main_property) && is_array($item)) {
            $item = $item[$main_property];
          }
          elseif (is_scalar($item)) {
            // Nothing to do.
          }
          else {
            $item = NULL;
          }
        });
        $data = array_filter($data, static function ($item) {
          return NULL !== $item;
        });
      }

That means, $data is the custom_field object and we use a Drupal core interface to getMainPropertyName(), which gives us back the property name of the main property. I.e. that comes from the custom_field. Then we grab $item[$main_property] and receive the error that this doesn't exist. In other words, the property, that we were told to be the main property name, isn't defined? That must mean, that the field definition has given us the wrong information.

If I'm not completely wrong, I'd pass that over to the custom_field module.

There is no main property name with custom_field. It's not technically possible as the properties are dynamic so theres no way to know which property would be considered the "main one". If the ECA module is depending on that... I'd have to say its not gonna be compatible with custom_field and nothing I can really do about it from my end. jurgenhaas also uses the custom_field module so I'd suggest bouncing it back to him to see if there is anything differently that can be done for ECA.

Thank you guys. Maybe one day:)

@apmsooner just one little thing to consider, whether you want to re-open the issue for that is totally up to you:

The field item from custom field is an instance of ComplexDataDefinitionInterface which implements the method getMainPropertyName() that should either return the name of the main property, if one exists, or NULL if it doesn't. As custom_field doesn't have one, it should return NULL, but it returns value. Unfortunately, I don't know what's required to make that change, but I think custom_field would be more compliant with that interface if you got that changed (fixed).

Thanks for diligently pointing this out. I could have sworn i already had mainPropertyName() set in the field type but sure enough I'm not seeing it for some reason. Opening this back up and I'll provide a patch that can be tested.

Here's a patch that can be tested.

@apmsooner, thank you so much for your effort. Much appreciated!
It looks good, I don't see any error in logs, however looks like nothing is passing so it seems @jurgenhaas has to review also.

@jurgenhaas I have tried simple model with standard entity reference field to User using this manual : Eca manual and i was able to see if user was added + his name or if user was removed so this worked fine.
However when I changed all parameters to custom field with name "field_resource" (entity reference to user called "name" + one text field called "role" as described on picture above) the first problem is that new_list and origin_list are blank and new_user and original_user is []. When I changed parameter from field_resource to field_resource:name the list value now looks "better" and shows ID of all assigned users, however new_user and original_user are still [].

Another issue is when it passed through Trigger (custom event entity aware) and loaded - it always loads Node id ,instead of user id.

So not sure if anything else has to be updated in custom field or I am missing anything.

@jurgenhaas Can you be so kind and test some simple model to determine the issue ?

Thank you

@jurgenhaas - I suspect there would need to be specific plugin integration to make custom_field work with eca module. The custom_field module field types consist of its own plugin system so ECA wouldn't know (i assume) how to interact with for instance a custom_field entity reference field without accessing the the custom_field plugin for that column type. The column settings "type" value map up to the same named plugin ids: https://git.drupalcode.org/project/custom_field/-/tree/3.0.x/src/Plugin/....

Theres a helper function here that would return an instance of the custom_field type plugins based on field definition settings passed into it that may be helpful: https://git.drupalcode.org/project/custom_field/-/blob/3.0.x/src/Plugin/...

I have no knowledge of ECA unfortunately but if theres enough interest in making it work with custom_field, I'm open to helping out where I can. I suspect that further effort would live as a feature request in the ECA module at this point unless you have any insight of additional changes needed in custom_field module. I'll wait on additional feedback before I merge this patch in.

This should be fine, thanks a lot @apmsooner for addressing this!

@coaston when data doesn't have a main property, ECA calls $data->getValue() to receive the data from the object, and that should subsequently being processed without any issue. If you're not receiving data as expected, then it's time for the ECA debugging techniques described at Debugging. That gives you an insight to the available tokens and their data at any single point during ECA processing. If you're still seeing issues with this, that would probably be better addressed in a separate issue in the ECA issue queue, since the original problem for custom_field seems to be resolved and we don't want to create noise in a "foreign" issue queue.

I wonder whether this issue is also related (in particular to comment #13 💬 suport for @custom_field Active ), sorry if posting to the wrong place.

While I can get Custom field values populated via ECA (see here 💬 Handling Multi-Value Nested Fields Closed: works as designed , a really nice combination with many use cases), it seems that the ECA condition "Entity: Field value has changed" is always evaluated to true, even if the value of the subfields of the Custom field didn't change. Is that also because of the lack of a "main" property value that is missing?

With respect to #12 💬 suport for @custom_field Active , an ECA_custom_field module would be really great as the number of users of both ECA and Custom field is expected to increase even further.

I'm honestly not sure how the field value "has changed" logic is factored. I don't know of anything in the field api that determines that so assume perhaps theres something in ECA that is doing that evaluation. As for your sidenote in that comment, that shouldn't be the case in having to have a unique value. There's no conditions in the custom field module that require uniqueness. You could set multiple values with all the exact same values so not sure why that would be a problem in ECA rule. I really still unfortunately don't have experience with ECA though either. I guess I'd have to get a visual also of the use case for populating a custom field from tokens.

I'd say, the comment in #17 should be a new issue and provide steps to reproduce the problem. Ideally with a simple ECA model to show the problem. We can then look into it. Commenting on a closed issue isn't really what moves the analysis forwards.

Okay, I think I got it. The key is to test whether the value of a subfield of the custom field has changed, not the custom field itself. So you have to iterate through all subfields of a custom field if you would like to grab any changes. See .

I consider this issue closed, and excuses again for opening a closed topic.