Provide a way so that theme authors can make their themes configurable.
For example: A theme might offer the possibility to optionally show a tag cloud.
There should be a way so that the theme user can easily configure this.
And actually there already would be such a way. It’s just simple forbidden in the current code. There already is a config section in the themes package.json But the code filters and only allows the attributes posts_per_pageas documented and image_sizes . Themes can directly access these variables as `{{@config.posts_per_page}}
Why restrict this to just these two variables. Allow any variables for theme authors.
You do receive the same feature request multiple times. Each time given with a elaborate description of the use case. (By me and also the former authors in the PR that you linked).
The Feature request can be implemented by deleting two lines of code.
And you dare to ask WHY ?!?!?
(To repeat the requirement: To give theme authors a way of easily making their theme configurable)
@DoogieMuc I’m not sure if this will help or not, because (not being a coder) I don’t yet fully understand the pertinent infrastructures of the code to this issue. Having said that, I am very pleased to find and use the many examples of existing themes that do provide what (I think ) you are describing.
These themes provide for the setting of variables as bits of JavaScript in the (Site, Page, and Tag) Header Code Injection areas in the Admin UI.
One such example is the Fizzy Theme:
I have found many others, and would highly value and appreciate a tutorial on the best way to implement this method.
Thank you, this is actually a nice idea.
Sadly it’s only a workaround. But one that fits for most use cases.
The “Code Injection” of the admin UI injects code into the client side javascript. This code will be executed at the client, when a visitor visits the page. This code can hide elements of the page. But still those elements need to have been loaded.
For hiding a small tag cloud that’s ok. It doesn’t matter if that few bytes are loaded for nothing and then hidden.
We’re looking at ways to support theme settings natively in Ghost watch this space. No roadmap or timeline yet, but we’re listening. Thanks for your patience. We often take a little longer than usual to implement things, because we spend more time to try and make sure we really get the underlying architecture right.
If you rush features with a poorly executed fundamental architecture and then allow a developer ecosystem to be built on top of it, well that’s how you end up with ants WordPress
) you are describing.
watch this space. No roadmap or timeline yet, but we’re listening. Thanks for your patience. We often take a little longer than usual to implement things, because we spend more time to try and make sure we really get the underlying architecture right.