WordPress, web development, and world domination.

I happened to be poking around in my database a while ago, particularly in the WordPress ‘options’ table for this blog. There’s an awful lot of cruft hanging around from old plugins that I don’t use anymore. I cleaned a few things out, but something hit me as I was perusing all those options: I can’t always tell which options belong(ed) to which plugins, themes, or to the WordPress core.

In many cases, plugin authors tag the option names in a way that you can figure it out. For example, Alex King’s Twitter Tools plugin uses a prefix of aktt_ on all of its options. And many other plugin authors similarly use a prefix of some sort that identifies the author and/or plugin. But it’s very inconsistent.

I would like to suggest a formal namespacing scheme which might help with option management in the future. The option_name field is a VARCHAR(64), so there’s plenty of room for creativity in option naming. Also, there are not really any tangible restrictions on what characters can be used, though most of us tend to stick with identifers that would be legal variable names when programming.

My suggestion for a format is: area:plugin-slug:option-name
Where area is one of core, plugin, or theme (any others that should be separate?). The plugin-slug is the same as the slug used in the Plugin Repository or Theme Repository. For core options, the slug can be ‘_wp_’ for normal options or ‘_trans_’ for transient options, or they might even be broken down in to sub-areas (‘general’, ‘writing’, ‘discussion’, etc.). For backwards compatibility as names are changed to the new format, core options could go through a deprecation phase where they keep the old names, but the get_option functions could be modified to check for the new names first, then fall back to the old.

Using Twitter Tools as an example again, the aktt_last_tweet_download option could be named plugin:twitter-tools:last_tweet_download. The core option rss_excerpt_length would become core:_wp_:rss_excerpt_length.

Advantages:

• Finding and deleting options based on their source would become easy. Need to get rid of some leftover options related to the Shazbot theme that you deleted? DELETE FROM $wp->options WHERE option_name LIKE "theme:shazbot:%"
• New standard option areas and slugs can easily be added in the future while retaining organization.
• Less chance of namespace collisions between various plugins and themes.

Disadvantages:

• Added complexity. Coders need to remember to use the new naming scheme, use new option get/set functions which take extra namespacing parameters, or we need to migrate to some sort of universal OOP plugin/theme frameworks in order to enforce consistency.
• Plugins with longer names get less flexibility with the actual option_name. For example ‘plugin:all-in-one-seo-pack:’ has already eaten up 27 characters which leaves 37 characters for the specific option name. Still not bad, but there might be cases where it could cause problems.
• Without core buy-in, unlikely to to be utilized by the general plugin/theme codign community.

Other Notes:

Backwards compatibility for core options should be easy, for the most part. I am unaware of any code in the wild using the ‘foo:bar:baz’ format for option names, so collisions with existing plugins is unlikely. The current get_option() function can be modified to match $setting against a regular expression to see if the setting being fetched is namespaced. If so, but the option isn’t found, un-namespace it, and look again. If the setting is not namespaced, and it’s not found, try looking for ‘core:_wp_:$setting’ as a last resort. This behavior could be in place for a few version releases, then deprecated later.

Also, as mentioned on the wp-hackers mailing list, current “best practice” is for a plugin or theme to wrap multiple options up into an array, and save it as a single entry. In some ways, that in itself helps mitigate some of the options table clutter. But a consistent naming standard, if followed by enough developers, would make things even cleaner. And there are certain use-cases where it still makes sense to keep multiple separate options. (I’m guilty of not grouping my options in arrays, but I’m planning to re-vamp all of my plugins eventually)

While I don’t really expect this idea to become part of core, I wanted to put it out in the wild for discussion. At the very least, we might be able to come up with some more solid “best practices” that can be documented on the WordPress Codex.

Further Reading:

You can learn more about how to build options pages for your plugins, and how to deal with options cleanly from these two excellent articles:

• Consolidate Options with Arrays in Your WordPress Plugins – Stephen Rider
• WordPress Settings API Tutorial – Otto