I like WordPress a lot. It’s one of my favorite open-source projects, and I use it often for both my professional and personal projects. It’s been my go-to web development framework for a number of years now.
There’s one thing I don’t like about WordPress, though: the domain to which a WordPress site is deployed is saved as a setting in its database. I don’t think that was a good design decision, because it makes it a pain in the ass to move a WordPress site from one domain to another. This shortcoming is especially evident if you’re trying to develop a WordPress site on one domain, but would like to deploy to another. (For example, I always set up my local sandbox such that the WIP lives at example.dev, while deployments are pushed to example.com). I really wish WordPress had been designed just to path against its own document root, much like MediaWiki (another awesome piece of web software).
Having spent a significant amount of time as a freelancer, I am always surprised at how frequently developers leave simple and obvious security vulnerabilities in their applications. All kinds of vulnerabilities have abounded in some of the projects I’ve inherited, but two jump out at me over and over: Cross Site Scripting and SQL Injection vulnerabilities.
I spent an evening thinking of how, to the greatest extent possible, to “idiot proof” PHP programming within the context of the typical web application. What follows is the result of that evening’s worth of research and experimentation. Read the rest of this entry »