-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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.
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
Classic meta boxes modal #34105
Classic meta boxes modal #34105
Conversation
Size Change: -17 B (0%) Total Size: 1.03 MB
ℹ️ View Unchanged
|
Thanks Ella! Code looks good in general but this is more of a tricky design problem to solve 😄 Personally I'm more in favor of the top toolbar. This way we have a better separation semantically. The point of having something in the place where it used to be, is a good one though.. Some small notes about the modal:
|
Thanks for so patiently working to enable the iframe for the various editors. I think it's hard to overstate the benefits it can bring to WYSIWYG and theme design. The design for how to open the dialog deserves a bit of thought. |
I have tried a different approach that involves embedding the meta boxes in DOM shadow in the content itself, but that doesn't work because the meta boxes rely on JS in the top frame and, much like an iframe, the DOM elements of the meta boxes in shadow DOM are not accessible by JS in the top frame. So that approach doesn't work. The meta boxes have to be rendered in the top frame, like we do here with a modal.
Sure, we can make it bigger.
I'll investigate that |
One side effect of metaboxes in the canvas is that the autosave button resets virtually instantly, because it cannot know the saved state of metabox contents. I suspect one benefit of moving to a modal is that we could add an explicit and separate "save" button for just the metaboxes there. Does that sound about right? |
This modal approach won't work either. The meta boxes need to render when the page loads so all JS can initialise. Trying an alternative in #34421. |
@jasmussen @ntsekouras What do you think about something like #34421? The meta boxes are left where they are now (we can't control rendering them at a later point such as in a modal), and then we show/hide them when the user clicks the button or tabs into them with the keyboard. Not sure what else to do, but we need a solution here, otherwise we can't iframe the post editor. |
I think with the right visual treatment, it can work. I will put on my todo list to see if we can find a good visual treatment for it. |
Ref: #47924 (comment) Since Post Editor is now iframed, it doesn't work when post has metaboxes. So There should be a way to use iframe even when classic meta boxes are visible. ref:
|
@jasmussen We now know that metaboxes no longer work with the new iframe. In the latest WP 6.2 beta, the iframe doesn't load when we use metaboxes. Now I found this closed topic here with a possible solution. But it seems that it is still unclear and the question is when can we expect a possible modal solution? Will this be the case with the WP 6.2 version? |
I can't say when it will land, but it looks like it might need a bit more time in the oven than 6.2, so hopefully 6.3? And the plugin in the meantime. |
@jasmussen the solution #34421 from @ellatrix seems ideal to me. It would be really nice if we can get this in 6.3. So all of us can use the iframe post editor. |
Description
This is one tasks we need to do before we can iframe the post content editor. See #33346.
Currently classic meta boxes (if there are any) are rendered below the post content and in the same scroll area as the post content. As a result, they pretty much feel as an extension of the post content.
When iframing the post content, the scrollable area move from the interface's content area to the styled post content area, which does not include the classic meta boxes below it because they are editor UI, not content.
We cannot leave the classic meta boxes below the iframed post content, because it would mean having two scrollable areas.
We also cannot move the classic meta boxes into the iframe, because they're editor UI, not content. It's as if we'd move the meta boxes into the TinyMCE editor iframe. :)
The only solution we have is to remove the classic meta boxes either in a modal or a sidebar. A sidebar doesn't seem right, since these meta boxes have always been given a wider space. So a modal fits better.
The only thing left is to find a food space for a button to open this modal. There's a lot of places where we could put this.
I picked the last option because it would allow people to easily find the meta boxes. It's in the same space they were before, but now you need to expand them with a button. Yes, the button is now in the iframed (styled) post content, but this should be fine compared to having all classic meta boxes embedded in the post content.
How has this been tested?
Screenshots
Types of changes
Checklist:
*.native.js
files for terms that need renaming or removal).