CHAPTER 7 • Making the Most of WordPress Plugins 209
Now that you’ve gotten your hands a little dirty with plugins and widgets, it’s time to discuss
database usage. It is easy enough to store data in the options tables, but sometimes it is just
not the best practice.
PLUGINS AND THE DATABASE
Storing data in the database is sometimes necessary to make your plugins function the way
you want. From storing some simple options to adding full tables with more data for the users
to utilize, the database is truly a tool that should be put to good use. Putting data in the
database means that you can query for it easily; it is just very convenient.
However, it comes at a price. A cluttered database isn’t very nice to maintain, and you have to
make sure that the user can uninstall the data stored by the plugin. And if that’s not enough,
you need to decide where to save this data. Either you use the Settings API to make sure that
things end up where they should — a nice solution for smaller settings — or you create your
own table within the database for the plugin only. The latter solution is probably better if you
need to store a lot of data, but it extends the database in such a way that it may create issues
with other plugins interacting with the database, should you want to integrate with them in
any way. It also means that there is a part outside WordPress that needs to be backed up, and
if you want to move the install, the Export/Import method won’t cover the data unless you
sort that out, too.
Then there’s caching, which is something you might need to consider for your plugin,
especially if it pulls data from an external service at regular intervals. You could use files for
caching obviously, but another option is the Transients API, which was created for these
things. You can read more about that at http://codex.wordpress.org/
Transients_API.
So what’s best? Data in options or in its own table? Maybe you should even use the meta tables
or the posts table? It is entirely up to you, depending on what you need to store. My personal
guideline is that settings should go in options, and if it is actual content or larger amounts of
data, I consider the external table option.
Just make sure that you inform the user and make sure that it is possible to clean up after
uninstallation should it be necessary, and you’ll be fine.
BACKWARD COMPATIBILITY FOR PLUGINS
Another aspect to consider when developing plugins is whether you want or need backward
compatibility. There are new functions and hooks added to WordPress all the time, and if you
rely on the new ones, previous versions not featuring them naturally can’t run the plugin.
That’s why you should be careful when using new features as they may just not work in older
versions of WordPress.
However, it is not just WordPress functionality that changes; the system requirements have
seen some revamps too. As of this writing, PHP 5.2.4 is required. The basic premise should be
to support the software that WordPress runs on, but sometimes that’s just not enough, and