There’re a couple of variables can help us determining which admin screen we’re seeing: $pagenow
for current page ID, $typenow
for current post type, etc. But using these variables requires us a huge afford to combine them just to get the correct information we want. Fortunately, since version 3.3, WordPress gives us a more completed solution with WP_Screen
class which turns out the best way to get current admin screen information with ease of use.
Note: This topic is started by Kaiser at wp-hackers
email list. I’m writing it here and add some notes for quick reference for myself and for others who interested.
To get the current screen object, simply use:
$screen = get_current_screen();
This $screen
is an instance of WP_Screen
class, which has the following interesting public variables:
Available public variables of current admin screen object
1. $screen->id
: The unique ID of the screen.
2. $screen->base
: The base type of the screen. This is typically the same as $screen->id
but with any post types and taxonomies stripped.
For example, the base of post.php
or post-new.php
is post
for all post types.
3. $screen->action
: Any action associated with the screen.
add
for*-add.php
and*-new.php
screens.- Empty otherwise.
4. $screen->is_network
: Whether the screen is in the network admin.
5. $screen->is_user
: Whether the screen is in the user admin.
6. $screen->parent_file
: The parent file for the screen per the admin menu system.
Some $parent_file
values are edit.php?post_type=page
, edit.php
, and options-general.php
.
7. $screen->parent_base
: The base menu parent.
This is derived from $parent_file
by removing the query string and any .php
extension.
For example, $parent_file
values of edit.php?post_type=page
and edit.php?post_type=post
have a $parent_base
of edit
.
8. $screen->post_type
: The post type associated with the screen, if any.
For example:
- The
edit.php?post_type=page
screen has a post type ofpage
. - The
edit-tags.php?taxonomy=$taxonomy&post_type=page
screen has a post type ofpage
.
9. $screen->taxonomy
: The taxonomy associated with the screen, if any.
For example, the edit-tags.php?taxonomy=category
screen has a taxonomy of category
.
Enqueue scripts and styles for editing custom post type page only
We’ll see an example of screen object to do a very popular thing in WordPress: enqueuing scripts and styles for admin pages.
WordPress gives us a hook wp_enqueue_scripts
which has a parameter $hook_prefix
to determine the current admin screen. But this parameter can’t give us information about the current post type unless we use another variable $typenow
or check the $_GET
.
But everything is now easier with screen object:
add_action( 'admin_enqueue_scripts', 'rw_enqueue_scripts' );
/**
* Enqueue scripts and styles for editing page of 'slider' post type only
*
* @return void
*/
function rw_enqueue_scripts()
{
$screen = get_current_screen();
// Check screen base and current post type
if ( 'post' === $screen->base && 'slider' === $screen->post_type )
{
wp_enqueue_script( 'slider-options', get_stylesheet_directory_uri() . '/js/slider-option.js', array( 'jquery' ) );
// Enqueue other scripts and styles
}
}
Hi Rilwis,
so far I solved the whole thing (how to determine every screen, collect all of them and list them). When I get the plugin out into the wild, I’ll pingback to your post 🙂
That’s cool. I’m curious what you’re doing 😀
Just a heads up, but you want admin_enqueue_scripts to enqueue scripts on the admin side rather than wp_enqueue_scripts
Correct! Post updated. Thanks.
very helful!! thank you very much!!!