I'm looking for advice on the best way to store a series of settings for a modular theme.

To note:

  • The settings will not be user facing (not suitable for the customiser api).
  • Ideally the options would not be stored in the database as they will be static (for performance).
  • The theme is not public, it will be used as a framework for multiple sites.

I have discarded add_option / get_option which uses the database, and likewise for get_theme_mod / set_theme_mod.

Am currently using a global scoped array - which is not ideal (from what I read).

Any other thoughts / suggestions?

  • 3
    WordPress already does a query to load all autoload options, adding your options to this won't really have any impact, as they'll just be grabbed in that same single query.
    – Milo
    Jan 8, 2018 at 19:08

2 Answers 2


If a user can not change them then they are not options, they are constants. Declare them using const in your maim theme file (probably functions.php but any other files that is being always loaded will do), and use them wherever you have use the "options" array now.

If you want to control it without editing you theme files, you can use a conditional define instead (check if value is not defined yet and if not define it). That way you will be able to override the default values by defining them at the wp-config.php file per site.

... But this all question sounds wrong. The DB is there, so just use it, and a basic UI to control the options is easy to come up with. There is no real reason to resort to code changes every time you want to active/deactivate a module.

  • Thanks, as other users mention - that WordPress autoloads all options, think i'll go with that route. I assumed they were individual database hits from viewing various get_option calls from plugins, via Query Monitor. Jan 11, 2018 at 19:01
  • 1
    When you add options you can set whether they are autoloaded or not, and by default they are. If you use the theme_mod API All your settings will be stored in one option which will be autoloaded. Jan 12, 2018 at 6:32

First Pick

I would not ignore database options from the start, it would be my first pick since theme_mods are theme-depended.

As performance, wp options are autoloaded, and they make use of the persistent cache system that WordPress has in core(you can see it in action on wp_cache_get). They are as good as a global object.

Second Pick

It could be a reason to not store these settings as options if they are almost static(if they would rarely change) and they should just define which modules/parts of the theme should load or not.

In this case, I would go for a config.json file, which should be loaded with file_get_content. This way you could define a default config in the framework(something like config.example.json), and copy paste it over your websites.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.