Problem/Motivation

I got warning on node form where I use field groups in paragraphs.

Warning: Parameter 1 to Drupal\field_group\FormatterHelper::formProcess() expected to be a reference, value given in Drupal\Core\Render\Renderer->doTrustedCallback() (line 101 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php).

Steps to reproduce

1. Create paragraph type
2. Create some fields and add some field groups on manage form display
3. Create content type and add paragraph field
4. Open node add page
5. Warning will be displayed

Proposed resolution

As in Drupal Core all render callbacks have value arguments (not reference) we should remove '&' symbol from public static function formProcess(array &$element, FormStateInterface $form_state = NULL, array &$form = []);

Comments

Romixua created an issue. See original summary.

Andrii Kleba’s picture

I have the same problem.

 
Warning: Parameter 1 to Drupal\field_group\FormatterHelper::formProcess() expected to be a reference, value given in Drupal\Core\Render\Renderer->doTrustedCallback() (line 101 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php).
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 781)

This path fixed it.

swentel’s picture

Status: Active » Needs review

Triggering tests

mrweiner’s picture

This isn't really a duplicate of #3147495: Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface, although the patch is needed for other developers to properly address the error noted in that issue.

mrweiner’s picture

Status: Needs review » Reviewed & tested by the community

Updating status. This fixes the problem for me.

frankdesign’s picture

Patch at #2 solved the issue for me. Thanks

nils.destoop’s picture

I agree with the patch. But if you look at Drupal core, all process functions are receiving it by reference. I don't know the reason, as you are expected to return the element.

If you look in formBuilder, you'll see that it's called by reference. I think cause of this warning is idd triggered by #3147495, as that one is the paragraph implementation instead of the processing handling in drupal core form builder.

damienmckenna’s picture

Title: formProcess function should expect value bun not reference » formProcess function should expect value, not reference

Clarifying the title; no bunnies were harmed ;-)

dxvargas’s picture

I've updated the patch since it was failing to apply to current dev version (8.x-3.x).

dxvargas’s picture

Status: Reviewed & tested by the community » Needs work

Tests are failing just like they are failing in https://www.drupal.org/project/field_group/issues/2894351#comment-14394498.
The changes I've made are minimal, the tests are failing because of external problems. I hope the issue can go back to RTBC soon!

I put the issue in "Needs Review", please check!

dxvargas’s picture

Status: Needs work » Needs review
donquixote’s picture

Why is this used as a '#pre_render' callback?
It is only meant to be used as form '#process'.
Could there be a 3rd party module that uses the callback with '#pre_render'?

mrweiner’s picture

Status: Needs review » Reviewed & tested by the community

#10/#11 looks good to me.

@donquixote see https://www.drupal.org/project/field_group/issues/3147495#comment-14214001 for the #pre_render stuff. third-party modules need to update their implementations if they are seeing the noted error.

berdir’s picture

On the preprocess/pre_render discussion, this was changed in field_group at some point as a new function that replaced the previous pre_render. See this commit in paragraphs:

commit c8387b322e780dcb53d04b548e59244af4656b6c
Author: mpp <mpp@359881.no-reply.drupal.org>
Date:   Mon Aug 5 21:28:52 2019 +0200

    Issue #2907094 by mpp, bserem, andybroomfield, zuuperman, weseze, jwilson3, Berdir: Make paragraphs module working with field_group version 3.x with support for the field_layout module

diff --git a/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
index 785bdfe..7812796 100644
--- a/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
+++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
@@ -643,7 +643,12 @@ class InlineParagraphsWidget extends WidgetBase {
         ];

         field_group_attach_groups($element['subform'], $context);
-        $element['subform']['#pre_render'][] = 'field_group_form_pre_render';
+        if (function_exists('field_group_form_pre_render')) {
+          $element['subform']['#pre_render'][] = 'field_group_form_pre_render';
+        }
+        if (function_exists('field_group_form_process')) {
+          $element['subform']['#process'][] = 'field_group_form_process';
+        }
       }

       if ($item_mode == 'edit') {

And then the process function was converted to a safe callback as part of the D9 update, and if you get this error then I assume that's because contrib or custom modules made it through those two API changes incorrectly.

As #8 said, #process is actually called with a reference, I don't know why either, it has been like this for at least 12 years ($element = $process($element, $form_state, $form_state['complete form']); in D7, which just happens to support that and there is no explanation that I can find and D8 changed to syntax and kept that).

Since it's not needed it's fine to change it but the only reason to so is to be kind to invalid integrations that did not do the #pre_render => #process switch. I assume there is a reason that this change happened and not calling it correctly might result in other problems? And it's definitely not a major bug. Leaving up to the maintainers to commit or close as won't fix.

(I was asked to provide feedback here about this)

swentel’s picture

Status: Reviewed & tested by the community » Closed (won't fix)

Ok, closing then, thanks for the clarification!