Opened 8 years ago
Closed 6 years ago
#37790 closed defect (bug) (wontfix)
Post editing sidebar does not always act sticky
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.6 |
Component: | Editor | Keywords: | has-patch |
Focuses: | Cc: |
Description
Situation 1 (works fine)
- Go to the new post page (
/wp-admin/post-new.php
). - Paste enough lorem ipsum into the visual editor that the page is able to scroll.
- Scroll down.
Expected and actual behaviour:
#side-sortables
gets position: fixed
and sticks to the viewport as you scroll down the page
Situation 2 (does not work)
- Add metaboxes to the post type (enough so that the page will scroll - ACF is an easy way to do this, or you could just install a bunch of plugins, or manually create the metaboxes).
- Go to the new post page.
- Scroll down.
(Make sure your viewport is taller than the editor).
Expected behaviour:
Just like the other situation, #side-sortables
should get position: fixed
and stick to the viewport as you scroll down the page.
Actual behaviour:
Nothing happens to #side-sortables
and the sidebar does not follow the viewport as the user scrolls.
This happens because in wp-admin/js/editor-expand.js
it compares the height of the editor against the height of the viewport.
// Sidebar pinning if ( $postboxContainer.width() < 300 && heights.windowWidth > 600 && // sidebar position is changed with @media from CSS, make sure it is on the side $document.height() > ( $sideSortables.height() + postBodyTop + 120 ) && // the sidebar is not the tallest element heights.windowHeight < editorHeight ) { // the editor is taller than the viewport
It should compare the height of the whole page instead. i.e.:
heights.windowHeight < $('#poststuff').outerHeight() ) { // the page content is taller than the viewport
Attached a diff (make sure to do define('SCRIPT_DEBUG', true);
when using this diff as I didn't recompile the JS).
Attachments (1)
Change History (8)
#6
@
7 years ago
FWIW this patch is a very welcome change and appears to fix the problem described in situation 2.
I ended up needed this for a production site and had to deregister editor-expand
in favour of this patched version.
#7
@
6 years ago
- Keywords needs-testing 4.9-early removed
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
I am going to close this out as a wontfix
. The new block editor has redesigned the edit screen and the Classic Editor is being preserved as is, with the exception of major bugs.
Thanks for the patch!
That's not needed for patches anyway, as the JavaScript gets minified during the build process.