Size Change: +2.03 kB (+0.11%)

Total Size: 1.77 MB

_{compressed-size-action}

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: torounit <toro_unit@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: arnaudbroes <arnaudbroes@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

This PR is working pretty well.

My only concern is that the meta box height will be fixed at 50%, which might make it difficult to see the meta box content.

I'll ping @earnjam and @arnaudbroes about this:

Also, the E2E tests related to meta boxes are failing, so we may be missing some problems.

@stokesman @t-hamano
https://github.com/user-attachments/assets/6e55f9e2-fa6f-430e-a7fd-2943288acdc4

How about using ResizeableBox to make the height changeable?

How about using ResizeableBox to make the height changeable?

@torounit, I did think it would be likely to be suggested. It’s rad that you made a working demo. I'm not sure if it’d be necessary for a first try with this approach but I’m not opposed to it either.

With or without it, I believe the priority would be determining and addressing any responsive issues. Like maybe at less than a certain height the view should not be split and work a bit more like #64247.

Also, the E2E tests related to meta boxes are failing, so we may be missing some problems.

Hopefully the latest commit takes care of any e2e failures 🤞.

I'm not sure about this. It's a solution that imo makes both experiences a bit worse. You no longer have a full view of the content, and neither do you have a full view for the meta boxes. What happens when you have lots of collapsed meta boxes? The height of all collapsed meta boxes will need to be capped.

What we could do is combine both approaches. So have a toggle in the header (the one from Move legacy meta boxes to toggle), and also the resizing.

So by default it would put content at 50% and meta at 50%, but you have the option to hide the meta boxes with the header toggle, and the option to resize the height (maybe even all the way to 100%).

Currently, the header component is integrated into the editor package. Is it possible to display the meta box toggle only in the post editor?

Currently, the header component is integrated into the editor package. Is it possible to display the meta box toggle only in the post editor?

It can probably be an option? @stokesman would you be ok in adding it to your PR here?

If this PR is updated, I'd be happy to test it.

What we could do is combine both approaches.

I find the general idea favorable though lean toward using the details element instead of a toggle in the header for a few reasons:

• The header already has a lot of UI
• The details element keeps the toggle nearer its content and when collapsed occupies the place where folks are accustomed look for the metaboxes.

I’ve tried it and it seems workable. I will probably push an update with that soon but am open to hearing any thoughts on why a toggle in the header would be better in case I'm missing something.

I've updated the PR in various ways. The primary changes:

• The height of the metabox area is limited to 50% by default to avoid many metaboxes from taking up too much space even if they’re collapsed
• When the viewport is short (arbitrary < 550px) the metabox area is collapsible (details element)
• When the viewport is not short, the metabox area is resizable

Hopefully the decisions will be self-explanatory with some testing but I'm happy to discuss and open to change them.

EDIT: I’ve updated the screen recording in the description in case anyone wants a quick look.

I’d like to ask @ppolo99, @hrkhal and @aaronjorbin to have a look at this as they did provide feedback on #64247 and may find some of their concerns addressed here.

Since #64247 has been added to the 6.7 Editor Tasks board, I will also add this PR to that board.

This is wonderful!

Can we keep the details toggle for any screen size? I think we need a way to quickly show and hide at all times. Not sure if this is already done, but it'd be great to persist the open/close state.

With those changes it would be good to merge imo!

Reduced height	Normal height

Can we keep the details toggle for any screen size? I think we need a way to quickly show and hide at all times.

If considered necessary, I think it’d be nice to avoid the UI bulk of a resize handle stacked atop the summary and I don’t know if it can be done easily working with details and ResizeableBox. So another approach would be using a custom resize handle that supports toggling. A custom resize handle already seems necessary for keyboard support #64351 (comment).

Not sure if this is already done, but it'd be great to persist the open/close state.

I take it you mean persist it in user preferences. That’s not done and I agree it’d be nice. Perhaps the resized height should also be persisted?

If considered necessary

I think a toggle is necessary, imo. Like I said before, this can be in the form of a top toolbar button. I think that's actually what @mtias preferred last time we talked about it.

You can actually keep everything as it is now, and just add the toggle to the top toolbar to add/remove the whole thing. The details is probably still useful for smaller screens.

I do also slightly prefer a bottom toggle compared to a header toolbar toggle, but if it's technically too difficult it's better to have something and revise it later.

this solves the problem

Thanks for sharing. I tested and found it makes the block canvas content unable to be scrolled completely. It was better after removing the min-height your snippet adds but there was still a bit of clipping so might not work for all post lengths.

