Proposal for namespaced theme-dependant configs

brachetti commented 6 years ago

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.

am0wa commented 6 years ago

Adding comment of my ticket here as these two were considered as duplicates:

custom variables, that developers might use across their templates in a simple convenient way e.g. {{@config.custom.social.instagram}} or through the dedicated helper {{@misc.instagram}}

Steps to Reproduce

open theme package.json
add any property in "config": { "foo": "bar" }
access it in template {{@config.foo}}

Actual: Only {{@config.posts_per_page}} would be passed

Expected All properties mentioned in dedicated scope has to be available

Technical details:

Ghost Version: 1.4.1
Node Version: 6.10.0
Browser/OS: All

ashleysommer commented 6 years ago

I came here to propose this exact feature request, only to find two other users have already made this same proposal.

I see it as a critical feature to allow templates/themes to be less hard-coded and more configurable.

I noticed this Issue is tagged "Needs Info". What info is required?

nehalist commented 6 years ago

Any news on this?

oshibka404 commented 6 years ago

@kirrg001 I see there a test explicitly checking that only allowed properties are exposed to @config. Why is it needed at all? Why don't let a developer list any properties in "config"? Can it be kinda dangerous?

kirrg001 commented 6 years ago

Can it be kinda dangerous?

No, not dangerous. The Ghost team uses this @config object to create common config keys (e.g. posts_per_page). 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.

I see your point, it would be great to offer the ability to define theme configurations, which are then available in the theme.

This is a design decision and needs more thoughts. I've added this issue to our backlog 👍

Thanks for your report and inputs.

ashleysommer commented 6 years ago

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.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

jericho1ne commented 5 years ago

Still no way to pull in custom objects? This is very problematic.

johackim commented 4 years ago

This is a good suggestion !

There is input for facebook and twitter urls but not for mastodon, reddit, ect...

So the package.json would be a good emplacement to add this custom urls IMO.

I agree with this PR.

ashleysommer commented 4 years ago

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.

TryGhost / Ghost