WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 17 months ago

#19658 closed enhancement (fixed)

action hooks for after_title and after_editor needed to utiliize wp_editor

Reported by: stonefree Owned by: 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 2 years ago.
screen shot demonstrating awkward layout
empty-normal-sortables-gap.png (47.9 KB) - added by trepmal 2 years ago.
19658.diff (399 bytes) - added by helenyhou 18 months ago.
edit-form-advanced.php.patch (376 bytes) - added by logikal16 18 months ago.

Download all attachments as: .zip

Change History (27)

stonefree2 years ago

screen shot demonstrating awkward layout

comment:1 follow-up: trepmal2 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)

comment:2 stonefree2 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'.

comment:3 in reply to: ↑ 1 azaozz2 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.

comment:4 trepmal2 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!

comment:5 wpsmith2 years ago

  • Cc travis@… added

comment:6 nacin21 months ago

  • Milestone changed from Awaiting Review to 3.5

We may need this for #21391.

comment:7 markoheijnen21 months ago

Closed #19358 as duplicate

comment:8 helenyhou21 months ago

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

comment:9 sc0ttkclark21 months ago

  • Cc lol@… added

comment:10 nacin19 months ago

  • Component changed from General to Post Types

comment:11 goto1019 months ago

  • Cc dromsey@… added

comment:12 follow-up: nacin19 months 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.

comment:13 nacin19 months ago

  • Keywords punt added

comment:14 in reply to: ↑ 12 helenyhou19 months 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.

comment:15 sc0ttkclark19 months 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.

comment:16 markoheijnen19 months 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

comment:17 taylorde18 months 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')

helenyhou18 months ago

comment:18 helenyhou18 months 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 :)

comment:19 SergeyBiryukov18 months ago

#22278 was marked as a duplicate.

comment:20 logikal1618 months ago

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

comment:21 logikal1618 months 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.

comment:22 markoheijnen18 months 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.

comment:23 nacin17 months 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.