We’re going to kick off this basketball game (yeah, I pretty much suck at sports metaphors) by laying down some base concepts to build our discussion of child themes on.

Note: I’m presenting these not as “fully nuanced truth” but as “useful ways to think about it for now”. So if you wouldn’t mind holding the “yeah buts” and “well that’s not entirely corrects” until the end that would be cool.

The building blocks of a WordPress site

A common set of ingredients behind many modern content management-based websites can be seen in the following diagram. WordPress, Drupal and many others are built on top of this core DNA.

Only three of these languages are delivered to the browser for rendering of the pages: HTML, CSS and Javascript.

Their roles are (in a modern context):

• HTML provides the page structure and content
• CSS provides the visual design and layout
• Javascript provides logic and behaviour on the client-side

Behind the curtain of WordPress

So, in a single run-on sentence, WordPress primarily uses a pile of PHP files to provide logic, communicate with the database, build the HTML pages and then send these along with css files and javascript files (and media files) to the user’s web browser.

But, I hear you ask, surely WordPress is more than that? There is core code and features, dialog boxes, choices to be made, plugins, themes, etc.

I hate to shatter the illusion, but behind the scenes it’s predominantly PHP split across dozens of files along with a little css and javascript to send to the browser.