There are two types of requests that can be made to a WordPress site.
A front-end request and an admin request.
Let's dive a bit deeper into the code that runs on a typical WordPress front-end request.
Except for specific requests, like the ones we looked at in the file structure lesson,
any request for content on a WordPress site, also known as the WordPress front-end,
is handled by the index file in the root directory.
Here, the WP use themes constant is set up, and in the first additional file is required,
WP blog header.
Require is a special PHP statement that will include the contents of the file being required.
There's a similar statement in PHP called include, which does the same thing.
The difference is that using require will throw an error and end execution if the file can't be
required. There are also supplementary statements, namely require once or include once, that will
only include the file if it's not been included already. The WP blog header file sets up the
WordPress environment by requiring the WP load file. In the WP load file, the abs path constant
is defined. This is used by many plugins to check if the plugin is indeed being run on a WordPress
environment. The file then sets up some error reporting levels. After that, it finds and loads
the WP config file or attempts to redirect to WP admin setup conflict of PHP to inform the user
to create the WP config file. You'll also note that this code allows the WP config file to be
moved outside of the WordPress directory. By moving WP config outside of the WordPress directory,
you can prevent the file from being accessed by a malicious user. WP config is the file that defines
all the database constants, debugging constants, and any other constants that your WordPress
installation might need. Finally, it requires the WP settings file, which sets up the WordPress
environment. WP settings does a lot of work, so this will just be a high level summary of all the
things it sets up. First, it sets up any WordPress version information, and then it requires any files
needed for initialization. After that, it calls functions to set up any initial constants, fatal
error handling, default time zones, server vars, maintenance mode, and finally checking if debug
mode is enabled. It then checks whether it needs to load the advanced cache.php drop-in. After that,
it sets up the wplang dir constant and then loads early WordPress files. It then sets up the global
database object, sets up the database connection, and starts the object cache. After that, it
initializes multisite if multisite is enabled, and then soon after that, it defines a function
called short emit. Short emit can be used for custom requests in WordPress. It loads the
localization libraries, runs the installer if WordPress is not installed, and then after that,
loads most of the rest of the WordPress libraries. It then starts setting up any commonly used global
objects like the embed object and the text domain registry. It loads some multisite specific files
and then it sets up and installs any master use plugins.
If this is a multisite, it will then load any network activated plugins
and then fire any master use and network activated plugins
once they're loaded. It then sets up any cookie constants and any SSL constants
and creates any common global variables. It then creates the initial taxonomies and post types,
registers the theme root directory, and then finally starts loading any active plugins.
It then does things like setting up default constants which affect functionality
and adding magic quotes and setting up the request global variable. Then it creates some more global
objects, the query object, the rewrite object and the WordPress object, the widget factory,
and the roles object. It sets up any templating constants and loads the default text domain
and sets the WordPress locale. It then loads the functions.php file for the active theme
and the child theme if one is installed, creates a site health object and sets up the current user.
It checks the status of multisite and finally runs any callback functions hooked into the wploded
action hook. Back to the blog header file. Once the WordPress environment has been set up,
the wp function is called. This function determines what needs to be rendered and
fits the relevant data from the database to render it. The wp function calls the main method
of the wp object which is found in wp includes class-wp.php. This main method calls its own
init method. The init method calls the wp get current user function which sets up the current
user object. The main method then calls the pass request method. The method does quite a bit but
the short version is that it matches the request to the rewrite rules and creates the query vase
array based on the match rules. If no rewrite rules match, it will attempt to populate the
query vase array based on a query string. Back to the main method, if pass request returns true,
it will call the query posts, handle 404, and register global methods.
Query posts calls the bold query string method which builds the query string from the query
variables. It then calls the query method of the wp the query object. This code is found in the wp
query class file at wp includes class-wpquery.php. This will run the query and populates the wp query
object with the results. Once it initializes the query and passes the arguments, it will run the
get posts method which creates the SQL query based on the passed query parameters and then runs the
query against the database to return the relevant data. Back to the main method, handle 404 sets the
headers for any 404 errors if nothing is found for the requested URL. Finally, register globals
registers the query variables as global variables. After that's done, the send headers method is
called which sends any relevant headers to the browser. Last but not least, it runs any callback
functions that have been hooked to the wp action hook. You will learn more about hooks in a later
lesson. Back to wp blog header, after all the query data is set up, the template loader is required.
This file finds and loads the correct template based on the URL. First, it calls any callbacks
hooked into the template redirect action. Then it checks for specific requests typed, so for a
robots.txt file, for the favicon, for an RSS feed, or if they're requested for a trackback and performs
those specific actions. If the request gets this far, it will set up a list of template conditionals.
It will then loop through these conditionals and find the appropriate template file.
Finally, it will include the template file that was found earlier. Note the use of include not
require, so that the rest of the request can still be rendered if the template file is missing.