#41235 closed enhancement (wontfix)
New load_screen_** action
Reported by: | aussieguy123 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.9 |
Component: | General | Keywords: | |
Focuses: | Cc: |
Description
WordPress includes a load-<page> hook, however this is not specific enough to have a function that runs only on one single screen in the admin area without additional logic. Lets say I have a custom post type "killed_attachment" and I want to have a function which will only run on the edit posts screen for this post type.
My proposed solution:
<?php /** * Fire load_screen_* hooks * @action admin_init (or a better action, suggestions?) */ public function run_load_screen_hooks() { $current_screen = function_exists( 'get_current_screen' ) ? get_current_screen()->id : null; do_action('load_screen_' . $current_screen); }
With this new action, instead of requiring logic to detect the screen as in:
<?php /** * @action admin_init */ public function run_on_killed_attachments_edit_post_only() { $current_screen = function_exists( 'get_current_screen' ) ? get_current_screen()->id : null; switch ( $current_screen ) { case 'edit-killed_attachment': //Code which will only run on the killed attachment edit posts screen break; default: break; } }
You could simplify this as:
<?php /** * @action load_screen_edit-killed_attachment */ public function admin_enqueue_scripts() { //Code which will only run on the killed attachment edit posts screen }
Basically both functions do the same thing but one is 9 lines long and contains extra logic, the other is one line long.
Shorter functions and less logic means less bugs and more readable + maintainable code.
Change History (6)
#2
@
7 years ago
Yes. I saw the existing current_screen
hook. However that would also need extra logic in code hooked into it to have code run on a specific screen. So this is a new load_screen_{$screen_id}
action
Perhaps the code to set up this new action could be hooked into the existing current_screen
action?
Something like:
<?php add_action( 'current_screen', function() { $current_screen = function_exists( 'get_current_screen' ) ? get_current_screen()->id : null; do_action('load_screen_' . $current_screen); });
#4
@
7 years ago
Looking at your examples, I'm not really sure what the advantage to a new dynamic hook would be other than making what is already pretty straightforward with current_screen
slightly more specific.
As pointed out, the existing current_screen
hook could be used for what you want, and the screen object is passed to it:
<?php add_action( 'current_screen', function( $screen ) { if ( isset( $screen->id ) && 'killed_attachment' === $screen->id ) { // Do stuff. } } );
#5
@
7 years ago
@DrewAPicture the idea of the action is to avoid the need for the if statement (or other logic)
This is similar to how alot of MVW style frameworks work, instead of using an if statement to detect a page they would use something else (like a route or action) to hook into the page directly.
With the screen passed to current_screen, the code to set up this new action could be as simple as:
<?php add_action( 'current_screen', function( $screen ) { do_action('load_screen_'.$screen->id); });
#6
@
7 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
@aussieguy123 I understand your use case – I'm saying that don't think that reason alone is adequate justification for adding a new dynamic hook in this context.
Thank for you the suggestion and your willingness to make your case, however, I'm going to close this ticket was wontfix. If a greater need for such a hook should arise in the future, we can certainly reopen this ticket to revisit it.
@aussieguy123 thanks for the ticket. There is actually a current_screen action that currently triggers. It seems like you're essentially suggesting a
current_screen_{$screen_id}
action?