Welcome to the WordPress jungle.

WordPress loading sequence: the wp-admin edition

Welcome to another instalment of my WordPress Jungle tours through the backwaters of WP.

This article builds upon my previous walkthrough of the WordPress loading process. If you log into the admin, the address is yoursite.com/wp-admin. That URL doesn’t do an .htaccess redirect, you actually load theindex.php in the wp-admin folder.


The first thing it does, is load wp-admin/admin.php — This is the file that bootstraps the admin. It sets up a few constants to let the rest of the system know you are in the admin. Then, it loads up our trusty wp-load.php, which loads wp-config, which loads wp-settings.phpand boots up the entire WordPress application. (see the previous article for more details on how this works).

The big difference is that admin.php doesn’t start the wp object to populate a query and it doesn’t use the template loader from the front end. So let’s go through admin.php for the rest of this article.


WordPress now makes sure your browser doesn’t load a cached version of the admin page.

It also checks if a database upgrade has been done (or you are in the middle of upgrading multisite). You get a few hooks and filters here to interact with the process.


At this point the ‘normal’ part of the WordPress application has already loaded (through wp-settings.php). Admin now loads extra files with all the specific admin functions and classes. This happens in wp-admin/includes/admin.php


After loading all the extra function files, we’re back in wp-admin/wp-admin.php! auth-redirect() is a pluggable function that checks if the user is logged in. If not, he is redirected to a log in screen. Bonus tip: you can add this function to your own templates for a quick and dirty protected page type.


This function is run through WordPress Cron and checks if there are posts that are in your trash for longer than the maximum time you have set. If so, it permanently deletes them.


This function saves the options you set in the ‘screen options’ drop down at the top of admin screens. These options are stored in the usermeta table.

WordPress then loads the date and time format from wp_options. You set these values in your admin (Settings > General).


WordPress now enqueues wp-admin/js/common.js, which is responsible for things like displaying tables, validating forms,…


The editing variable is set to false here. If you are in post.php or post-new.php, it is set to true. These are set to edit/create any kind of post type.
I have not found any other reference for the $editing reference. I guess it is only there for plugins to check.


Next, a few variables are set to determine which admin screen is loaded.

If the selected admin page was added through a plugin, the URL-variable is saved in $plugin_page.

If you are editing or adding a post type (other than the default: post), it’s post type is saved in $typenow.

A last URL variable which is checked and saved is taxonomy. You get this if you open a taxonomy overview or if you are editing one. It is saved into $taxnow.


Most pages then just load wp-admin/menu.php. Two special cases (multisite and a user editing his profile) load a different menu file (which then at the end requires wp-admin/menu.php).

wp-admin/menu.php builds a big menu array and at the end, it requires wp-admin/includes/menu.php.

That last file provides extra filters and hooks and filters to customize the menu before it is output to the browser.


WordPress now checks if you are an admin (current_user_can). If so, the PHP memory limit is increased temporarily. This may be necessary for certain admin scripts. You also get a filter here which you can use from you plugin to override the constant.


You now get the admin_init hook. It is comparable to the init hook (from the regular loading sequence). The admin loading process is over and all extra admin functions are available.


If the page we want to access was added through a plugin, WordPress will now create a custom hook for it: $page_hook.

If you need a quick and (very) dirty way of seeying your current $page_hook, you could addthis snippet in your functions.php.

The $hook_suffix variable is used to create extra hooks throughout the admin files. For instance in admin-footer.php and admin-header.php


WordPress will now store a WP_Screen object in $current_screen. The properties for this object are calculated (in the get method of WP_Screen) based on the $hook_suffix variable (see above).

The object in $current_screen will also let you interact with things like the help tabs.


If the admin page you are trying to view is a page added by a plugin, you now get a load-$page_hook action and a $page_hook action you can call. In the comments here, you’ll also see how the $page_hook is calculated.


Another special case is when you are importing. WordPress checks if you are calling a proper importer (among other things).


One of the last hooks in this bootstrap file: load-$pagenow. As you see from the if-else statements, this will only fire if it is not a page created by a plugin (those have the $page_hook).


If your page provides an action value in $_REQUEST, you can hook into it with add_action(‘admin_action_youraction’, ‘yourfunction’);


After loading wp-admin/admin.php, you have to look into the requested admin file. There you’ll see how it works (unless it is a plugin page, which is handled in admin.php, as we have seen).

The dashboard (wp-admin/index.php), for instance, loads the dashboard widgets and sets up help tabs (through WP_Screen).

I plan on going through a selected range of admin pages in future articles.

What most have in common, though, is that they call wp-admin/admin-header.php and wp-admin/admin-footer.php

Those two files will probably be a subject of my next article.