I have tested this item ✅ successfully on a22f55b

works for me!

I have tested this item ✅ successfully on a22f55b

RTC

Not sure if this is the right solution...

I merge this even if I'm not 100% confident with this solution. thanks

maybe the alternative is to check if the legacytrait is implemented.

Maybe we can implement Iterator intrface over base Table class?

hmm that's maybe an idea too

then it also will be possible to do $array = iterator_to_array($table) https://www.php.net/manual/en/function.iterator-to-array

@Fedik
The same problem also arose.
but this fix didn't help.
Error in the Form class in the findField() method.
There is code in this method
$fields = $this->xml->xpath('//field[@name="' . $name . '" and not(ancestor::field/form/*)]');
which causes the error specified in the subject of this PR.
The error pops up because $name contains the value *_errors
I spent half a day looking for where this value falls out in $name. Found.
I had this happen when saving an article in one of the plugins.
Using the Content model.
Of the ArticleModel class in the loadFormData() method, the method is called
$this->preprocessData('com_content.article', $data); from trait FormBehaviorTrait
Method preprocessData($context, &$data, $group = 'content')' in 'trait FormBehaviorTrait contains the code

Factory::getApplication()->triggerEvent('onContentPrepareData', [$context, &$data]);

So in my case, initially $data had the object type, but after calling the trigger, the type became array.
One of the plugins converted the type from an object to an array and returned a link.
There should be no problems, because in the Form class, the bindLevel method takes into account that the binding occurs of an array or object.
But the fact is that the object had hidden properties.
In the case when the plugin has applied a function to the object

settype($data, 'array');

the hidden error field has turned into *_errors
and at the time of binding, this field causes an error when calling the function
$this->xml->xpath(); in the name of $name when it contains *_errors
I suggest in the Form->bindLevel($group, $data) method
, where the foreach($data as $k => $v)
iteration occurs, to check for the presence of an asterisk

then ignore the binding for the field with an asterisk

In the case when the plugin has applied a function to the object settype($data, 'array');

That is illegal, and it will not work in the future.

I agree with You that this is illegal.
And I hope in the future Joomla will tell us which plugin changes the object to an array or vice versa, thanks to the type check. But you must agree that it is difficult to intercept an error when the type changes somewhere in the plugin, and the error climbs into another from the opposite part of joomla.
But there is also another problem, the FORM class allows it to be bound as an array and as an object. Both methods are acceptable. But let's assess the situation, should the binding of the form give an error due to the fact that the name begins with an asterisk? or should such a name just be skipped?
After all, the binding code should just look for fields of the same name, if the field name does not match, then it does not match anyway. This may be intended by the algorithm of a plugin or component, it should not cause an error.
The problem appeared to me as a result of creating a module for saving articles, i.e. this error was not in the module that I was making, but in the plugin.
Maybe we need to wrap additional quotes around the name here?

$el->xpath('descendant::field[@name="' . $name . '" and not(ancestor::field/form/*)]')

Another question for you, Is the data transferred to the CONTENT plugin only in the form of an object? or can they be passed as an array?

But you must agree that it is difficult to intercept an error when the type changes somewhere in the plugin

Should write to developer of the plugin, that it is a bug in their plugin.

or can they be passed as an array?

Currently can be both, depend from Model and Request. But it should not be changed at the middle of runtime.

Should write to developer of the plugin, that it is a bug in their plugin.

And how do you recommend to access the data?
After all, the data can be either an object or an array.
And if you refer to the value of the array as the value of the object, there will be an error. That's why I understand the plugin developer. that he made the type conversion to an array so that there would be no problems that he was accessing the value in the wrong format.

Whe you realy need, you can do:

$myData = (array) $data;

But do not:

$data = (array) $data;

When you realy need, you can do:

$myData = (array) $data;

But do not:

$data = (array) $data;

But if you need to change the article data inside the plugin. Then we have to use 2 ways. 1.Modify as an object, and 2.Modify as an array. And before that, check the type.