In my previous post on How WordPress Boots Up we went over half of the bootup process up to the point where WordPress wp-settings.php returns as a SHORTINIT’ed version, with the barebones of WordPress available, which, though an obscure feature, turns out to be quite useful for environments where only the very core WordPress features are required (especially the database abstraction). I encourage you to at least skim through part one, don’t worry we won’t leave without you.
With, hopefully everyone being up to speed now, let’s open up wp-settings.php in our favourite editor and continue our journey towards the WordPress response to our index request. The SHORTINIT test fails on line 96, so WordPress proceeds with loading everything else:
- The l10n library, the code of which defines a couple of dozen functions resides in wp-includes/l10n.php. Among these functions are the well-known
__()and_e()functions, which expose the power of translations throughout WordPress. wp_not_installed()(defined in wp-includes/load.php) makes use of theis_blog_installed()function (defined in wp-includes/functions.php). A redirect is forced if WordPress is not installed at this point. This is where we branch off into the famous 5-minute WordPress installation, which is out of the scope of this article.- 36 files are included, and we’ll quickly go over each one of them:
- wp-includes/class-wp-walker.php – defines the
Walker(no, not the Texas Ranger) class for displaying various tree-like structures. - wp-includes/class-wp-ajax-response.php – defines the
WP_Ajax_Responseclass, which returns XML responses to AJAX requests. - wp-includes/formatting.php – the main WordPress Formatting API. This file contains function definitions for escaping and sanitization functions, time conversion functions, validation functions, and other useful tools that are used within WordPress, so next time you’re writing a plugin and need a tag balancing function or URL escaping function check to see if the ones defined in this file can be used instead of writing your own.
- wp-includes/capabilities.php – defines 3 classes:
WP_Role,WP_Roles,WP_User. These combined expose the set of user and role management methods that WordPress makes use of when managing Users in your WordPress Dashboard, and in general when checking user permissions and restrictions. - wp-includes/query.php – defines functions that are part of the WordPress Query API, like
is_page(),is_404(), and theWP_Queryclass which is instantiated into the$wp_queryglobal object, which is used by functions likethe_post(),the_comment()which are also defined in this file. - wp-includes/theme.php – defines lots of useful theme-related function such as
get_template(),get_stylesheet_uri(),get_404_template(),add_theme_support()and others. - wp-includes/user.php – defines the User API, which includes authentication functions and the
WP_User_Queryclass. - wp-includes/meta.php – defines metadata functions like
get_metadata()and theWP_Meta_Queryclass for multiple metadata queries. - wp-includes/general-template.php – defines general template functions, the most known of which are
get_header(),get_footer(),get_sidebar(). - wp-includes/link-template.php – defines link template functions, the likes of which you most probably already know –
site_url(),previous_post_link(),get_permalink()and many others. - wp-includes/author-template.php – defines author-related template functions like
the_author(),the_author_meta(),the_author_posts(). - wp-includes/post.php – defines post functions like
register_post_type(),get_post(),get_post_meta()and loads of others. - wp-includes/post-template.php – defines post template functions like
the_ID()andthe_title(). - wp-includes/category.php – defines category and tag functions like
get_categories()andget_tags(). - wp-includes/category-template.php – defines category template functions like
the_tags(),the_category(). - wp-includes/comment.php – defines functions for comment management, which include
get_comments(),wp_allow_comment()when a comment is approved,pingback()and theWP_Comment_Queryclass (which is the basis for our last week’s Display The Number Of Comments Held For Moderation article). - wp-includes/comment-template.php – defines
wp_list_comments(),get_comments_number(), and many others. - wp-includes/rewrite.php – home of the
WP_Rewriteclass which is the core class of the Rewrite API, which handles request routing. This file defines wrapper functions around the$wp_rewriteglobal likeadd_rewrite_rule(),add_rewrite_endpoint()and others. Permalinks, among other core stuff, work thanks to these exposed functions and methods. - wp-includes/feed.php – defines the WordPress Feed API with functions such as
get_the_content_feed(),fetch_feed()and other useful stuff connected to RSS, RSS2, Atom and RDF feeds. - wp-includes/bookmark.php – the Link/Bookmark API lives here, exposing functions such as
get_bookmarks(). - wp-includes/bookmark-template.php – Link/Bookmark-related template functions reside here. The only out-of-the-box function that can be used as a template tag is
wp_list_bookmarks(), which you have most probably used in your templates. Now you know where it comes from. - wp-includes/kses.php – defines functions that are used to strip, normalize and filter out tags that are not wanted. These functions protect your website from persistent XSS attacks and other malicious evils. The
wp_kses()function is great to filter out unwanted data from both front-end and back-end users. - wp-includes/cron.php – the CRON API allows you to schedule events to be fired off within WordPress, the events are stored in the ‘cron’ entry in the options table as serialized data. Scheduling actions is done through the
wp_schedule_event()andwp_schedule_single_event()functions. For more insight on how these functions can be used check out our Writing a Tweets to WordPress Posts Plugin (Part 1) article which deals with the WordPress Cron API. - wp-includes/deprecated.php – this file includes functions that are deprecated and will be removed in upcoming versions of WordPress. Still using
get_author_name()oris_plugin_page()? Use of these functions will throw deprecation messages for now and in the near future your scripts may not work. If you’re using a function that is deprecated open this file, find it and see how you are supposed to get by from soon on. - wp-includes/script-loader.php –
wp_enqueue_scripts()is defined in this file among other useful functions that allow you to insert stylesheets and javascript into the head of a WordPress page. The script uses BackPress dependencies which are defined in wp-includes/class.wp-dependencies.php which defines a parent enqueue class, wp-includes/class.wp-scripts.php, wp-includes/functions.wp-scripts.php (wp_enqueue/dequeue_script()), wp-includes/class.wp-styles.php and wp-includes/functions.wp-styles.php (wp_enqueue/dequeue_style()). - wp-includes/taxonomy.php – defines the
WP_Tax_Queryclass and provides all sorts of wrapper functions around the global$wp_taxonomiesvariable likeget_taxonomy(). - wp-includes/update.php – defines a set of functions designated to update WordPress and its components.
wp_version_check(),wp_update_plugins()andwp_update_themes()among a couple of others. - wp-includes/canonical.php – functions used to enforce canonical URLs. If you want to find out what canonicalization is check out this article
- wp-includes/shortcodes.php – provides a set of functions revolving around the Shortcodes API like
add_shortcode(),do_shortcode(),strip_shortcodes()and other useful ones. - wp-includes/media.php – defines the
WP_Embedclass, and a set of functions likeadd_image_size(),set_post_thumbnail_size(),image_resize()which are very useful, especially when third-party image resizing plugins go wrong. Also be sure to check out our Images, Image Sizes and Post Thumbnails in WordPress article. - wp-includes/http.php – defines some simple HTTP functions like
wp_remote_post/get()andwp_remote_request()which can be used for some pretty neat stuff like requesting other pages. - wp-includes/class-http.php – defines
WP_Http,WP_HTTP_Proxy,WP_Http_Cookiesand other useful classes which expose methods that allow WordPress and your plugins to manage and process HTTP requests. - wp-includes/widgets.php –
WP_WidgetandWP_Widget_Factoryclasses are defined here, and functions such asdynamic_sidebar(),register_sidebar(),register_widget()and others. - wp-includes/nav-menu.php – defines the
register_nav_menu()function among others, which allows you to manage navigation menus. - wp-includes/nav-menu-template.php – you guessed it,
wp_nav_menu()is defined here, yes the one that is used in most WordPress templates out there to display navigation code. - wp-includes/admin-bar.php – and last but not least, this file defines functions pertaining to the Admin bar that you see when you browse your WordPress website being logged in as an administrator.
- wp-includes/class-wp-walker.php – defines the
- Since we’re not running a multi-site (hopefully, as multi-site is out of the scope of this article) wp-settings.php proceeds to define some plugin directory constants through the
wp_plugin_directory_constants()functions (defined in wp-includes/default-constants.php). Such constants asPLUGINDIRandWP_PLUGIN_URLare unpacked into the global scope. wp_cookie_constants()is called, unpacking cookie path and name constants. This function call is followed by a similarwp_ssl_constants()call which defines only two constants:FORCE_SSL_ADMINandFORCE_SSL_LOGIN.- wp-include/vars.php is loaded into the scope. This file creates common globals that are accessible from within WordPress and its components. These globals include the
$pagenowglobal, simple browser detection globals ($is_lynx,$is_gecko,$is_winIEand others), and web-server detection globals ($is_IIS,$is_apache, “nope no nginx detection”). create_initial_taxonomies()(defined in wp-includes/taxonomy.php) is called, which sets up all the initial taxonomies used in WordPress:category,post_tag,nav_menu,link_categoryandpost_format.create_initial_post_types()is similarly called (defined in wp-includes/post.php). Here the following post types are registered:post,page,attachment,revision,nav_menu_item. The following post statuses are registered:publish,future,draft,pending, private, trash,auto-draft,inherit.register_theme_directory()providing theget_theme_root()as an argument, yes you guessed it, registered the theme directory.wp_get_active_and_valid_plugins()retrieves the list of all active plugin files for loading and includes them. This is the point where your plugin code gets executed, functions, classes defined, etc.- Includes wp-includes/wp-pluggable.php and wp-includes/wp-pluggable-deprecated.php which include functions (and deprecated functions) that can be redefined by plugins. Like
wp_mail()for more advanced mailing,wp_authenticate()for alternative authentication methods, etc. wp_set_internal_encoding()is called to set the internal encoding according to theblog_charsetoption.wp_cache_postload()is called if object caching is enabled.- At this point a
plugins_loadedaction is fired. This is the very first action (aftermuplugins_loadedfired before loading the non-multi-site WordPress plugins) that you can hook into, it comes before theinitbecause WordPress has not been initialized yet, at least not fully. wp_functionality_constants()definesAUTOSAVE_INTERVAL,EMPTY_TRASH_DAYS, andWP_POST_REVISIONSconstants.wp_magic_quotes()adds magic quotes to POST and GET requests and merges them into the$_REQUESTglobal.- The
$wp_queryglobal object is instantiated from theWP_Queryclass. - The
$wp_rewriteglobal object is instantiated from theWP_Rewriteclass. - The
$wpglobal object is instantiated from theWPclass. Hurray! - The
$wp_widget_factoryis instantiated from theWP_Widget_Factoryclass. - At this point your
setup_themehooks are executed, followed by template constant definitions fromwp_templating_constants()and default localization text-domain loadingload_default_textdomain(). - The
$localevariable is defined and the wp-content/languages/ folder is searched for to require the necessary WordPress localization files. - wp-include/locale.php is loaded defining the
WP_Localeclass and it is instantiated as a$wp_localeglobal. - Theme function files (functions.php) are loaded at this point for both the parent and the child themes.
do_action('after_setup_theme')is fired to denote the end of theme setup.- If the current theme supports
post-thumbnailsthe wp-include/post-thumbnail-template.php is loaded which defines template tags such asget_the_post_thumbnail(). - A shutdown function is registered called
shutdown_action_hook(defined in wp-includes/load.php). This function simply fires theshutdownaction for plugins to hook into before the WordPress script’s execution is almost completed. $wp->init()is called which initializes WordPress. This init process involveswp_get_current_user()(defined in wp-includes/pluggable.php), which hydrates the global$current_uservariable.- The
initaction is fired. - The
wp_loadedaction is fired.
What a long process, and that’s not the end of it. Remember how wp-settings.php is included into wp-config.php, which by this time has no more code to execute, so the calling wp-load.php, which also has finished executing its code, so its callee wp-blog-header.php which has to continue booting up WordPress, to ultimately return the HTTP request with the necessary HTML code.
Finally, after submerging into some really deep waters we can have a quick gulp of air and continue exploring more WordPress Internals in our third and final part of how WordPress boots up. So, stay tuned, follow our Twitter feed for WordPress tips, tricks, development and design articles, and be sure to let me know if I messed some of this WordPress loading up. exit().




Best part about this tutorial: you ended it with
exit();:D
:) Thanks for reading up to the very very end, John.
Maybe the time has arrived for the release of a simpler, leaner, WordPress version.
With functionality comes complexity; it’s all made so that developers can extend and make use of some advanced features in a modular way. WordPress became more than just a blogging engine a long long time ago, thus, maybe when comparing it to the likes of Joomla, Drupal, Moodle, and other content management systems it doesn’t seem to be too bloated or complicated. I can’t know for sure, as my exposure to other CMSes has been limited to usage/setup/plugin development, never dug into their cores too much.
A simpler WordPress version will require the removal of some functionality, I guess. What are you prepared to give up? Or are you referring to other methods of simplifying? What struck as the most complicated part?
I think that developing for and extending WordPress appears to be quite convenient and simple, we aren’t even really required to look inside the core, it’s there to make life easy at the expense of many files, lines of code, complicated structure and whatnot.
Pingback: Linkdump #62: WordPress. « Tomasz Kowalczyk