Is there a way around this?
Short answer: Yes, technically possible, but not recommended. Read below for the long answer:
Using Custom Database
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
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:
In this case, implement
Options API functions in your theme's
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.