Consider Banning use of wp_options by Plugins

[thegulshankumar]

Developers are abusing wp_options to store own plugin data instead bothering to create own table. Why not restrict wp_options for internal Core use only?

Why?

• This greatly affect performance of site.
• This makes hard to clean up wp_options when needed.

Some are good plugins who care about performance so they use seperate table.

Thanks

[thegulshankumar]

Apart from that optional "Clean Uninstall" button should be made mandatory.

[williampatton]

I don't think it is at all inappropriate to use the options table to store options. It's what it is for. The wp_ prefix is just a prefix - in no way does it imply that it is reserved only for core use.

It's also already behind cache layers which custom tables are not and so forcing plugins to have their own tables makes me feel like they would be inherently less well performing - not better - and/or much more complex code required to retrieve or save their data increasing the likelyhood of security problems.

Everyone is welcome to discuss the possible merits and pitfalls of _discoraging_ use of the options table but it should absolutely never be on the table to consider any outright ban.

[williampatton]

I'm suggesting this be closed. I don't think it's a core enhancement at all and if anything it's a policy change which doesn't belong on this trac.

[thegulshankumar]

Which Cache layer are you talking about? Please elaborate little more detail.

[williampatton]

Replying to thegulshankumar:

Which Cache layer are you talking about? Please elaborate little more detail.

The Options_API makes use of caching via it's various caller functions. You can see some of it in action if you look at the code of get_option().
​https://developer.wordpress.org/reference/functions/get_option/

[thegulshankumar]

Thanks for the information

I recently discovered that Yoast SEO started using custom table.
​https://yoast.com/innovations/indexables/

[SergeyBiryukov]

Related: #30577

[johnbillion]

Thanks for your interest in this issue @thegulshankumar but this isn't anything that can be enforced by -- nor is appropriate for -- a core change. The options table is meant for both core and custom options and there's no reason for that not to be the case. Whoever would want a whole new database table just to store one plugin option?

Every database table in WordPress can be abused, it's up to plugin developers to follow best practices and choose an appropriate storage mechanism for their data, whether that be a single row in the options table, or a whole new database structure, or something in between.

[thegulshankumar]

Thanks to all for clarifying.