I'm testing the "Antispam by CleanTalk" plugin on Joomla 4.
I've just found out that when the plugin is installed, you try to configure it, and it has a usergroup field (multiple=true) in the plugin configuration; Joomla 4 throws this error:
TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given
layouts/joomla/form/field/text.php, line 99
So, it looks like the user groups (array(2)) are not correctly processed by the field definition:
<field name="roles_exclusions" type="usergroup" multiple="true" label="PLG_SYSTEM_CLEANTALKANTISPAM_EXCLUSIONS_ROLES" description="PLG_SYSTEM_CLEANTALKANTISPAM_EXCLUSIONS_ROLES_DESC" />
No errors when we try to configure an unpublished plugin.
TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given
layouts/joomla/form/field/text.php, line 99
Joomla 4 Beta 7 and a plugin manifest with a usergroup field with multiple=true.
usergroup field with multiple=fals works fine.
It looks like Joomla accepted the field type and continued processing it until it broke processing the multiple attribute.
Yes, when that field type is not found, Joomla uses text field type as I mentioned. However, in this case, I think it is better use the right field type instead.
I still think that the developer of Antispam by CleanTalk plugin will have to fix the typo/bug in their plugin code instead of we have to add code to handle every possible cases (especially when the case causes by error/bug from extension developer)
I agree with @joomdonation, it a bug in the plugin. They should use correct field type.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-02-07 10:10:49 |
Closed_By | ⇒ | anibalsanchez |
On Joomla 3, the plugin works fine.
I've just checked that the Usergroup field has been deprecated. https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4
So, yes, it is part of what the developer has to update for Joomla 4.
Closing the report.
Shouldn't type="usergroup" changed to type="usergrouplist" ? We do not have usergroup field type, so it default to text and it causes that error. Change type to usergrouplist should address the issue, so look like a problem with the plugin itself to me.