Move legacy meta boxes to toggle #59242
Conversation
ellatrix
requested review from
ajitbohra,
ryanwelcher,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
|
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: @Kyleidoscope. 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. |
|
I like this approach. It will actually make it much easier to edit metabox content. |
|
Size Change: +254 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in c5a425c. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7990653555
|
|
Seems to balance the tradeoffs and allow for the best of both worlds. About this icon:
I tried a new one:
What do you think? If you're into it, here are the vectors, you can call it |
mtias
added
the
General Interface
|
@jasmussen The problem with that icon is that is symbolises the previous way we were showing meta boxes? Not that the icon I used it is great, I just didn't know what it use :) |
|
How would you feel about this one instead?
I personally prefer the one shared on this thread, but it's not a strong opinion. |
|
I also really like this approach. But I just tested this with the first Plugin that came to mind still using the legacy metabox (Yoast) and it doesn't render correctly in there. They seem to render the metabox with a I think this is a good test case we should be considering as the baseline test for this implementation. |
|
What do you mean with Yoast not working? It seems to work for me: 
|
|
Okay I dont know what happened before. It is now working for me also. Thanks and sorry for the confusion |
ellatrix
force-pushed
the
try/meta-boxes-toggle
branch
from
10a6774
to
81bd1a5
Compare
ellatrix
added
the
[Feature] Meta Boxes
| @@ -328,6 +328,10 @@ _Returns_ | |||
|
|
|||
| - `boolean`: Whether the metaboxes are being saved. | |||
|
|
|||
| ### showMetaBoxes | |||
|
|
|||
| Undocumented declaration. | |||
|
Given the primary focus that the other buttons/icons in that area already have while creating content, might it be better to move this sort of toggle/interaction a bit farther away and perhaps into the |
|
To help with moving away from metaboxes and into the tooling we have today, I opened an issue to create a how to guide in the block editor specifically for this: #59804 |
|
I tested this and seems to be working fine as a POC. I see an advantage to make each plugin load their metaboxes into a separate modal. The ongoing scrolling if more than one plugin loads metaboxes for a post is quite cumbersome and a big downside of the current implementation. see video metabox-modal.mp4It would be an instant improvement if there were a separation of concern and each plugin use their own space. That way developers can have more controls over the layout and not step on each other's toes when design changes are implemented. The button could change into a drop-down box listing each plugin. |
|
@bph thanks for testing. I don't think the metabox API allows us to discriminate per plugin. A plugin can register one metabox or multiple related meta boxes. |
|
Hmm @youknowriad It seems the Options > Preferences > Advanced screen is able to separate displaying of metaboxes by plugins. Maybe that's a start? |
|
@bph The problem is that is not a guarantee. It's worth considering but a plugin can register multiple meta boxes at the same time. |
For instance ACF allows users to define field groups (to group fields together) but the expectation is that it's still the same form in the end. |
|
Hi, it's Anh from Meta Box. Our plugin's goal is helping developers to create meta boxes. And this change might affect both us and our users. One problem we see as @arnaudbroes said above about the UI. The current (below content) is a better place for meta boxes than sidebar slots, because of the horizontal space it can use. Our plugin allows users to put custom fields in columns, tabs and groups (including nested groups), so the UI can be complex for some use cases. The thing is while we can improve UI of each field, we leave the freedom to users to organize fields, so the UI is some kind of unpredictable. In my quick test, the toggle seem to work fine for most fields. However, the WYSIWYG field doesn't allow users to enter content. My concern (question) is: is there any technical issues that we need to worry about? I remember previously when Gutenberg started to support meta boxes, it didn't work with file uploads. FYI, we have more than 40 field types, from simple fields like text, textarea to complex fields like Google Maps, Open Street Maps, file upload, select2, date time picker, etc. If you can share more about the technical background here, so we can prepare for what's coming, that would be great. |
There was a problem hiding this comment.
While I agree with the proposed change, this is too much of a "sudden" swap for many developers, and we should keep compatibility in mind.
I understand the argument that metal boxes were always legacy APIs, but as a team focused on UX (I hope that's what we're doing), we can't disregard people using the canvas like this.
|
I don't disagree that we need to account for these plugins but as I explained before, we need to find a path forward for these plugins with the new APIs. Meta boxes already cause multiple regressions in the editor.
And may cause other regressions in the future.
So my thinking is what we can do to encourage developers to move away from meta-boxes now, which will allow us to make progress on the rest of the projects. |
|
Like I said, I don't disagree, but I think we need a better middle ground, but this isn't it (IMO). I don't have any ideas at the moment, but happy to help out. P.S. I think we fixed the revision issue. |
I completely agree with this, I fully understand that this change is needed to allow further progress to be made on other issues and features and I am not against making this change, but I don't think the current solution is ideal in terms of UX. |
|
What should be the solution for you folks, what's preventing you from using the new APIs?
One other solution would be to auto-enable classic editor if we detect a meta-box but I don't really want to come to that. |
|
@youknowriad I think the theme that I am reading through all the comments is that it's not a imitation of the available API's but rather a UX issue where manny plugins have interfaces that don't fit into a sidebar but also don't really fit the concept of blocks. A good example of this to me is how the current new experimental WooCommerce single product editing experience didn't opt to be fully block-based but instead uses a more fixed form approach to enter a lot of metadata. To me it sounds like the best way to get more plugins to migrate to using the block editor native approach would be to expose additional slots where UI can be rendered. Like introducing a plugin location at the bottom of the screen that does not use the old metabox API but actually uses native block editor apis. I know that @SaxonF has given this issue quite a bit of thought in the Admin Redesign for how the UI could handle forms in setting screens. Maybe some insights from those explorations could help us come up with a compromise that would make it easier for plugins to migrate over when their UI doesn't fit into a sidebar |
|
That makes sense yeah!
That's an interesting example and it shows that it's already possible to use block editor APIs and components to take over the screen and build such a custom editor.
I don't think new Slots are a solution because a meaningless slot (which is what meta boxes are) is just a way to hack the UI which will put us in the same situation again if we ever want to modify the UI again. We shouldn't repeat the mistakes IMO. That said, I do think there's a path forward for things like data views, fields... which will address a lot of these use-cases but I don't really expect this to be ready soon while we may need a solution for meta boxes sooner. |
This basically sums it up. Many plugins like AIOSEO and Yoast have already been fully integrated with the sidebar and they use the aforementioned Block Editor components. It's just that we know that an absolute majority of our users prefer to use our metabox over the sidebar menu because the UI feels more intuitive. This is mostly due to the larger amount of horizontal space that is available (e.g. AIOSEO uses tables for a few features that simply do not fit in the sidebar, and we have to open a modal for those as a result).
If technically viable, that would indeed be ideal. We really don't mind having to adapt to new APIs, it's mostly a matter of having a similar amount of space available to us. |
Even if we wanted to, it's not really possible to add a slot below the content without putting it inside the iframe. If we add it outside the iframe, we end up with two scrollable areas because the iframe is scrollable and the meta boxes would need to be scrollable as well. We can't expand the iframe contents because that would break viewport units. For me two whole point of this PR is to have the iframed editor consistently regardless of whether a plugin uses meta boxes. |
|
A slot within the iframe would mean it's all styled as content. So at that point you might as well create blocks? |
|
@SaxonF actually just shared a new walkthrough of the current explorations for the admin redesign project in slack here: https://wordpress.slack.com/archives/C02S78ZAL/p1710741693260459?thread_ts=1710189675.902729&cid=C02S78ZAL To me the idea of the content area which can be used to expose settings that are not directly tied to the frontend appearance of the site on the web makes a lot of sense. See the prototype: https://www.figma.com/proto/804HN2REV2iap2ytjRQ055/System?page-id=2244%3A16904&type=design&node-id=2737-40156&viewport=-2476%2C655%2C0.54&t=V97h1DsXrJBso2X6-1&scaling=min-zoom&starting-point-node-id=2737%3A40126&mode=design And here one showcasing it populated with an example of a product CPT: https://www.figma.com/proto/804HN2REV2iap2ytjRQ055/System?page-id=2374%3A25967&type=design&node-id=2511-45456&viewport=748%2C1481%2C0.33&t=1lc4tsPo3i43E7Td-1&scaling=min-zoom&starting-point-node-id=2476%3A23475&show-proto-sidebar=1&mode=design
|
Just want to share my experience for creating custom blocks for "meta" data entry (not explicitly meta fields, but anything that is about the content):
I've used it for a "testimonial" CPT, which only has a quote block + a custom block and a fully locked template - it works for that use case. But for a general plugin (like SEO) which will need to work for all post types, that may be suboptimal. I understand the desire to provide more complex UIs to users as a plugin developer. The sidebar and its slots are great, but they mostly work for "vertical" forms with one input per row. Anything that's a table, needs a preview (like social sharing) etc. doesn't have enough space there. From an extenders' standpoint, I also think a SlotFill under the editor would be great. Although I see there are technical aspects that make that problematic. Some plugins building custom block editors also try to work with tabs at the top (like the new WooCommerce product editing experience, givewp form builder, LearnDash quiz builder). I don't think the UI is perfect, and I've got no idea if it's accessible. But from a user perspective it makes sense to have "content", "settings", at the top. Conclusion: I understand the direction this PR wants to take, and I support it - but I think this implementation may be a little too "harsh". |
|
Hi @ellatrix, I'm a Seriously Simple Podcasting plugin developer. Could you advise, will it work if we move the meta fields to the sidebar without implementing the toggle feature? Like this:
|
|
@ellatrix do you have any updates on the progress of this PR? |
|
Definitely too late for this release now, let's try the next. I think I'll change the PR to a collapsible details panel in the footer area instead, to make the change less big. |
Sounds good, thanks for the update! |
What?
(would also fix #61210)
Why?
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).
See #34105 for more background.
How?
Testing Instructions
Testing Instructions for Keyboard
Go to Options > Preferences > General > Advanced and toggle custom fields.
Screenshots or screencast