Dougal Campbell's geek ramblings

WordPress, web development, and world domination.

Suggestion: WordPress Option Namespacing

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:

About Dougal Campbell

Dougal is a web developer, and a "Developer Emeritus" for the WordPress platform. When he's not coding PHP, Perl, CSS, JavaScript, or whatnot, he spends time with his wife, three children, a dog, and a cat in their Atlanta area home.
This entry was posted in WordPress and tagged , , , , , , , , , , . Bookmark the permalink.

11 Responses to Suggestion: WordPress Option Namespacing

  1. Well, you’ve obviously seen my article, ;-) so you already know I do similar already. My thoughts:

    1) starting the name with “plugin” or “theme” is a good idea.

    2) You’re idea makes a big assumption — that all plugins are coming from the WP repository. Personally, for the second part of the option name I use the name of the folder containing my plugin — which also pretty much precludes two plugins using the same term

    3) Beyond that we’re quite similar. I do it this way: “plugin_slug_settings”

    4) I would not try to *force* people to follow a scheme. This is more a case of education (so thanks for linking to my article ;-) ) “You can lead a horse to water….” applies to code.

    5) Not sure why it’s necessary for Core. If it had been done from the beginning it might have been a good idea, but at this point changing all the options names would break practically every plugin in existence. Not worth the doing. (I guess you could do some code workaround, e.g. “if option doesn’t exist, add core_wp_ to the beginning and look again” but again — is it worth it?)

  2. Evan Mullins says:

    Great idea Dougal. This would def help knowing where things come from in the database.

  3. I think this is a great idea! Wouldn’t it be possible to handle this update on the WordPress side when saving options? Meaning the suggested option prefix value would be generated based on where/how the option is created. That way there wouldn’t be an extra step for developers and it would all be consistent.

    This could also be hooked into the uninstall system so maybe we can create a new function that automatically clears all plugin options based off of the plugin calling it during uninstall?

  4. Pingback: uberVU - social comments

  5. Andrew says:

    I certainly think this is something that should be in core. It should be straightforward to write up a basic patch for this that would handle un-namespaced options gracefully.

  6. Pingback: L’hebdo WordPress : extensions, twitter, bbpress

  7. arena says:

    separator ‘:’ not supported for meta tables !

  8. Pingback: In WordPress, prefix everything | Andrew Nacin

  9. Pingback: Suggestion: WordPress Option Namespacing | WPLover

  10. Pingback: asdasdasdasd | WP

Leave a Reply

%d bloggers like this: