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 |
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! |
|
This could use some testing |
|
Yes closing this in favour of #64247 :) |
@gaambo You should not use blocks unless it's actually a preview of content as it would appear on the front-end. Blocks can use inspector controls and modals of course, which would be styled as UI. |
I know, but the docs and other articles often mention to use blocks with a meta-field storage instead of meta boxes - it was mentioned in this discussion here as well. And I just wanted to chime into this discussion, that blocks - even if they store the value in the postmeta - are often not a good replacement for meta-boxes. |
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