Proposal for namespaced theme-dependant configs

This is a proposal for extending the config properties for themes package.json.

Why is this useful?

• As a developer I can just declare the configs I want to use and then use them, leaving it to the user to configure them in the admin backend.
• As a user I want to configure my theme instead of editing files, which is a bad approach in the first place as it defies maintainability and upgradeability (now I have to edit my files in the “uno-zen” theme in order to select and configure the social accounts I want to link)

Envisioned developer workflow

As a theme developer I want to be able to use central user configuration, i.e. for the social group. Currently there is a blog config for a facebook profile. As a developer instead of using @blog.facebook, I would like to use @config.social.facebook property. This by itself does not bring a lot of value, but bear with me for a moment. Say I also want to do something really nice like the uno-zen theme which allows for 37 different social icons. I could i.e. check a reddit account by checking the @config.social.reddit property.

configs in theme

How would ghost know about such a property? Well, it could be as simple as a list or object in the theme’s package.json. Think something like

{
  // ...
  "config": {
    "social": [
      "reddit", "stumbleupon", "github", "github_org", "google-plus"
    ]
  }
}

Note: A list would obviously be the easiest, an object could carry meta information about the config though (i18n tho …).

Notice the github_org config? This could be something that is just interesting to this theme: Imagine a blog for an open source project where they have a primary repo, but also a nice collection of other useful libraries. Or anything, matter of fact is there is no constraint on the number or names of the items, they will be represented as “Config for Stumbleupon”, “… Github”, “… Github Org”, “… Google Plus” (notice the conversion to title case).

Other configs

This approach can of course be extended to other configs, given that there is a config area (e.g. “Publication Info”). One useful other example would be including disqus comments or not, something which is commonly solved by editing files as well.

[ashleysommer]

If we now allow defining any key in this config object, the Ghost team has no chance to add a new key, because it could be used from a theme developer already. IMO there needs to be a clear differentiation between theme developer specific/custom config and Ghost config properties.

That is why this proposal specifically calls for “namespaced configs”, that is, there will be no collisions of keys because each config set will exist in its own namespace under config.

[ashleysommer]

This issue is the number one reason I abandoned Ghost back in January. Dev’s have no interest in implementing features which users and theme builders obviously want and need.