Warning: Array to string conversion in Drupal\eca_modeller_bpmn\ModellerBpmnBase->optionsField()

There must be a plugin from a third-party module that has a configuration form with some unsupported components in it. This certainly not a bug in ECA. Can you please debug this further on your site to find out which plugin is causing this?

Ok, will do so. I will get back here with more info.

thanks.

This error has been present since the Tamper module update.

https://www.drupal.org/project/tamper/releases/8.x-1.0-beta1 →

@tetatu thanks for the hint. That's brand new then. Just checked, and they have a new plugin to find entities.

That has $entity_types[$entity_type->getProvider()][$machine_name] = $entity_type->getLabel(); in line 386 of \Drupal\tamper\Plugin\Tamper\EntityFinder::getEntityTypes. That label turns out to be a renderable array. They should turn that into a string, since this is used as an option in a select field. Would anyone mind reporting that in the tamper module? I'm away from the desk today.

In my case, the $entity_type->getLabel() does return a string.

Maybe there something else on the structure. I will take a look on Monday.

I uninstalled ECA and all its dependencies, because Composer wouldn't let me uninstall the new version of Tamper. Then I managed to uninstall it. Then I reinstalled ECA, then the previous version of Tamper, but even though I specify the exact previous version

composer require 'drupal/tamper:^1.0@alpha'

Composer installs the latest one, so I can't 100% verify that this module is causing the problem.

I think the problem is near,. because if I invalidate the getLabel with a forced PHP error, por exemple using implode(), then the warnings go away.

To get more deep on this, I will join my colleague on Monday to trace the code and be sure about it.

https://www.drupal.org/project/tamper/issues/3509682 🐛 Array to string Active

I think you should improve that issue and try to explain a little more why you think an ECA error message is related to tamper :)

The plugin I mentioned in #5 has a list of entity types in a select field and the values in the options come across as arrays. If you remove that plugin, flush the cache and retry, the problem is gone.

Can it be that there exists a content entity type here that violates \Drupal\Core\Entity\EntityInterface contract? Allowed return types for \Drupal\Core\Entity\EntityInterface::label() are string, \Drupal\Core\StringTranslation\TranslatableMarkup or null.

With the entity types I tested, all labels are instances of \Drupal\Core\StringTranslation\TranslatableMarkup.

It is the case that \Drupal\tamper\Plugin\Tamper\EntityFinder::getEntityTypes() returns a multidimensional array, but this is intentional. The list of content entity types are grouped by provider:
$entity_types[$entity_type->getProvider()][$machine_name] = $entity_type->getLabel();

This makes it easier to find the content entity type that you want to use:

Thank you @megachriz, that's exactly what's happening. As the JavaScript-based property panel in BPMN doesn't know anything about the Drupal Form API, we need to recognize this special case and convert that nested array into something that a simple html select understands. Will provide an MR for.

Awesome. I'm ready to test that MR when it's available .

Here you go.

The warnings are gone after applying the MR to the latest dev release 2.1.x-dev.

There are no more PHP warnings when editing ECA model, and the select box with Entities still show the flat list with all of them.

Thanks!

Merged and back ported to 2.0.x

I'm using ECA version 2.1.5, will this fix be included in the next update? I see there's also a version 2.0.14, what's the purpose of that?

will this fix be included in the next update

Yes.

I see there's also a version 2.0.14, what's the purpose of that?

That's the previous minor version of ECA. Almost 3000 installations are still using it, so we need to maintain that as well. BTW, there is also a 1.1.10, which is also still used by some sites.

This is unnecessary extra work for you developers. The 2.0.14 runs on the same ^10.3 || ^11 system as the latest one, so anyone who used that could upgrade to the latest one.

Welcome to the world of inertia. If you know a way to solve that issue, IT in general will be your fan.