.interface-interface-skeleton__content:has(.edit-post-meta-boxes-area) > .editor-visual-editor{
    flex-shrink: 0;
    flex-basis: auto;
    /*
    The height can lessened if you prefer a shorter editing canvas.
    Subtracting 45px is so the first meta box header is visible even when scrolled to the top.
    */
    height: calc(100% - 45px);
}

.interface-interface-skeleton__content > [aria-label="Meta Boxes"] {
    /* Not necessary except to ensure the height of editing canvas can be set to very short. */
    height: auto !important;
}

.edit-post-meta-boxes-main__presenter {
    /* hides the resize handle */
    display: none;
}

.interface-interface-skeleton__content:has(.edit-post-meta-boxes-area) .editor-visual-editor:not(.is-scrollable) .block-editor-block-canvas {
    /* Pads the editing canvas so the space around it can trigger scrolling the outer scrolling area directly */
    padding: 24px;
}

For me that still won’t create a better experience than what is shipped but hope it helps any folks for whom it might.

Just came here to comment on this annoying feature that you guys introduced. First, do you guys actually use WordPress to produce content. Because some of the features that you introduce, it's like you just work on WordPress while using Joomla for your work.

This feature is so annoying I don't know what to do. I am trying to write an article. Previously, the entire page was one element and I could scroll from top to bottom. At the bottom, I have Yoast SEO and I need to constantly refer to it because I want my content to remain SEO friendly. Eg, do I have the right number of keywords yet?

Anyway, it was a simple matter of scrolling to the bottom. Now I need to first resize the screen to access that section. It's adding 20% more work needless to my content production work and it's needless. In fact, now the editing screen appears so small it's practically unworkable.

Please, stop changing things that are working fine. And if you must make changes, make them optional. As an example, it would be a better option for the Drag to resize option to be disabled using a double click or something. Yes, we know you work on WordPress pro-bono but really guys. Have sympathy for the people who actually use the product for work

For God's sake how do I turn this incredibly awful "feature" OFF??? Why would you ever do this? It makes writing nearly impossible when you rely on Custom Forms and Meta!

Please disable this. Make this optional at the absolute minimum. This is a HORRIBLE CHANGE TO THE EDITOR! Change this back!

Thanks @stokesman. I hope the (crude) image below highlights my concern. Please ignore the fact that the Yoast section is mirrored twice in the screenshot below. In any case, any other SEO plugin could be down there. In the meta box area. Or any other plugin. It's all about functionality. Having to drag to resize all the time makes for a frustrating user experience. I have seen several people complaining all over the place, including on WordPress. The issue is a bit hard to explain but...

Yes! This is the issue exactly - IT IS HORRIBLE! Whatever went down in 6.8 to get to this needs to be changed back!

Yeah, this "feature" is pretty terrible. I use SEOPress and ACF and editing the stuff in those metaboxes is such a PITA now.
Is there a way to disable it? There has got to be a way to do it right? It's such a bad user experience.

