Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hiding all metaboxes prevents POST request to post.php to save meta fields #67207

Open
2 of 6 tasks
enricobattocchi opened this issue Nov 21, 2024 · 5 comments · May be fixed by #67228 or #67254
Open
2 of 6 tasks

Hiding all metaboxes prevents POST request to post.php to save meta fields #67207

enricobattocchi opened this issue Nov 21, 2024 · 5 comments · May be fixed by #67228 or #67254
Assignees
@afercia @stokesman
Labels
[Feature] Meta Boxes A draggable box shown on the post editing screen [Status] In Progress Tracking issues with work in progress [Type] Regression Related to a regression in the latest release

Comments

@enricobattocchi
Copy link

Description

Since WordPress 6.7, when all the metaboxes are hidden in the preferences, the POST request to post.php to save meta fields is not fired anymore as it used to (e.g. in 6.6.2).
This creates problems with plugins, e.g. Yoast SEO, that use a sidebar to allow users to change some post metadata.
In general, this is a different behaviour from what used to happen so any mechanism relying on that request being fired could be affected.

Step-by-step reproduction instructions

  1. Have WordPress 6.7.* on your site
  2. Install and activate only one plugin adding metaboxes, e.g. Yoast SEO
  3. In the block editor, Preferences > General > Advanced, disable "Yoast SEO" and close
  4. important: reload the page or edit another post - the metabox needs to be hidden from the beginning
  5. open the Yoast SEO sidebar and change a setting, e.g. the focus keyphrase
  6. save the post
  7. no POST request is fired to post.php, so the changed value is not saved

Up until 6.6.2, a POST request was fired to post.php even with hidden metaboxes, so the new value was saved.

Important to notice: the value change in the hidden field works as expected, only the POST request is not fired anymore.

Notable finding:
if the user visits Preferences > General > Advanced, enables the metabox and then disables it again, then doesn't reload the page, the changed value will be saved instead. The problem happens only if all metaboxes are hidden since the editor page has been loaded and the relevant settings have not been touched.

Screenshots, screen recording, code snippet

https://www.loom.com/share/bdf879f26d67454caca89aa7b6c3de0b (created by a Yoast support engineer for this issue)

Environment info

  • WordPress 6.7, 6.7.1
  • Firefox 132 on Devuan Linux "Daedalus"
  • Local by Flywheel instance with PHP 8.2.10

Please confirm that you have searched existing issues in the repo.

  • Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

  • Yes

Please confirm which theme type you used for testing.

  • Block
  • Classic
  • Hybrid (e.g. classic with theme.json)
  • Not sure
@enricobattocchi enricobattocchi added the [Type] Bug An existing feature does not function as intended label Nov 21, 2024
@Mamaduka Mamaduka added the [Feature] Meta Boxes A draggable box shown on the post editing screen label Nov 21, 2024
@afercia
Copy link
Contributor

afercia commented Nov 22, 2024

I think the culprit is here:

gutenberg/packages/edit-post/src/components/layout/index.js

Lines 229 to 245 in b58cce6

if ( ! hasAnyVisible ) {
return;
}
const contents = (
<div
className={ clsx(
// The class name 'edit-post-layout__metaboxes' is retained because some plugins use it.
'edit-post-layout__metaboxes',
! isLegacy && 'edit-post-meta-boxes-main__liner'
) }
hidden={ ! isLegacy && isShort && ! isOpen }
>
<MetaBoxes location="normal" />
<MetaBoxes location="advanced" />
</div>
);

Previously, the 'normal' and 'advanced' metaboxes areas were still rendered and hidden with CSS.
After #64351 these etaboxes areas aren;t rendered at all. As such, there's no POST request.

@Mamaduka
Copy link
Member

cc @stokesman

@afercia
Copy link
Contributor

afercia commented Nov 22, 2024 •
edited
Loading

Reading the dev note about the split view for metaboxes, there's no mention that the rendering of the HTML has changed. As in:

When panels visibility is disabled in the Preferences:

  • Previously: the metaboxes HTML was rendered and hidden with CSS.
  • After: the metaboxes HTML is not rendered.

This impacts, for example, any plugin that uses hidden input fields in their metaboxes to save meta and thus trigger the POST request.

It sounds like a breaking change that was overlooked and not documented.

@afercia afercia added [Type] Regression Related to a regression in the latest release and removed [Type] Bug An existing feature does not function as intended labels Nov 22, 2024
@afercia afercia linked a pull request Nov 22, 2024 that will close this issue
Open
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Nov 22, 2024
@afercia
Copy link
Contributor

afercia commented Nov 22, 2024

Of course, avoiding to render the HTML and run extra code is a performance benefit. However, I'm not sure this behavior can be changed without deprecating saving meta via hidden input fields in the metaboxes area and allowing a grace period for plugins to adapt.

@stokesman stokesman mentioned this issue Nov 22, 2024
Open
11 tasks
@t-hamano
Copy link
Contributor

I was not able to reproduce this issue. Is there a step I'm missing?

  • WordPress 6.7.1
  • Only the Yoast SEO plugin enabled
  • All meta boxes disabled
eb7297de708aa91d873579ffe93133ef.mp4

@t-hamano t-hamano mentioned this issue Nov 23, 2024
Open
@stokesman stokesman linked a pull request Nov 23, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@afercia afercia

@stokesman stokesman

Labels
[Feature] Meta Boxes A draggable box shown on the post editing screen [Status] In Progress Tracking issues with work in progress [Type] Regression Related to a regression in the latest release
Projects
WordPress 6.7.x Editor Tasks
Status: No status
Milestone
No milestone
5 participants
@Mamaduka @afercia @stokesman @enricobattocchi @t-hamano