Uncaught TypeError: formActions is null on a form that is trying not to use Gin form modifications

Created on 17 November 2024, 7 months ago

Problem/Motivation

Custom form, not trying to use Gin form changes, "Proceed to next step" button does not workโ€”no result on pressingโ€”due it seems to a JavaScript error in Gin:

Uncaught TypeError: formActions is null
    updateLabelIds https://example.ddev.site/themes/contrib/gin/dist/js/more_actions.js?smwn10:17
    init https://example.ddev.site/themes/contrib/gin/dist/js/more_actions.js?smwn10:11
    init https://example.ddev.site/themes/contrib/gin/dist/js/more_actions.js?smwn10:10
    attach https://example.ddev.site/themes/contrib/gin/dist/js/more_actions.js?smwn10:4
    attachBehaviors https://example.ddev.site/core/misc/drupal.js?v=10.3.8:166
    attachBehaviors https://example.ddev.site/core/misc/drupal.js?v=10.3.8:162
     https://example.ddev.site/core/modules/big_pipe/js/big_pipe.js?v=10.3.8:153
     https://example.ddev.site/core/modules/big_pipe/js/big_pipe.js?v=10.3.8:184

This is custom codeโ€”the form ID is node_individual_wizard_formโ€”and it is not expected to be using Gin's special features around action buttons at all.

Excluding the form ID with hook_gin_ignore_sticky_form_actions() or even the entire related entity route with function hook_gin_content_form_routes_alter() does not fix the error.

Steps to reproduce

Make a custom form? Intermediate problem seems to be that the form has no edit-actions, HTML output is:

 <label data-drupal-selector="edit-submit" for="edit-submit--2" role="button" class="button button--primary" tabindex="0" data-gin-sticky-form-selector="edit-submit">Proceed to next step</label>

Proposed resolution

Do not load/apply the more_actions JavaScript file where it is not called for.

Remaining tasks

User interface changes

API changes

Data model changes

๐Ÿ› Bug report
Status

Active

Component

Code

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States mlncn Minneapolis, MN, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @mlncn
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States mlncn Minneapolis, MN, USA

    The reason this is getting applied when it is not expected is because the base form is a node form and so the condition $form_state->getBuildInfo()['base_form_id'] ?? NULL) === 'node_form' (line 375 of src/GinContentFormHelper.php) is evaluating to true.

    The reason we cannot opt out of it is because the $form_ids_to_ignore (line 335 of src/GinContentFormHelper.php) is hard-coded, with no alter hook.

    Given this is a pretty custom one-off case i'm not sure we should look more into automatically ensuring this does not apply when it might break things, but it seems that might be possible (check for edit_actions somewhere)?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States mlncn Minneapolis, MN, USA

    Ah but excluding the form means the buttons do not show up at all.

    Seems that the modifying/placing and the removing should be handled in one spot.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States mlncn Minneapolis, MN, USA

    Changing this to a feature request, since as covered above we can avoid this error if we can exclude custom (but content-extending) forms from Gin's enhancement of content forms.

    Note that the ability to exclude by route will not help because the check for base_form_id, while mixed in with the check for routes, is independent and if it returns true the enhancements get applied.

    Also, even where restricting by route can work, the route as in the example is for all entities of a type, so for all nodes, not by content type, so in many cases definitely too broad.

    Allowing the $form_ids_to_ignore variable to be modified by third-parties (the same way routes already can be, in the same method) seems a very straightforward improvement.

    Merge request forthcoming.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States mlncn Minneapolis, MN, USA
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States mlncn Minneapolis, MN, USA
  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany jurgenhaas Gottmadingen

    @mlncn We're currently working on ๐Ÿ“Œ Improve sticky actions implementation Active and with the latest version of the MR!536 the javascript error in the IS should be gone. Would you mind giving that a try and letting us know if that's true?

    If not, please help us to find out what's still wrong with that, as we need to iron that out before we start looking into form_ids_to_ignore and route_names in the \Drupal\gin\GinContentFormHelper::isContentForm.

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany jurgenhaas Gottmadingen
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States mlncn Minneapolis, MN, USA

    Congratualations on figuring #3489493 out and apologies for not helping there; but this should be unblocked now.

  • Status changed to Needs review 17 days ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bjcooper Nebraska, USA

    I've run into a related issue here, where you can't actually disable sticky action buttons on content forms.

    The GinContentFormHelper->formAlter() method does actually check if the current form ID should have sticky action buttons or not using GinContentFormHelper->stickyActionButtons()โ€”which invokes alter hooks so you can ignore form ids via hook_gin_ignore_sticky_form_actions_alter. This I've done, and I can see that $sticky_action_buttons has been set to FALSE for the form I'm trying to skip sticky action buttons on.

    However, formAlter() immediately ignores that flag for content forms, rendering hook_gin_ignore_sticky_form_actions_alter completely useless for content forms:

    public function formAlter(array &$form, FormStateInterface $form_state, $form_id) {
       //...
    
        // Save form types and behaviors.
        $use_sticky_action_buttons = $this->stickyActionButtons($form, $form_state, $form_id);
        $is_content_form = $this->isContentForm($form, $form_state, $form_id);
    
        // Sticky action buttons.
        if (($use_sticky_action_buttons || $is_content_form) && isset($form['actions'])) {
          // Add sticky action button behavior...
    

    This seems like an oversight in the logic, since you can never disable sticky action buttons on content forms this way, in effect, ignoring gin_ignore_sticky_form_actions.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bjcooper Nebraska, USA

    At any rate, adding similar ignore form id alter hooks to isContentForm() like @mlcn mentioned would certainly help. Ideally, though, the stickyActionButtons() method would actually control sticky actions behavior (it could default to true for content forms by calling isContentForm() itself when the setting is enabled), and the remaining alterations specific to content forms would only be controlled by isContentForm() and its new alter hooks.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bjcooper Nebraska, USA

    Related issue: https://www.drupal.org/project/gin/issues/3406878 โœจ Support for the Mercury Editor module Active

Production build 0.71.5 2024