Cloning a GLPI form with a PluginFieldsQuestionType double-encodes default_value and breaks the cloned form editor

[clintswartzlander]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

GLPI Version

11.08

Plugin version

1.24.2

Bug description

Environment

• GLPI: 11.0.8
• Fields plugin: 1.24.2
• Item type: Ticket
• Forms: native GLPI Forms

Summary

Cloning a GLPI form that contains a Fields plugin question (PluginFieldsQuestionType) creates a broken clone. The cloned form cannot be opened in the form editor and displays:

An unexpected error occurred

Cloning a form containing only native GLPI question types works correctly.

The issue is reproducible with a brand-new form and a single Fields question, so it does not depend on legacy forms or previously corrupted container data.





### Relevant log output

```shell

Page URL

No response

Steps To reproduce

Steps to reproduce
Create a new GLPI form.
Add one normal question, such as Title.
Save the form.
Clone the form.
Open the clone and confirm it works correctly.
Return to the original form.
Add a question of type PluginFieldsQuestionType, for example a dropdown from an Additional Fields block.
Save the form.
Clone the form again.
Open the new clone.
Actual behavior

The cloned form editor displays:

An unexpected error occurred

PHP logs show:

Twig\Error\RuntimeError: An exception has been thrown during the rendering of a template
("array_merge() does not accept unknown named parameters")
in "@fields/question_type_administration.html.twig" at line 43.

The backtrace reaches:

marketplace/fields/inc/field.class.php:1292
PluginFieldsField::prepareHtmlFields()

marketplace/fields/inc/questiontype.class.php:138
PluginFieldsQuestionType->renderAdministrationTemplate()

The logged exception and call path show the failure occurs while the Fields question is rendered in the cloned form editor.

Database evidence

The original Fields question stores default_value as valid JSON:

{"items_id":[]}

The cloned question stores the same value double-encoded as a JSON string:

"{"items_id":[]}"

Example:

Original question:
default_value = {"items_id":[]}

Cloned question:
default_value = "{"items_id":[]}"

The extra_data remains valid in both records, for example:

{"block_id":"4","field_id":"8"}

This indicates that the cloning process serializes or encodes default_value a second time specifically for PluginFieldsQuestionType questions.

Expected behavior

Cloning a form containing a Fields question should preserve the question configuration without changing the data type or encoding of default_value.

The cloned form should open normally in the form editor and remain editable.

Your GLPI setup information

No response

Anything else?

Additional notes
This occurs on a completely new form created from scratch.
It occurs consistently whenever the form contains a PluginFieldsQuestionType question.
A form with only native GLPI questions clones successfully.
The original form remains functional; only the clone is broken.
Manually converting the cloned default_value from a JSON string back to the original JSON object format repairs the existing clone, but future clones reproduce the problem.
The failure occurs in PluginFieldsField::prepareHtmlFields() at field.class.php:1292, where the malformed value ultimately causes array_merge() to fail.
Suspected cause

The GLPI Forms cloning path appears to double-encode the default_value for PluginFieldsQuestionType.

The Fields administration template later passes the malformed value into PluginFieldsField::prepareHtmlFields(), where it eventually causes:

array_merge() does not accept unknown named parameters

A regression test could:

Create a form with one PluginFieldsQuestionType.
Clone the form.
Assert that the cloned question’s default_value has the same JSON structure as the original.
Open/render the cloned form editor successfully.