WordPress.org

Make WordPress Core

Opened 14 months ago

Closed 12 months ago

Last modified 12 months ago

#24334 closed enhancement (fixed)

"edit_form_after_title" and "edit_form_after_editor" hooks wrapper optional?

Reported by: lemmonaid Owned by: helen
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.6
Component: Administration Keywords:
Focuses: ui Cc:

Description

Would it be possible to make the DIV.edit-form-section wrapper applied around edit_form_after_title and edit_form_after_editor hooks in post/page edit screen optional in WP3.6? Or create additional non-wrapped hooks besides?

http://core.trac.wordpress.org/browser/trunk/wp-admin/edit-form-advanced.php#L462
http://core.trac.wordpress.org/browser/trunk/wp-admin/edit-form-advanced.php#L502

These wrappers were actually introduced in WP3.6, the WP3.5 version was without them.

Explanation of what I do:

  • edit_form_after_title hook - I output UL list of tabbed interface here and open the first tab content DIV
  • edit_form_after_editor hook - I close the first tab content DIV and output the other tab content DIVs

The first content DIV is always a visual editor. But as you can see, when I open the DIV in one hook and closing it in another one, this was working fine in WP3.5 as no wrapper was added to those hooks. Once there is a wrapper, it obviously messes up the HTML and closes divs prematurely. This is causing issues obviously for tabbed interface.

Screenshot: http://awesomescreenshot.com/09915rzc37
Ticket started on Alpha/Beta support forum: http://wordpress.org/support/topic/wrapper-of-edit_form_after_title-and-edit_form_after_editor-hooks-optional

Thank you!

Attachments (1)

edit_form_after_editor.24334.diff (864 bytes) - added by wycks 12 months ago.

Download all attachments as: .zip

Change History (13)

comment:1 SergeyBiryukov14 months ago

Introduced in [23615].

comment:2 lemmonaid14 months ago

Thanks for answer, but I need the exact oposite. I would like to remove the wrapper DIV.

I have nothing against it, just I would like it to be optional (applied by default). So if someone like me don't want to have the code inside the wrapper, he can disable it or use other non-wrapper hook.

comment:3 SergeyBiryukov14 months ago

  • Keywords ui-focus added

It was just a reference to the changeset where the wrapper divs were added, for context.

comment:4 wycks12 months ago

This removed the wrapper div and instead put the hook into the container. It seems to do the same thing.

Version 0, edited 12 months ago by wycks (next)

comment:5 nacin12 months ago

Could you provide a use case where removing the wrapper is absolutely required? As of right now this is probably a wontfix/worksforme.

comment:6 wycks12 months ago

The only reason I can think of is if a user does not update WordPress, if a plugin/themes is using the filter pre [23615], or in the case of lemmonaid 's reason for this ticket.

It seems a bit redundant to have a hardcoded div right above a container which already works in the same context and has been there a long while.

It's probably a worksforme though since I created the patch for 3.5 not knowing it had already been fixed.

comment:7 lemmonaid12 months ago

Thanks for looking at this ticket guys.

I've actually provided a use case in my initial explanation. You can have a look at the screenshot: http://awesomescreenshot.com/09915rzc37

I understand this is more of a special case request. I was just pleased to see the hooks in WP3.5 so I could finally make the user interface like the one from screenshot. Unfortunately, I have to ban it for WP3.6 due to the wrapper DIV being applied (it breaks my HTML tabs wrapper, so tabs won't work).

comment:8 lemmonaid12 months ago

As of the wycks' fix, this won't help me actually ;) I really just need to get rid of those wrapper DIVs added in WP3.6 to the hooks. Their position is perfect.

comment:9 helen12 months ago

I don't know about the conditional wrappers anymore. I really want the edit screen to have better structure, and I think of those hooks as being used to add sections to the edit form, but as always, there are other uses to be found. Maybe it's good enough that a class for .edit-form-section has been added and people can use the wrapper div or other container themselves to semi-easily get the appropriate spacing.

comment:10 helen12 months ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Awaiting Review to 3.6

Yeah, going to just remove the wrappers.

comment:11 helen12 months ago

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

In 24586:

Remove the conditional wrappers for the edit_form_after_* hooks. Using the .edit-form-section class will still add a 20px bottom margin; devs will just want to add wrapping containers as appropriate. fixes #24334; see #23240.

comment:12 lemmonaid12 months ago

I love you! :) This is exactly what I wanted. This way the developers can apply an .edit-form-section class themselves whenever needed, while it stays out when not in need (as in my case).

Note: See TracTickets for help on using tickets.