Adding Plugin Config Files to WordPress

Almost everyone who has worked with WordPress has dealt with wp-config.php. I know – there are a lot of managed hosts out there that take care of a lot of this for you – but even though a person may not have directly edited the file, they have definitely interacted with it.

For those who are unfamiliar:

This file is located in the root of your WordPress file directory and contains your website’s base configuration details, such as database connection information.

Anyway, for sometime now, I’ve been working on a relatively large plugin for a client and have recently taken to introducing a similar type of configuration files. So this raised that question, do what you think of plugin config files?

Plugin Config Files

To be clear, I don’t think that every plugin needs a configuration file. In fact, I think that if we’re not careful, then we’re dangerously approaching placing options into config files under the guise of treat them as configuration options.

"Not even sure how to set this up."
“Not even sure how to set this up.”

If you aren’t going to make decisions about how your plugin (or theme, for that matter) is going to function, then throw the options into a settings page and have your users work on that. After all, it’s only a little more work for them).

But seriously, here’s the scenarios in which I’m finding that it may be acceptable to introduce plugin config files:

  • The plugin is portable. That is, it will be installed on several different systems each of which have their own subtle nuances in the UI but have the same functionality.
  • The plugin includes custom post types, taxonomies, constants, etc. Whether it’s one or all of the above, the plugin has its own name for each of the above all of which still function the same way in terms of the back-end code.
  • The person managing the file is technically sound. Just like wp-config.php is meant for those who are comfortable with editing constant values and understanding their affect, such is the case of plugin config files.

For what it’s worth, I’ve found a lot of success with these.

We’ve been able to roll this out to a number of sites and have been able to completely control the menu, the meta boxes, the custom post types, and more all through the use of the config file without actually having to change variations of the code all over the place.

Have You Done This?

For a plugin that’s installed across a variety of site handled by a technical manager, I’ve found this solution to work out well. I wouldn’t say that this is something that I’d, you know, ship into the WordPress Plugin Repository.

Even still, for those who build plugins (or themes or other WordPress related work) for a living, when are your thoughts on doing something like this?

As much as I’m finding it to be useful, I’m interested in the feedback. Hit me.

14 Replies to “Adding Plugin Config Files to WordPress”

    1. I don’t like the idea of plugin specific config files, but I don’t see any problem in using the wp-config.php for controlling settings.

      Agreed.

      A lot of this, though also depends on the client, I think. If they are comfortable editing settings and hopping around from the installation root then over to the plugin and all of that, then go for it!

      Of course, now I’m just splitting hairs between wp-config.php and and a plugin config file.

      At some point, I think it comes down to either having a settings page or storying the values in a file.

  1. Not a huge fan of the concept, but my last plugin I made sure it worked out of the box with absolutely no settings for the user.

    Some users were turned off by the approach, but most appreciate the plug and play.

    I think overridable filters are nice and you could include an mu-plugin file for the overrides if a user is inclined.

    1. Not a huge fan of the concept, but my last plugin I made sure it worked out of the box with absolutely no settings for the user.

      Love hearing that last part – major respect for themes and plugins that “just work” with as few options as possible.

      I think overridable filters are nice and you could include an mu-plugin file for the overrides if a user is inclined.

      This is a good point as well, especially if the person working with the code is an experienced WordPress developer.

  2. I know that some plugins have added the option to add some settings to the wp-config.php for security reasons. e.g. http://wordpress.org/plugins/amazon-s3-and-cloudfront/

    I feel that if you added all of the settings in wp-config.php then you loose the overview.

    BTW – There is a plugin that lets you have all of the settings hard coded. https://timnash.co.uk/wordpress-hard-coded-options/

    One could just as well use filters and actions and let the developer change the setting with a site specific plugin.

    1. I don’t think Tom was suggesting changing core plugin files, but stashing the config file elsewhere, where it wouldn’t be wiped by a plugin upgrade, like in the root directory, where wp-config.php is stored.

      My suggestion above, was to actually use the wp-config.php file itself, since it’s already there and won’t confuse people by having random files dotted around.

      1. Some plugins already do that: w3 total cache , mu domain mapping.
        I would fear bloat of the wp-config.php And the naming of the constants could get ugly and unclear.
        apply_filters should prevent that. And devs are free to put that in a separate single file plugin or the themes functions.php

      2. I don’t think Tom was suggesting changing core plugin files, but stashing the config file elsewhere, where it wouldn’t be wiped by a plugin upgrade, like in the root directory, where wp-config.php is stored.

        Yep – right.

    2. I would rather put those settings in an array/object and allow those values to be changed by apply_filters.

      This works well for those who are WordPress developers and understand hooks – but there are some front-end developers who understand changing constant values, but not writing a custom hook.

  3. There’s a lot of people referring to publicly downloadable plugins here. I wouldn’t use a config file (with constants) for those, since it rules out having different configurations for sites on multisite. I’d use filters instead, so that people can apply per site settings.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.