#23240 closed defect (bug) (fixed)
#post-body-content gap with one custom metabox
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.6 | Priority: | normal |
Severity: | minor | Version: | 3.5 |
Component: | Administration | Keywords: | |
Focuses: | ui | Cc: |
Description
Gap before metabox when post type does not support title and editor, the #post-body-content div is empty but has a 20px margin which makes any next metabox unaligned. Probably shouldn't be displayed at all.
add_action( 'init', function() { register_post_type( 'test', array( 'supports' => array( 'nothing' ), 'public' => true ) ); } ); add_action( 'add_meta_boxes', function() { add_meta_box( 'edit-ui', 'Test UI', function() { echo '<p>Feeling a bit too heavy...</p>'; }, 'test', 'normal', 'core' ); } );
Attached image shows it all, highlighting parts in yellow.
Attachments (9)
Change History (28)
#4
@
12 years ago
- Component changed from Post Types to Administration
- Keywords ui-focus needs-patch added
- Milestone changed from Awaiting Review to 3.6
Hmm, that's my fault. Should probably look at doing better margins/markup all around on the edit screen so that adding stuff using the edit_form_after_* hooks works without extra styling or wrappers but we don't get any funny gaps when something isn't shown.
@
12 years ago
Altered #post-body-content styles to affect the TinyMCE Editor container (#postdivrich)
#7
@
12 years ago
wp-admin.css.patch is not quite correct, as the attachment compat fields are not within the TinyMCE div.
I'm still hoping to find a solution that allows people to utilize the edit form hooks without having to add extra CSS or markup of their own to achieve sane spacing. Happy to have somebody else take a stab; looking at it myself in the meantime.
#10
@
12 years ago
23240.diff is a starting point for what I was thinking about a more generic solution - using a class of .edit-form-section
to give better HTML structure and that pesky bottom margin to pieces of the edit screen that need it. Then it can also better accommodate custom additions on the edit_form_after_*
hooks by adding a wrapping div with said class if has_action()
.
Patch really is only a starting point - edit_form_after_editor
would need the same treatment, and the class would probably need to be applied to a few existing elements in edit-form-advanced.php
. And, of course, testing.
#11
@
12 years ago
- Owner set to helen
- Resolution set to fixed
- Status changed from new to closed
In 23615:
#12
follow-up:
↓ 13
@
12 years ago
Nope, my test above has still got the same results.
add_action( 'init', function() { register_post_type( 'test', array( 'supports' => array( 'nothing' ), 'public' => true ) ); } ); add_action( 'add_meta_boxes', function() { add_meta_box( 'edit-ui', 'Test UI', function() { echo '<p>Feeling a bit too heavy...</p>'; }, 'test', 'normal', 'core' ); } );
Is there something I'm missing?
(At revision 23615)
#13
in reply to:
↑ 12
;
follow-up:
↓ 14
@
12 years ago
Replying to soulseekah:
Nope, my test above has still got the same results.
Could not reproduce in Firefox 19. Do you have SCRIPT_DEBUG
enabled?
#14
in reply to:
↑ 13
@
12 years ago
Replying to SergeyBiryukov:
Could not reproduce in Firefox 19. Do you have
SCRIPT_DEBUG
enabled?
No, my apologies, completely forgot about it.
Looks good, thank you, helen.
#15
@
12 years ago
- Cc Ken@… added
I have a concern about this commit. What happens to code if a plugin developer was using the hooks to add a wrapper div around the editor? (Open <div class="wrap"> on 'edit_form_after_title' and closing </div> on 'edit_form_after_editor') It'd break the html in bad ways. I don't know if anyone has code in the wild doing this but I (temporarily) did this on a client's site for 3.5.1 (but went with dropping the editor on that particular case).
Can't seem to reproduce in 3.4.2 and below.