I’m a fan of short release cycles. Depending on the project, the length of the cycle will vary, but for many of the types of projects on which I work, I aim to have two-week release cycles.
Further, there are times in which I’m working on a project for someone where environmental variables are necessary so the code knows if it’s running in development, staging, or production.
And this can be achieved a different way depending on the needs of the project. Sometimes, a configuration file will work, sometimes query string variables can work, and other times I think it’s reasonable to store a setting in the database.
But, as far as WordPress is concerned, I think we shortcut better design decisions and throw information in the database, specifically the options table, when alternatives may be better suited.
The WordPress Options Table
I want to be clear: I do not think the options table should serve as a dumping ground for settings when you have nowhere else to put information. And that’s the gist of this entire post.
Instead, you can use:
- a configuration file,
- session data (when appropriate),
- a custom database table,
- or something else.
So why do we see this happening so frequently? It’s not that there aren’t times in which it makes sense to use it. I just think we abuse it. But there are reasons why.
The WordPress Codex defines options like this:
Options are pieces of data that WordPress uses to store various preferences and configuration settings.
With a definition like this, it’s easy to see why so many will use it as a place to store anything that doesn’t fit anywhere else.
Instead, I think it’s important to ask the question:
To what type of storage is [this data] most relevant?
That is, if it’s related to posts then why not store it in the post meta table? Same for term metadata or comments or anything else.
The point is this:
Find the most logical place to store the data and place it there.
In other words, don’t toss data into the WordPress options table because it doesn’t fit anywhere else. That pollutes it. Instead, find – or create – the most logical place for it. That is probably evidence of a code smell and would be a good reason to re-evaluate the architecture of your code and how information is being represented.
But what might this look like? That is, how would we take a given piece of code and change how it’s represented in the database.
Unfortunately, it’s hard to provide a prescriptive solution to this question whenever so many variations of the implementation of a problem exist. So maybe a simple guideline is in order:
If the data is related to the pre-existing data types (or tables), then use them; otherwise, consider a configuration file or custom database table that maps to your work.
I’m sure there are other guiding factors, but this is a better place to start than simply polluting the WordPress options table.