Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#19658 closed enhancement (fixed)

action hooks for after_title and after_editor needed to utiliize wp_editor

Reported by: stonefree's profile stonefree Owned by: nacin's profile nacin
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.3
Component: Posts, Post Types Keywords: punt has-patch
Focuses: Cc:

Description

I was pretty excited about the new wp_editor function, but the current hooks make it difficult to utilize. TinyMCE is problematic inside meta_boxes, but "edit_form_advanced' and 'dbx_post_sidebar' are not ideal alternatives because they output content after meta boxes, including comments box. Ideally all form fields should be at the top. It looks awkward otherwise, especially for clients. I have attached a picture to demonstrate.

I am proposing the following additions to edit-form-advanced.php

do_action ( 'after_title' ); //line 316, after the title div
do_action ( 'after_editor ' ); //line 340 , after the editor div

The after_title would be helpful as a way to label what content to put in the standard editor for CPTs.

Attachments (4)

Screen shot 2011-12-24 at 12.39.31 AM.png (238.1 KB) - added by stonefree 12 years ago.
screen shot demonstrating awkward layout
empty-normal-sortables-gap.png (47.9 KB) - added by trepmal 12 years ago.
19658.diff (399 bytes) - added by helenyhou 11 years ago.
edit-form-advanced.php.patch (376 bytes) - added by logikal16 11 years ago.

Download all attachments as: .zip

Change History (27)

@stonefree
12 years ago

screen shot demonstrating awkward layout

#1 follow-up: @trepmal
12 years ago

I've been meaning to write up a ticket like this to see what the core devs think.

I really like the idea of being able to place a secondary editor just below the primary, but there are some issues with that currently.

  1. There's an area above do_action( 'edit_form_advanced' ) (normal sortables) that could already be filled with other boxes, which would push the secondary editor down the page
  2. Even if the normal sortables area is empty, such as on a brand new install, the min-height on it creates an awkward gap (screenshot forthcoming)

#2 @stonefree
12 years ago

Hi trepmal, thanks for the comment. The normal sortables area you're referring to is caused by 'do_meta_boxes' , which is the source of problems for me too. My proposed do_action ( 'after_editor ' ); would fix that since it occurs before 'do_meta_boxes'.

#3 in reply to: ↑ 1 @azaozz
12 years ago

As far as I know the idea was to make the Edit/Write screen fully "pluggable" to accommodate CPTs, so adding these actions seems good.

On the other hand we can introduce non-movable metaboxes where MCE can be used. Was testing that yesterday and it seems to work properly. As long as the editor's iframe parent nodes are not changed (all parents, the whole DOM branch), MCE seems to work properly. There is a little "quirkiness" when more than one metabox is not movable but think that's acceptable.

Replying to trepmal:

The 50px height is needed so metaboxes can be dragged there. Without it you won't be able to add a metabox when the container is empty.

#4 @trepmal
12 years ago

I understand that the min-height is required so the empty container can receive dragged items. I only meant to show that somehow forcing meta boxes out of that container isn't a pretty solution.

Basically, +1 for more hooks!

#5 @wpsmith
12 years ago

  • Cc travis@… added

#6 @nacin
12 years ago

  • Milestone changed from Awaiting Review to 3.5

We may need this for #21391.

#7 @markoheijnen
12 years ago

Closed #19358 as duplicate

#8 @helenyhou
12 years ago

For reference, #19358 was about a hook below the screen title h2/above the title field. Moar hooks!

#9 @sc0ttkclark
12 years ago

  • Cc lol@… added

#10 @nacin
12 years ago

  • Component changed from General to Post Types

#11 @goto10
12 years ago

  • Cc dromsey@… added

#12 follow-up: @nacin
11 years ago

edit_form_after_title was added in #21391.

Before the title is a bit weird, and *really* disrupts the hierarchy of the page. If you don't want a giant title field at the top, then disable it.

After the editor, well, we have the normal and advanced sortables by then, with the edit_form_advanced hook in between them.

#13 @nacin
11 years ago

  • Keywords punt added

#14 in reply to: ↑ 12 @helenyhou
11 years ago

Replying to nacin:

After the editor, well, we have the normal and advanced sortables by then, with the edit_form_advanced hook in between them.

That's what's weird, though - since the use case I've seen is for non-sortables, it makes more sense to have something between the editor and any sortable areas.

#15 @sc0ttkclark
11 years ago

This has another use, but might be different from the original poster's intent.

Currently, the plugin Tabify Edit Screen has to use jQuery to move it's HTML up, but if this filter were in place it could simply just hook into it for output.

http://wordpress.org/extend/plugins/tabify-edit-screen/screenshots/

I just wanted to make sure that use-case was taken into consideration here. Tabify is a life saver for large sites with lots of meta boxes.

#16 @markoheijnen
11 years ago

That was the use case I described at #19358 and probably shouldn't close as duplicate as what Helen also described at comment 8

#17 @taylorde
11 years ago

  • Cc td@… added

Adding a +1 for a hook after the editor, before any sortables. I'm increasingly modifying the edit screen for custom post types to get the perfect UI for whatever content is being worked on. While removing the editor and adding it back in order to get the right flow is possible, a single hook would make that less workaroundy.

As recap, Implementing helenyhou's idea of a hook after the main editor would bring us to this:

  • After the title, before the main editor ('edit_form_after_title')
  • After the main editor, before the normal sortables (e.g. 'edit_form_normal')
  • After the normal sortables, before the advanced sortables ('edit_form_advanced')

@helenyhou
11 years ago

#18 @helenyhou
11 years ago

  • Keywords has-patch added

19658.diff adds edit_form_after_editor to parallel edit_form_after_title, which now exists. Would still love this in 3.5 and close this out nicely :)

#19 @SergeyBiryukov
11 years ago

#22278 was marked as a duplicate.

#20 @logikal16
11 years ago

+1 to helenyhou's patch for adding an edit_form_after_editor action.

#21 @logikal16
11 years ago

Patch modified to allow edit_form_after_editor hook even for posts without editor support. This would allow for consistent placement of custom content.

#22 @markoheijnen
11 years ago

Hey logikal16, Helen's patch does work when a post type doesn't have editor support. It just it's still in the post-body-content and that doesn't really matter that much for now. Maybe later.

#23 @nacin
11 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 22446:

edit_form_after_editor action. props helenyhou. fixes #19658.

Note: See TracTickets for help on using tickets.