options - Any way to partition wp_options?

admin管理员组

文章数量:1410730

I'd like let some functions in my functions.php file use update_option() to save some local data, but the wp_options table seems to be global to every piece of software on my site, so I have to give my data some long name to make sure it doesn't collide with a name that someone else has chosen for their data. Is there a way around this?

Thanks

I'd like let some functions in my functions.php file use update_option() to save some local data, but the wp_options table seems to be global to every piece of software on my site, so I have to give my data some long name to make sure it doesn't collide with a name that someone else has chosen for their data. Is there a way around this?

Thanks

• options

Share Improve this question edited Nov 12, 2019 at 20:46 Eje 16544 bronze badges asked Jan 22, 2017 at 21:32 SteveSteve 18555 bronze badges

Add a comment  | 

4 Answers 4

Sorted by: Reset to default 2

No, and I strongly advise against changing the WordPress Options table schema, you'll run into many problems such as:

• No longer having a reliable update process
• Non-portable code
• You won't be able to use the get_options suite of functions and the object caching and optimisations that come with them

If you managed to get it working with get_options you'd be back were you started

My suggestion? $prefix.'_option_name'

Is there a way around this?

Short answer: Yes, technically possible, but not recommended. Read below for the long answer:

Using Custom Database table:

You can obviously implement custom Database table to handle your data. However, for simple operations, this process is not recommended. Some reasons are:

• It becomes difficult to maintain. For example, what if ten more plugins you are using decide to have their own table? Your database will become filled with tables that are most likely not well defined.

• You'll have to closely monitor future updates of WordPress & Database and personally make sure your custom Database functions remain compatible.

• Options API has been optimized by years of experience & updates, getting the same level of optimization with your custom Database will not be easy.

So using the core Options API is your best option (unless your data is related to posts or users. In those cases you should use post meta or user meta respectively).

To avoid option name conflict if the data is site specific:

• Use the site's domain name as option name prefix. For example, if your site is example, use example_com_option_name (replace option_name with appropriate name) for your option name. No one else is going to use your domain name for their prefix.

• In this case, it's better if you don't write the data functions in theme's functions.php. Instead, create a custom Plugin to handle these site specific data with Options API. This way even if you change theme, site specific options will remain intact. Check this article on why you shouldn't use functions.php for these types of cases.

To avoid option name conflict if the data is theme specific:

What if the data in question is specific to the theme, so that, if you use that theme in other sites, those sites will have similar data; Or, if you change the theme, you may or may not need the data? In such cases:

• Use the theme name as option name prefix. For example, if your theme name is steve, you may use steve_option_name. If you think that the theme name may not be unique, then combine your primary domain name in the option name: example_com_steve_option_name.

• In this case, implement Options API functions in your theme's functions.php file.

To avoid option name conflict if the data is neither theme specific nor site specific:

What if you have multiple sites & they use different themes and all of these sites need same option data?

• In this case, implement Options API functions in a custom Plugin and use the plugin name as option name prefix. Like above, combine your primary domain name with plugin name to avoid all possible naming conflicts.

[Bonus] Avoid adding multiple options:

In most cases, you actually don't need to create multiple options. Unless most of the options are exclusively used in different parts of your site, it's generally better to just create one option and put all your site specific custom options in an array. This document describes how you can do that. As stated in the WP document:

Accessing data as individual options may result in many individual database transactions, and as a rule, database transactions are expensive operations (in terms of time and server resources). When you store or retrieve an array of options, it happens in a single transaction, which is ideal.

So, if using only one option is OK for your use case, then why bother creating custom database table? With only one option name, the low possibility of conflict (after following the above recommendations) becomes even lower & even if a conflict occurs, the solution is very simple, as you'll just have to change only one option in the database.

You could create a new table just for your options.

On my plugins that save options, I just make sure that the option 'name' is not a common word, by naming the option with the initials of my plugin name. So if my plugin was called "My Really Neat Plugin", the options name would be "mrnp_options".

If you are worried about colliding with another similar option, your plugin activation code could have several alternative option names. But then you'd have to store that option name somewhere. So, not a good choice, I'd think.

I also put the plugin's 'initials' as part of all functions in the plugin, so my functions don't collide with someone else's.

I strongly agree with Tom J Newell and Rick Hellewell, as this is best practice for WordPress.

This page in the WordPress Codex will help with creating database tables if that is new territory for you.

本文标签： optionsAny way to partition wpoptions