Opened 11 years ago
Closed 11 years ago
#28511 closed enhancement (wontfix)
Wp-admin #wpwrap hooks
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.9.1 |
Component: | General | Keywords: | |
Focuses: | ui, administration, template | Cc: |
Description (last modified by )
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.
11 years ago
#2
follow-up:
↓ 4
@
11 years ago
- Keywords reporter-feedback added
- Type changed from feature request to enhancement
#4
in reply to:
↑ 2
@
11 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 ?>
#6
follow-up:
↓ 7
@
11 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:
↓ 8
@
11 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:
↓ 9
@
11 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
@
11 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.
Can you please provide some use cases/code examples for these hooks?