 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 WPU's themes constant is set up and then 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 app's 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-config.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 wp-lang-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 multi-site if multi-site is enabled, and then soon after that, it defines a function called short-init. Short-init 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 multi-site specific files, and then it sets up and installs any master use plugins. If this is a multi-site, 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 local. 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, checks the status of multi-site, and finally runs any callback functions hooked into the WP loaded 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 fed to 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 getCurrentUser function, which sets up the current user object. The main method then calls the passRequest 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 vars array based on the match rules. If no rewrite rules match, it will attempt to populate the query vars array based on a query string. Back to the main method, if passRequest returns true, it will call the queryPosts, handle404 and registerGlobalMethods. QueryPosts calls the buildQueeryString 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-wp.query.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 getPosts method, which creates the SQL query based on the past query parameters and then runs the query against the database to return the relevant data. Back to the main method, handle404 sets the headers for any 404 errors if nothing is found for the requested URL. Finally, registerGlobals registers the query variables as global variables. After that's done, the sendHeaders 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 request types. So for a robots.txt file, for the favicon, for an RSS feed, or if the request is for a trackback and performs those specific actions. If the request getList gets this file, 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 it 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.