Answering short: it’s legit and proper solution.
Answering in details:
1. About the table capacity
Considering _options
table structure
option_id | bigint(20)
option_name | varchar(64)
option_value | longtext
autoload | varchar(20)
and the fact that option_value
(which is going to contain your HTML), is longtext
– it can store L + 4 bytes, where L < 2^32
(4 Gigabytes of info).
I’d like to say more: serialized array, which can contain options stored as a text, is much more effective THAN key-value
pairs in terms of db optimization (understand as storing a short strings under meta/option_name - meta/option_value
, is less effective).
2. About storing the HTML
Dont forget about charaters escaping there.
<?php echo stripslashes( get_option( 'your_option' ) ); ?>
, in order to output the content.
More advanced solution may be a serialized array. But it’s more suitable if you want to store some key-value
“option” pairs additionally to your HTML.
3. The API.
_options
table can be accessed via user-friendly API