Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#24334 closed enhancement (fixed)

"edit_form_after_title" and "edit_form_after_editor" hooks wrapper optional?

Reported by: lemmonaid's profile lemmonaid Owned by: helen's profile 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 11 years ago.

Download all attachments as: .zip

Change History (13)

#1 @SergeyBiryukov
11 years ago

Introduced in [23615].

#2 @lemmonaid
11 years 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.

#3 @SergeyBiryukov
11 years ago

  • Keywords ui-focus added

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

#4 @wycks
11 years ago

This removed the wrapper div and instead puts the hook into the container under the editor. It seems to do the same thing sans wrapper.

Last edited 11 years ago by wycks (previous) (diff)

#5 @nacin
11 years ago

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

#6 @wycks
11 years 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.

#7 @lemmonaid
11 years 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).

#8 @lemmonaid
11 years 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.

#9 @helen
11 years 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.

#10 @helen
11 years ago

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

Yeah, going to just remove the wrappers.

#11 @helen
11 years 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.

#12 @lemmonaid
11 years 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.