I opened an issue about this ( #63298 ) but was told to comment here instead.

I use 6.8, Twenty Twenty Five as a base theme and custom fields created with Pods Framework.

Maybe I just have to get used to it, but this new layout (content in its own scrolling frame and then meta stuff in a second scrolling frame) is terrible. Instead of quickly scrolling the entire Content+Meta stacked window in one quick action like it used to be (I use the mousewheel) now I have to move the mouse pointer to the window control, click, drag it up and then scroll inside the meta window. Then if I want to go back to editing Post content, I have to do the reverse, shrink down the Meta box area to expand the content editing area. And so on back n forth! This is terrible usability and I don't know why the developers above are so happy about it.

Please revert or provide an option to choose between the one window vs two. :(

this solves the problem

function custom_admin_script() {
    echo '<script>
        document.addEventListener("DOMContentLoaded", function () {
            function removeClassFromElements() {
                let elements = document.querySelectorAll("div.edit-post-meta-boxes-main");
                elements.forEach(el => {
                    el.classList.remove("edit-post-meta-boxes-main");
                });
            }
            removeClassFromElements();

            let observer = new MutationObserver((mutations) => {
                mutations.forEach(mutation => {
                    if (mutation.addedNodes.length) {
                        removeClassFromElements();
                    }
                });
            });

            observer.observe(document.body, { childList: true, subtree: true });
        });
    </script>
    <style>
	    .block-editor-iframe__scale-container {
	    	min-height: 1000px !important;
	    }
    </style>
    ';
}
add_action('admin_footer', 'custom_admin_script');

I tried this snippet - thank you, it is a significant improvement over what was pushed in WordPress 6.8. I changed the min-height to 500px and that seemed to allow for smooth scrolling across the entire document (removing that snippet or keeping it at 1000px created a lag).

However, I really can not stress enough that this is a solution in search of a problem. While I admit I don't understand the technical complexities of the need for an iframe in the entire editing experience and not just the block editor section, I'm sure if you're going to these lengths and across this many PRs, it must be important. But, this is NOT the solution. At least, not for those who actually work in WordPress - SEO, Custom Post Types, ACF, etc, etc. What you have done to the editor is make things significantly more difficult - we're talking 30% or more additional effort. I enter dozens, sometimes hundreds, of books a week via Custom Post Types and Custom Meta Fields, and that's not even getting into SEO or Analytics. In ONE DAY you brought my business to a halt with this. I have done nothing else in the last 24 hours but try and solve this problem that you have created. This snippet allows me to work, at least, though there is still an impact.

This entire concept needs to be rolled back and re-thought. I had no idea anyone was even considering this kind of change to the editor - I would have given a very staunch veto. Others in other PRs have chimed in - specifically Yoast and ACF - but you still persisted on this path. You impacted nearly 100 of my sites and pissed off my customers - it damn well better have been worth it.

There has to be a better way. Even this code snippet, which does improve things, is not even close to what was in 6.7.

Please reconsider what you are doing and roll this back. Whatever you are trying to achieve, this is not the way to go about it.

Going to add my voice here. Some of my clients are already calling me confused and annoyed. This change pushes custom fields in much too small a space. So much scrolling and toggling and it all just works much less smoothly than before. Many sites use ACF or similar, with bigger fields, too, like galleries. These are almost impossible to manage now.

Please, just make the edit screen longer again, like before. This vertical split thing is horrible. And I don't like the work-around above that likely won't work for long and isn't official.

Another solution can be tried to position the meta boxes better and have less clutter, but this really isn't it.

for actual sites that are ACF heavy this is literally just more work now for clients having to work in the backend, as already stated a simply mousewheel scroll worked just fine before, now there is a contant drag and drop, to position to a level where 99% of the content being worked on is in the correct position, in fact for one client they only has the page title as anything default wordpress, so its just a loss of workable space and finicky alterations on pages. Really not sure where the people who saw this as "must have" essential feature are . i hope they are making using of it at least now

I think I understand where folks that don’t like this are coming from. I’ve made a simple plugin that will minimize and maximize the meta box pane when scrolling via wheel gestures. If the post content is scrolled to the end it maximizes the meta box pane. If the meta box pane is scrolled to the start it minimizes the meta box pane. It works well in my limited testing. If anyone tries it and wants to leave feedback, please do so with an issue in the plugin’s repo. I think it might be a big improvement for some folks. Still, I hope WordPress can ship an update that would obviate any use for it.

This is a terrible idea. Please revert.

I opened an issue about this ( #63298 ) but was told to comment here instead.

I use 6.8, Twenty Twenty Five as a base theme and custom fields created with Pods Framework.

Maybe I just have to get used to it, but this new layout (content in its own scrolling frame and then meta stuff in a second scrolling frame) is terrible. Instead of quickly scrolling the entire Content+Meta stacked window in one quick action like it used to be (I use the mousewheel) now I have to move the mouse pointer to the window control, click, drag it up and then scroll inside the meta window. Then if I want to go back to editing Post content, I have to do the reverse, shrink down the Meta box area to expand the content editing area. And so on back n forth! This is terrible usability and I don't know why the developers above are so happy about it.

Please revert or provide an option to choose between the one window vs two. :(

They won't revert. They never do. You know, it being a pro-bono thing and all. It's similar to the open link in a new tab issue where we went from being able to do so in 2 clicks to needing 6 clicks now. We have simply had to move on...

They won't revert. They never do. You know, it being a pro-bono thing and all. It's similar to the open link in a new tab issue where we went from being able to do so in 2 clicks to needing 6 clicks now. We have simply had to move on...

Those kinds of changes are mindboggling. It still annoys me all the new -- and pointless -- hoops we have to jump through.

Two key statements jump out here:

First, do you guys actually use WordPress to produce content. Because some of the features that you introduce, it's like you just work on WordPress while using Joomla for your work.

Please, stop changing things that are working fine. And if you must make changes, make them optional.

It really is super annoying to have all these pointless changes add to how much work we have to do. You are driving people off Wordpress with these needless aggravations.

@TapiwaZvaks Could you submit a new issue with your thoughts? For features that have already been merged, it's best to discuss them in a new issue, where we can discuss how it could be improved.

That would be pointless. You have pushed back on user suggestions elsewhere.

There is a lot of good feedback here, thanks everyone who has contributed to this discussion in a professional manner.

Please remember to stay respectful and professional in your discussions here. The WordPress Community Code of Conduct states:

Examples of behavior that contributes to a positive environment for our community include:

• Demonstrating empathy and kindness toward other people
• Being respectful of differing opinions, viewpoints, and experiences
• Giving and gracefully accepting constructive feedback
• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
• Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

• The use of sexualized language or imagery, and sexual attention or advances of any kind
• Insulting or derogatory comments, taunting or baiting, and personal or political attacks
• Public or private harassment
• Publishing others’ private information, such as a physical or email address, without their explicit permission
• Publishing private messages without consent (an exception to this would be sending private messages to the Incident Response Team as part of an investigation)
• Other conduct which could reasonably be considered inappropriate in a professional setting

@aaronjorbin In fairness, you will get strong opinions when you interfere with our ability to do our jobs. I don't know how these development communities work exactly but I suggest you include users more in the testing phase. Had people seen that split screen in advance, they would have warned you about it.
I am fairly new here and it is also annoying to see that the suggestion to revert the "open link in new tab" change has not been fixed. Again, that is something speaking with an actual user could have avoided.
It is pride that prevents you from correcting these errors?

This change is really annoying and makes the workflow much slower.

Now we have to drag up the bottom box every time to use it, instead of just scrolling down.

Can this be made an option instead of a forced layout change?

At first, I was quite annoyed by this design decision, and followed the recommendation of @aaronjorbin to add comments here. Now looking at all the considerations and code changes that were involved makes the changes at least understandable. Nevertheless, it is painful if , for example, multiple or long ACF fields are involved, and that is something that may be quite common for other plugins with metaboxes, too.
Quite a lot of css-only and css-/js- hacks can already be found in the wild. Given the complexity of this change, these hacks may break things unknowingly, so how about creating a sustainable official recommended CSS "hack" that can be added with a filter action like admin_enqueue_scripts ?

I guess I'm in the minority of actually liking this new feature — mainly, liking the fact that the meta boxes are accessible at all times, instead of having to scroll down to the bottom of a long page, especially since ACF fields can't be placed above the content in the Block Editor. That said, I agree with everyone who is saying this should be an optional setting.

But the real reason I'm commenting is for a sanity check: I am working on several sites right now, all running 6.8.1, and only one of them has the drag/resize bar. I can't for the life of me figure out why the one site has it and the rest don't, even though they're all on the same version. Is it a setting somewhere now?

@room34 It depends on the theme / the pugins you use on the site.

With the revert that shipped in 6.8.1 it now behaves like it did in 6.7 where the resize UI only shows if you are using a block theme and all of the blocks you use on the site use API Version 3

@fabiankaegy Yeah, that's what I thought, but I do have a site running 6.8.1 that is still showing it. I even reinstalled core on that site, with no change.

Edit: Might be a plugin… testing now to pinpoint. Thanks.

Edit 2: It's a plugin in the sense that it only appears when a plugin is generating meta boxes, but I tested it with two plugins (Advanced Custom Fields and The SEO Framework) on two different sites. With both plugins (activated individually), the site that's been showing the drag bar shows it, while a site that isn't showing the drag bar exhibits the 6.7 behavior.

@fabiankaegy I don't think I'm going to investigate any further, but I just remembered, this site that is exhibiting the odd behavior has also had issues with other Block Editor updates in the past, because it is a really old WP installation (circa 2007). If the reversion of this feature involves anything in the database, it's possible that's the reason.

I would like to thank everyone who worked on the reversion.

I wish to add my opinion that I find this feature incredibly annoying. It involves extra steps and clicks rather than just scrolling to the point on the page I wish to edit.

Fortunately, and I have no idea why, it doesn't seem to have installed itself on any of my existing sites that have upgraded to 6.8, only ones that I have initially set up with WP 6.8.

Can we please have an option to turn this off? I cannot picture a scenario in which anyone would find this useful, especially if they use a trackpad/mouse to scroll to the part of the page they want to edit.