Collapse classic meta boxes under details element #64247
Conversation
ellatrix
added
[Type] Bug
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @ppolo99. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +1.39 kB (+0.08%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
|
I like the idea, and this is probably a good compromise 🎉 |
| ( ( hasV3BlocksOnly || ( isGutenbergPlugin && isBlockBasedTheme ) ) && | ||
| ! hasMetaBoxes ) || | ||
| hasV3BlocksOnly || | ||
| ( isGutenbergPlugin && isBlockBasedTheme ) || |
There was a problem hiding this comment.
Side note: I think we should remove the special treatment for the Gutenberg plugin. The different behavior from the WP core sometimes results in discovering no-framed editor bugs after the code has shipped.
Sorry, I can't remember examples now, but having the same condition in both builds makes sense, IMO.
There was a problem hiding this comment.
I was thinking the same as I was reviewing this. The conditional here seems odd at this point
There was a problem hiding this comment.
We are discussing this, I want to formally remove it in a separate PR.
There was a problem hiding this comment.
100%. My comment was just a side note.
|
Thank you for working on this :) I agree this feels like a good compromise 👍 The details element could use some additional styling to make it fit in better. But that can be a follow up :) |
fabiankaegy
added
the
Needs Dev Note
|
Some bits and bobs we could polish around the chevron icon, the font size, the height of the bar, etc. But not a blocker, and can work without it too. 👍 👍 |
There was a problem hiding this comment.
One thing I noticed is that when any popover is opened in the content, it gets positioned on top of the metabox area:
I think this can be solved by separating the stacking context as shown below:
.edit-post-visual-editor {
isolation: isolate;
}@stokesman has been continuously working on improving the layout of metaboxes and content areas, so he might know a good approach.
|
This is may be a small improvement over #59242 in that it doesn't add a new menu bar icon to toggle their visibility, but it does not solve the root problem highlighted/discussed there. We need a space wider than the sidebar to manage settings while still viewing the content. That is the only reason we continue to have the legacy metabox in the Yoast plugin. We have had the same functionality in a modal for years at this point, but the large majority of users still prefer the metabox because of ease of use and the discoverability problems of other options. This really isn't significantly different from the other PR from a UX perspective other than moving the toggle button from the top to the bottom. |
This PR doesn't change the width at all? I'm not seeing the problem. |
Right now a user can use a meta box while also viewing the content. This prevents that from occurring. |
Yes, but what does this have to do with the width? Sure a user can view both at the same time, but only the bottom of the post content and the top of the meta boxes. I'm not sure why this is a problem. |
|
It would probably be easiest for you to go re-read the discussion on #59242 to understand the root problem rather than repeating the whole discussion here. |
Is it important to be able to "see" the content and the meta box at the same time? Indeed, the user can only see the bottom of the content and the top of the meta box at a time, but can quickly move between the visible areas by mouse scrolling. What is the benefit of being able to see both the content and the meta box without having to open and close the meta box? |
@earnjam I'm well aware of that discussion. I understand that a concern is the width, but these meta boxes don't change in width. I understand that users use these wide one more, but they won't disappear. |
No, the concern is not the width alone. The concern is that the sidebar is the only option for an interface where you can control settings while also viewing the content. The sidebar is also very narrow, so it is not ideal in a number of situations. The Gutenberg-native option for plugins that require an interface wider than the sidebar is to use a modal or something that covers the full-screen. Those do not allow a user to view the content at the same time. So hence what I said (and was the general consensus on the other PR):
|
I don't get this requirement. Like I said, it's not been the case before that you can view content and wide settings side by side. The meta boxes below the content would previously scroll it out of view. |
There was a problem hiding this comment.
This LGTM code wise and it seems like a good compromise. The only difference is the one discussed about being able to see the bottom of the content and top of the meta boxes, but I don't think it's enough to outweigh the benefits of the direction to have the editor iframed always.
In general it would be good to land soon, to have more time to test in the plugin.
I'm not the biggest fan of this approach either but I understand compromises need to be made and this is probably the best solution for now. At the very least, it's much better than the toggle button that was previously proposed. I'll provide more feedback once this is merged into the Gutenberg plugin and we get a chance to try it out. |
|
I made #64351 to allow testing side by side visibility of a post and wide metaboxes. I’m not opinionated on this and just thought it was worth a try. |
That looks fantastic! |
|
I much prefer this approach over the previous! Could I confirm that the intended usage of the arrows within the meta box menu is correct? I've created a short video to show the meta custom field be added to the page menu by using the "down arrow", with the "up arrow" seemingly removing it (I understand it's just going back into the Meta menu, however to me, it feels like it should open up the meta menu to show it's back in there). Screen.Recording.2024-08-12.at.17.58.21.mov |
|
As has been said by many others the lack of visible and quickly accessed context for the meta boxes being edited is problematic. For my enterprise users this is another set of clicks added to their daily workflow and when we're managing 100's of articles per day this makes a real difference. The set of clicks are exacerbated by the need to open and close the meta box toggle multiple times to flip back and forth from the content for context. As a real world example, all of the brands I work with have an existing meta boxe under the main content area to manage headline permutations. We have multiple for multiple reasons, this is standard in publishing. We need easy access to the context of the content to write these headlines. The side bar is too small for of an interface to place this existing meta box, it is a claustrophobic working experience when you can't see all of the headline you are writing and prohibits easy scanning of text for reviewers. |
|
I noticed that there is no issue that this is attached to, so it's not clear to my why it's so important for the editor to load in an iframe at all times. Overall, I think @earnjam is correct. There needs to be a way to edit not content in a way that is both wider than the sidebar and also visually shows the content. If putting the editor in the iframe is necessary, what about moving the iframe for meta boxes into that iframe? |
|
Closing in favour of #64351 |
What?
Legacy meta boxes prevent the editor content from loading in an iframe. We cannot have two scrollable areas in the content area (and both the iframe and meta box area would be scrollable).
The solution I took here is to collapse the meta boxes at the bottom of the page. The location people would access them would remain the same (bottom of content), but now you have to switch between meta and content, both cannot be open at the same time.
Why?
Meta boxes should not trigger the iframe to be removed.
How?
Testing Instructions
Go to Options > Preferences > General > Advanced and toggle custom fields.
Or install a plugin such as Yoast.
Testing Instructions for Keyboard
Screenshots or screencast