Save button missing when using the Gutenberg/Mercury editor module

There must be a better way in checking if Gutenberg is active other than checking for the existance of a css class 😅 and ignore our sticky implementation, the best way probably would be if Gutenberg is using our ignore hook for this, but as a temporary workaround this MR should help 👀

gutenberg_gin_ignore_sticky_form_actions() {
  // Check if Gutenberg is active here and return FALSE
  return FALSE;
}

So you might want to open an issue in their issue queue to handle this properly.

the best way probably would be if Gutenberg is using our ignore hook for this,

Oh, I wasn't aware of the new hook. That's a good one. That should be rather straightforward to get into gutenberg or gin_gutenberg module.

Thanks for the input @saschaeggi . I will try it out.

@saschaeggi It does not seem to be the sticky button option. I have it disabled. It's the \Drupal\gin\GinContentFormHelper::isContentForm function that always returns TRUE, because

($form_state && ($form_state->getBuildInfo()['base_form_id'] ?? NULL) === 'node_form')

always evaluates true on node forms.

Was the following maybe intended to be a `&&`, because what comes after seem to only refer to the sticky action functionality?

if ($this->stickyActionButtons($form, $form_state, $form_id) || $this->isContentForm($form, $form_state, $form_id)) {

The or is the correct behavior in the check

Ok, that's good. But in our case it does not seem to be possible to use the hook_gin_ignore_sticky_form_actions, because the isContentForm condition will always evaluate true, because of node_form base form id.

There must be a better way in checking if Gutenberg is active other than checking for the existance of a css class

If you have a node object available you can check if Gutenberg is enabled for its content type via `_gutenberg_is_gutenberg_enabled($node)`. But that requires more knowledge about the form, for example the form object or a little bit more hacky: based on route information.

@szeidler a form (data?) attribute would be nice so we could check for that instead of a css class (something like data-gutenberg-enabled) on the form root element ($form['#attributes']['data-gutenberg-enabled'] = TRUE;)

Could we add something like that in Gutenberg?

Could we add something like that in Gutenberg?

Yes, that sounds like a no-brainer for me. I'm going to look into it.

Hi,
It seems it is not a Gutenberg specific issue.
Save button is also missing for Mercury Editor and possibly other modules that add buttons.

This is a Gutenberg specific issue, the Mercury editor issue was already fixed in dev.

@saschaeggi I created an issue + MR at ✨ Add attribute to form if Gutenberg enabled Active

Let's wait until ✨ Add attribute to form if Gutenberg enabled Active has been merged 👀

@saschaeggi The changes in Gutenberg has been merged, so putting this issue to "Needs Work" to adopt the new changes.

@szeidler this needs a review 👀

I just opened an issue, https://www.drupal.org/project/gin/issues/3461545 🐛 Buttons missing or not working properly in Views Active , about action buttons not appearing in Views only, but I'm using Gin as the admin theme, not the sites theme. Could this issue be related? If so, I'll just close that one. In my case, I'm seeing the save, not the other action buttons.

@saschaeggi In #13 is the fix for Mercury Editor in dev https://www.drupal.org/project/gin/issues/3459995 🐛 null is not an object (evaluating 'newParent.querySelectorAll') Fixed or something else? With the null is not an object patch with Mercury Editor the save buttons are gone. Mercury editor is looking for the ID #edit-submit which doesn't exist at this time and then hides it with javascript.

I've tried adding the mercury editor form to the code that is referenced in https://www.drupal.org/project/gin/issues/3461545 🐛 Buttons missing or not working properly in Views Active but this doesn't bring the save buttons back.

I tried the hook_gin_ignore_sticky_form_actions() without success.

Applying this patch to RC13 and removing the null is not an object patch addresses both issues in Mercury Editor.
Applying this patch to RC13 and leaving the null is not an object patch also works.

Hi @anthonyroundtree, I've raised the MR for the issue https://www.drupal.org/project/gin/issues/3461545 🐛 Buttons missing or not working properly in Views Active which will fix the issue of not rendering the action buttons for views. Please refer to this issue 🐛 Buttons missing or not working properly in Views Active and it occurs only when the beta feature Enable sticky action buttons is enabled.

This issue has been raised for the Save button missing while using Gutenberg module. The provided MR will resolve the issue for Gutenberg module only. It will not solve the issue for action buttons missing for view as this issue has been raised for Gutenberg module only.

Similar to @pbabin I'm also having this issue when using Mercury Editor 2.1.1 with Gin 3.0-rc13 (I don't have Gutenberg installed).

I get the save button back by using the first patch in this issue:
https://www.drupal.org/files/issues/2024-07-09/gin-save-buttons-missing-... →

along with this patch:
https://git.drupalcode.org/project/gin/-/merge_requests/458.diff
from issue
https://www.drupal.org/project/gin/issues/3459995 🐛 null is not an object (evaluating 'newParent.querySelectorAll') Fixed

I do not have sticky action buttons enabled in gin.

Again, with reference to #13, am I missing a patch for Mercury Editor which would mean I don't need to use the first patch from this issue above:
https://www.drupal.org/files/issues/2024-07-09/gin-save-buttons-missing-... →

@rachelf The patch from the beginning of the issue is only an emergency workaround, if your content editors are blocked from publishing articles.

It's not a solution for the underlying issue. A real solution is discussed in the merge request.

Many thanks for clarifying that the initial patch is for emergency use @szeidler.

Is the underlying issue only specific to Gutenberg (which I don't have installed)? Certainly the discussion in the merge request relates to Gutenberg, so how come I am also losing the Save button? Is there a comparable issue that I've missed for Mercury Editor, similar to this one in the Gutenberg issue queue:
https://www.drupal.org/project/gutenberg/issues/3460488 ✨ Add attribute to form if Gutenberg enabled Active

My apologies if I'm cluttering up this issue with irrelevant comments - and please let me know if I should be raising a separate issue over in Mercury Editor or elsewhere, or if there is a related issue.

@szeldler & @saschaeggi - Can I propose the following change?

if (!isset($form['#gutenberg_enabled'])) {
to
if (!isset($form['#gutenberg_enabled']) && !str_contains($form['#form_id'], 'mercury_editor'))

The forms that come in from mercury_editor on edit and create is node_sf_paragraph_page_mercury_editor_form.

I've tested this change locally and it addresses the disappearing save button when using mercury editor.

If so, I'm happy to put in a merge request with the proposed change.

I can confirm that the proposed change in MR476 works for my set up.

Can confirm The MR !461 works fine with the latest dev release of Gutenberg.

saschaeggi → changed the visibility of the branch 3460150-save-button-missing-3x to hidden.

saschaeggi → changed the visibility of the branch 3460150-save-button-missing to hidden.

The MR !476 needs a final review for both Gutenberg & Mercury editor

Tested !476, works as expected in Gutenberg 👍

I fixed PHPCS and inverted the mercury_editor condition, which was the other way around after the PHP 7.4 compatibility change.

I can confirm: Gutenberg is working fine. I tested mercury editor as well and the updated MR brought back the submit button. But maybe one of the Mercury Editor users could give it a try as well.

I've tested Mercury Editor with the most recent changes from MR !476. The save button is available on both the creation of a node with ME and the edit of a node with ME.

Thank you for the update from str_contains to strpos. Old habits die hard.

Thanks y'all 👏

Automatically closed - issue fixed for 2 weeks with no activity.