WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#28511 closed enhancement (wontfix)

Wp-admin #wpwrap hooks

Reported by: evandentremont Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9.1
Component: General Keywords:
Focuses: ui, administration, template Cc:

Description (last modified by SergeyBiryukov)

A header and footer to the back end has been required twice in the last month in my office. While researching this, I came across multiple threads on Stack Exchange, etc. but none had a real solution.

Turns out there is no hook to do so.

On a development site, I added

<?php do_action( 'pre_admin_header' ); ?>
<div style="position:relative;">

to admin-header.php; right after <div id="wpwrap"> and

</div>
<?php do_action( 'post_admin_footer' ); ?>

to admin-footer.php. right before <!-- wpwrap --> </div>

It functions as expected, all positioning is correct within the wrapper.

Some concern was raised in #wordpress-dev about maintainability, but realistically, I can't see this being an issue to support or maintain. As it is, #wpwrap is simply a wrapper for the rest of the admin. Adding an additonal div before and after the admin is output shouldn't break that, and realistically could be moved without issue if the structure of the backend changes.

Change History (10)

This ticket was mentioned in IRC in #wordpress-dev by iamepic. View the logs.


6 years ago

#2 follow-up: @ocean90
6 years ago

  • Keywords reporter-feedback added
  • Type changed from feature request to enhancement

Can you please provide some use cases/code examples for these hooks?

#3 @SergeyBiryukov
6 years ago

  • Description modified (diff)

#4 in reply to: ↑ 2 @evandentremont
6 years ago

Replying to ocean90:

Can you please provide some use cases/code examples for these hooks?

The use case that comes up internally was to keep client branding on the admin page for contributors.

This is an example stack overflow question http://wordpress.stackexchange.com/questions/51023/add-header-and-footer-to-wp-backend

I invoked it like this.

Header.php is everything until and including <body> then <?php include("headerbody.php") ?> same idea with the footer

<?php 

// enqueue_stylesheets includes all the stylesheets on front end


function theme_header(){
  include('headerbody.php');
}

function theme_footer(){
  include('footerbody.php'); 
}

if( current_user_can( 'subscriber' ) ){
  add_action("pre_admin_header", "theme_header", 1);
  add_action( 'admin_head', 'enqueue_stylesheets' );
  add_action("post_admin_footer", "theme_footer", 1);
} // only if subscriber


?>

#5 @evandentremont
6 years ago

  • Keywords reporter-feedback removed

#6 follow-up: @helen
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I strongly believe that with the ever-increasing percentage of sites using WordPress and thus users being familiar with the interface, it is best for the WordPress admin itself to remain fairly consistent even between different installations. I am also disinclined to take on the burden of maintaining such hooks now and into the future.

#7 in reply to: ↑ 6 ; follow-up: @evandentremont
6 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to helen:

I strongly believe that with the ever-increasing percentage of sites using WordPress and thus users being familiar with the interface, it is best for the WordPress admin itself to remain fairly consistent even between different installations. I am also disinclined to take on the burden of maintaining such hooks now and into the future.

Perhaps I don't understand as a newcomer to this side of things, but how can that be a "burden"?

For that matter, how is it any harder to maintain than do_action( 'in_admin_header' );? It allows nearly the same thing, but over the sidebar rather than within it.

If the admin interface needs to remain "consistent" why was theming introduced at all?

What I'm proposing doesn't change the interface; it adds a line of branding above it. Which, realistically is necessary and requested by a lot of our clients. Again, I've see this requested many a time on stackexchange.

Not adding them basically leaves two options:
1) Do it manually, having people using modified core files.
2) Prepend it with jQuery, which; while it works, isn't really the best solution.

#8 in reply to: ↑ 7 ; follow-up: @helen
6 years ago

Replying to evandentremont:

Perhaps I don't understand as a newcomer to this side of things, but how can that be a "burden"?

We strive to maintain backwards compatibility. Hooks are low-cost to add, and often remain low-cost to maintain, but it is still maintenance. My particular concern here is that you would be disconnecting the toolbar from the admin menu, which are currently visually coupled together. I would also be quite surprised if this played nicely with the sticky admin menu or smaller screen responsive considerations.

If the admin interface needs to remain "consistent" why was theming introduced at all?

Not sure what you mean here. There are color schemes, but those do not affect layout.

#9 in reply to: ↑ 8 @evandentremont
6 years ago

Replying to helen:

Replying to evandentremont:

Perhaps I don't understand as a newcomer to this side of things, but how can that be a "burden"?

We strive to maintain backwards compatibility. Hooks are low-cost to add, and often remain low-cost to maintain, but it is still maintenance. My particular concern here is that you would be disconnecting the toolbar from the admin menu, which are currently visually coupled together. I would also be quite surprised if this played nicely with the sticky admin menu or smaller screen responsive considerations.

It does play nice with the sticky menu as that uses padding on top of <html>, though granted it does split the sticky menu from the sidebar.

I guess this comes back around to, do wordpress dev's tell the user what they want, or do users tell wordpress dev's what they want.

I have to implement this either way, but where I've seen references to it before I can't be the only one that needs it.

Edit: One thing I'd like to add, obviously any layout issues would be the responsibility of the developer writing a plugin or theme that takes advantage of the hook. As far as backwards compatibility, it seems any admin layout would continue to use some form of #wpwrap.

If the admin interface needs to remain "consistent" why was theming introduced at all?

Not sure what you mean here. There are color schemes, but those do not affect layout.

I meant color, just referencing that of the "look and feel", the "look" is by design inconsistent.

Last edited 6 years ago by evandentremont (previous) (diff)

#10 @ocean90
6 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

What helen says, plus the question from Stack Overflow isn't something that confirms the need of such hooks, quite the reverse.

Note: See TracTickets for help on using tickets.