Working in technology, I find myself trying to re-design the tools I use. Frequently.
Not a day goes by that I don’t bemoan some drawback of WordPress and sketch out in my head the perfect replacement. Actually, most WordPress developers complain about one aspect of the software or another and mentally plan out a future product that fixes the nitpick of the day.
But, like WordPress, our solutions only solve part of the problem.
WordPress Isn’t The Whole Picture
When I ask new developers how to install WordPress, I usually get one of two answers:
- Use a host’s one-click installer
- Set up a standard PHP install, talking to MySQL, and routed by Nginx/Apache
In practice, though, configuring WordPress is rarely this simple. In addition to configuring the web server (Nginx, Apache, or some other flavor), you have to configure:
- PHP – As a server extension (Apache), as a CGI process, as an FPM module. Accessed over a port or a socket
- MySQL – Setting up a new user, locking that user down
- File system – Configuring the proper write-access and user permissions within the server so WordPress can’t touch non-WordPress files
- The server itself – Does the web server talk directly to PHP, or proxy through another application? Some servers use Nginx as a proxy to Apache, which bundles PHP as a module …
- Caching – Memcached? APC? Nginx microcache? Varnish?
- Does the site serve content through a CDN? Is the CDN merely an asset server or a reverse proxy?
WordPress has a 5-minute installer for the software itself. But the whole application is so much larger than the tarball pulled down from WordPress.org.
Full-Stack Development
Lately, when I start fantasizing about the “perfect” built-from-scratch CMS, I’ve been taking the entire stack into account. How static pages are served from a cache should be a consideration. How static assets are managed by the web server (and potentially offloaded to a CDN) should be a consideration. How the application deals with data connection pools and query caches should be a consideration.
WordPress is just one part of what can amount to a very complex stack in production. Unfortunately for newer developers, this stack is often convoluted, configured by a systems team with little to no maintenance documentation, and will be set up differently on every server you encounter.
I have yet to see an entire WordPress server set up twice in exactly the same way by different people – if the same sysadmin sets things up, she’ll usually do it the same way twice. Sometimes, I even see individual developers set up WordPress differently on two different servers.
It’s a nightmare!
My ideal blogging app/content management system/application platform would take the entire stack into account. The entire request lifecycle – from cache hits to database queries to static asset delivery – would be modeled within the application itself rather than left up to the whims of whichever sysadmin is tasked with installation.
What other considerations would you add to WordPress (or any other application) to support developing a full-stack solution over a piecemeal conglomeration of tools?