- 1. Currently Reading: Beginners Guide to Understanding WordPress Internal Functions
- 2. What is WordPress Caching and Why is it Important?
- 3. How does WordPress Caching Work?
- 4. How to Install & Setup WordPress Caching with WP Super Cache
- 5. How to Setup WordPress Caching with W3 Total Cache (W3TC)
- 6. MaxCDN Review: The Best CDN for WordPress?
WordPress geekiness an acquired taste and it gets better with every new thing you learn. We’ve all been using WordPress for quite some time now – it’s one of the reasons why you’re here at WPExplorer, reading this article! Like you, I too stumbled upon this fine craftsmanship and have been mesmerized by its sheer beauty. Not only does WordPress give us the ability to publish dynamic, visually appealing websites in a matter of minutes, but also use it as multi-dimensional content management solution (CMS).
As a side note, I’d like to mention that this article is intended for a WordPress beginner. Most of you might know what I’m talking about. So please feel free to give it a quick read and share your views in the comments section. Thanks!
Getting back on track, let’s take a look at the stuff we can do using WordPress:
- Magazine website – TIME, GigaOM, TechCrunch, all use WordPress.com VIP
- Host multiple websites under one roof – EduBlogs (WordPress MultiSite)
- Build a forum (BuddyPress)
- Online portfolio
- Host a job portal
- ECommerce store (Woocommerce, Exchange, EDD, Cart66, etc.)
- Photoblog or a photography portfolio
- Site for a band, restaurant and so much more
The list goes on. This article serves as a precursor to our upcoming post series – The Definitive Guide to WordPress Caching. Before we understand WordPress caching, we need to understand how WordPress works internally. Not just editing and deleting posts and comments – but how a few thousand lines of code intertwine between each other and produce beautiful dynamic websites.
Internal Functioning of WordPress
We all know how to work with WordPress. It all starts with logging into your WordPress administrator dashboard – right from your-site/wp-login.php followed by publishing, modifying or uploading new content, installing plugins, themes, taking backups, etc.
But have you thought about how this entire thing works? Websites run on HTML (which stands for Hyper Text Markup Language). Check your address bar – you’ll always find http://sitename.tld. Other protocols include https, ftp, ssh etc.
So it’s understood that the ultimate aim of WordPress, is to generate HTML pages – dynamically. The key term to understand here is ‘dynamically’. The terms “HTML page”, “web page” and “webpage” are all synonymous. At the very basic level WordPress uses PHP and a SQL database to store all its data. We need not be concerned much with PHP and other scripting languages WordPress uses, since this is a beginner’s guide and they’re advanced topics.
Thus, we have two entities. One is the “PHP code” which makes up the WordPress Core and the “Database” which makes up WordPress’ memory. Each WordPress installation has one database. No more, no less. Every bit of information that you have entered and will do in the future is stored in the WordPress database. Examples include:
- User information like password (encrypted with MD5), email address etc.
- All posts, pages, tags, categories and the relationship between them
- Custom post types
- Post revisions, drafts and trashed options
- Comments – both approved and unapproved and spam
- Theme options and plugin data
What about the images, documents and other files that are uploaded? Are they too stored in the WordPress database? Nope. They’re stored in a folder called “wp_content”. More on this follows.
The WordPress Folder Structure
As of WordPress 3.6.1, there are three main folders in every WordPress installation.
The base folder
This is the WordPress installation directory and everything (apart from the WordPress database exists here). We’ll call it the “root directory”. In case of people running WordPress in shared hosting servers powered by cPanel, the root directory is most probably the contents of the “public_html” directory, if you’re running WordPress in your base domain (i.e. site.com and not site.com/folder).
The WordPress root directory contains exactly three folders: wp_content, wp_includes and wp_admin along with a bunch of other PHP files, the most significant one being “wp_config.php”. By modifying this file, we can add a bunch of core WordPress customization options that aren’t readily available in the WordPress administrator dashboard. For example, we can disable post revisions, set the site name used by WordPress (useful for domain changes), enable maintenance mode, etc. The wp-config.php file is a very important file and should not be tampered with. It contains crucial information such as the access credentials to your WordPress database. If someone can get to your database, he/she has complete control over your site.
This folder contains all the other PHP files and classes which is required for WordPress’ core operations. Again, you don’t want to edit any files in this directory.
This folder contains the various files of the WordPress dashboard. You know that all administrative or functions related to WordPress, such as writing posts, moderating comments, installing plugins and themes are done via the WordPress dashboard. Only registered users are allowed access here and the access is again limited based on the User’s role. An administrator is allows full access followed by the Editor, then the Contributor and finally the Subscriber. The WordPress dashboard is typically accessible under http://wpexplorer.com/wp-admin.
The wp_content folder contains all user uploaded data and is again divided into three sub-folders:
The “themes” directory contains all the themes that are installed in your WordPress site. Every wordpress.zip file that you download from WordPress.org has 2 themes installed – for WordPress 3.6.1, they are Twenty Twelve and Twenty Thirteen. You can install as many themes as you want, but can only activate one theme at a time (although there do exist some plugins that allow you to activate more). Also, the “themes” directory can never be empty, since WordPress needs at least one theme to work with!
Similarly, the “plugins” is used to store all the plugins installed in your WordPress site. Unlike the “themes” directory, this directory may be empty as you can perfectly run a WordPress site without using any plugins. You at liberty to activate as many plugins as you like but it’s a good practice to install only the necessary ones. Check out Kyla’s article on the various WordPress plugins available today.
All the images (and other media files) that you’ve uploaded since the time you launched your site, along with all future uploads, will be stored in the “uploads” directory, categorized by year, month and day. This folder can be thought of as the database for all non-textual data – images, PDFs, videos, MP3s, etc. That’s why it’s a good security practice to restrict public access to these folders. This can be achieved by modifying the .htaccess file, present inside the wp_content directory. Therefore while taking a backup; copying only the WordPress installation folder doesn’t do the trick. You need to copy both the database and the entire content of your WordPress installation directory!
The Anatomy of a WordPress Request
Or as I like to call it,
What happens when someone views your blog?
When someone visits your WordPress powered website, WordPress dynamically generates a HTML code (combine with CSS and JS) and serves it to the visitor. You won’t see the extension .html after the URL, (as you might have seen in some old websites) since this content is dynamically generated. The following points are a generalization of the actions that take place in the event of a webpage request:
- Visitor’s browser requests a web page
- The WordPress core (can be thought of as WordPress’ brain) calls the required PHP scripts starting with index.php
- The WP core then communicates with its database and retrieves the data (posts/pages etc.)
- It then combines the fetched data, the data from the currently active plugins, and the currently active theme and generates the HTML code “on-the-fly” or “dynamically”
- It then serves this dynamically generated HTML code to the visitor’s browser
Similarly, when a post is published or saved, or a comment is submitted, or a search is made, the WordPress core carries out the required internal operations and saves them in its database for future use and it also notifies the WordPress administrator. You (the admin) see them as a new comment awaiting moderation, or ‘x’ number of comments in your spam queue, etc.
Now, repeating all these steps every time someone requests a webpage (post, page, archive page, anything) is a time and resource consuming job. It’s fine when 10 people visit your site. But increase that by 100, 1000, or a million, then the real trouble begins. Only supercomputers would be able to handle that many concurrent operations. And most WordPress sites are hosted on shared web hosting servers, which have maybe 1/1000th of the power of supercomputers.
So what do we do now? Enter WordPress caching. We won’t be covering it here, so please stay tuned for the next part of the series – an introduction to WordPress caching.