Whenever I review a third-party, PHP-based product for my use, I always try to figure out what makes it tick. I generally pick a page, look at the URL, and try to figure out how the PHP code executes to get from the URL to the output that I see on my screen. It usually takes about a week to get familiar enough with a system that I'm comfortable with writing new code for it. But I'm always left wishing there was documentation on the execution path to save other people the trouble I go through.
The execution path, or how Barebones CMS loads and processes a page, is critical under-the-hood knowledge that programmers should become acquainted with prior to developing new Widgets, Shortcodes, or Plugins. The best way to read this document is to follow along as best as possible in your own Barebones CMS installation.
During the installation process, the first page in the CMS is created at the root of the installation. This page consists of three files:
Here is what 'index.php' roughly looks like:
<?php define("BB_FILE", 1); $bb_dir = "."; $bb_file = "index"; $bb_relroot = ""; $bb_page = unserialize(base64_decode("YToxM...VzIjt9")); require_once "main.php"; ?>
You will note that there is a variable called $bb_page and it consists of serialized and Base64 encoded content. This is done this way to eliminate any possibility of hacking the system through improperly escaped content. If you want this and other dynamically stored variables to be readable, enable the 'USE_LESS_SAFE_STORAGE' option in your configuration file.
The initial file is typically no bigger than a few hundred bytes. The goal of this file is to load just enough content for 'main.php' to be able to figure out what to do.
After initializing a few variables, 'main.php' is loaded. This is the entire Barebones CMS caching system and is contained in a little over 2KB of code. The caching system determines which cache profile to use, what language file to serve up, if the language file exists, and whether any special bypass mechanisms are being used: 'action' or 'bb_action' in the $_REQUEST array or 'Flush Cache' was clicked in the editor thus forcing a site-wide update. Once the caching system determines that it is okay to serve cached content, it does so.
If the caching system determines that fresh content needs to be generated, it runs 'proc.php'.
The page processor, 'proc.php', is the primary workhorse of the Barebones CMS. The first thing it does is load the global configuration from 'config.php' and a few other support files.
The next step is to clean up all the input into PHP itself. This is done with the ProcessAllInput() function.
After that, the "preferred language" is selected and the language-dependent PHP file associated with that language is loaded. This file is named 'index_somelanguage_page.php' (e.g. 'index_en_us_page.php' for 'U.S. English') and looks roughly like:
<?php $bb_langpage = unserialize(base64_decode("YTo0On...zQ3Ijt9")); ?>
This loads a single variable, $bb_langpage, that contains all of the language-specific information about the page. Specifically, it contains widgets and a couple other minor page-level configuration options.
Once $bb_langpage is loaded, the widget infrastructure is initialized and then one of three processing options takes place:
BB_ProcessPage() is where the page generation magic happens. It has four states: 'prehtml', 'head', 'body', and 'foot'. Each state executes the Process() function of each widget on the page starting with the "root" master widget. Every page in the Barebones CMS has at least a root master widget that can't be detached or deleted.
If 'bb_action' is defined in $_REQUEST, then 'edit.php' is loaded. The editor is roughly 120KB of code. Each stage of the loading process consumes more RAM and more CPU with the main editor being the largest consumer. This is to keep load times and resource usage low.
Some might wonder if breaking up the main 'edit.php' file into logical sections or some such nonsense would be a good idea. Keep in mind that while thousands or millions of people will be viewing the frontend, the editor will likely only be used by a handful of people. So, it can consume more resources on the system.
The first thing the editor does is a lot of initialization:
After the editor is initialized, it uses 'bb_action' (and possibly 'wid') to locate an editor or widget action to execute. If it finds such an action, it executes it. The editor is heavily AJAX-driven, so following along in this code is kind of difficult. There is also some bouncing around between 'edit.php' and 'proc.php' to get some portions of the editor loaded properly.