Comments on: Suggestion: WordPress Option Namespacing

By: mikaeljorhult (Mikael Jorhult)

mikaeljorhult (Mikael Jorhult) — Wed, 12 May 2010 10:54:05 +0000

kanske har lätt att bli sentimental men sånt här gör mig lycklig på riktigt. http://bit.ly/drYPxu http://bit.ly/5Dmn7U #nördigtochvackert

By: Suggestion: WordPress Option Namespacing | WPLover

Suggestion: WordPress Option Namespacing | WPLover — Wed, 12 May 2010 00:14:22 +0000

[...] Suggestion: WordPress Option Namespacing [...]

By: In WordPress, prefix everything | Andrew Nacin

In WordPress, prefix everything | Andrew Nacin — Tue, 11 May 2010 17:24:12 +0000

[...] In the comments, Dougal also brought up namespacing options (and a related proposal). Though I neglected it in my laundry list, that is also very important. Same goes for transients, [...]

By: arena

arena — Fri, 18 Dec 2009 08:16:52 +0000

separator ‘:’ not supported for meta tables !

By: L’hebdo WordPress : extensions, twitter, bbpress

L’hebdo WordPress : extensions, twitter, bbpress — Wed, 16 Dec 2009 05:49:03 +0000

[...] Dougal Campbell qui pose la question. Il s’est en effet aperçu que les bases de données de WordPress peuvent vite devenir un [...]

By: Andrew

Andrew — Fri, 11 Dec 2009 17:23:37 +0000

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.

By: uberVU - social comments

uberVU - social comments — Fri, 11 Dec 2009 15:37:36 +0000

Social comments and analytics for this post…

This post was mentioned on Twitter by Dougal Campbell: New Blog Post: Suggestion: WordPress Option Namespacing http://bit.ly/5RZyZp #wordpress…

By: Brad Williams

Brad Williams — Fri, 11 Dec 2009 15:13:07 +0000

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?

By: Evan Mullins

Evan Mullins — Thu, 10 Dec 2009 21:43:21 +0000

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

By: Stephen Rider

Stephen Rider — Thu, 10 Dec 2009 18:01:38 +0000

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?)