Theme prefs plugin

Bloke · 2015-06-09 09:42:44

NicolasGraph wrote #291440:

I have to edit it for once during the design process, but after that, the whole install is just a pasting and enabling work.

Yes, and that first edit process is something I’d like to design out of the system as it makes plugin upgrades difficult. I’d far rather you upload the vanilla plugin and a “definition” file alongside it, or preferably in some well-known location, that the plugin reads to create/maintain the prefs.

I’m not altogether familiar with rah_flat’s internal workings and its directory structure, so if someone would like to suggest a suitable location for a pref definitions file that oui_prefs could read, I’ll make it happen.

NicolasGraph · 2015-06-09 10:12:14

Bloke wrote #291442:

Yes, and that first edit process is something I’d like to design out of the system as it makes plugin upgrades difficult. I’d far rather you upload the vanilla plugin and a “definition” file alongside it, or preferably in some well-known location, that the plugin reads to create/maintain the prefs.

I’m not altogether familiar with rah_flat’s internal workings and its directory structure, so if someone would like to suggest a suitable location for a pref definitions file that oui_prefs could read, I’ll make it happen.

Ok Stef, of course it would be nice to keep the prefs definition outside the plugin. I now just wondering if it needs to be linked to rah_flat, as it could also be used with sed_cleaner. Just wondering…

Bloke · 2015-06-09 10:35:49

NicolasGraph wrote #291443:

I now just wondering if it needs to be linked to rah_flat, as it could also be used with sed_cleaner.

Sure. Doesn’t matter where it is. I just need to make sure the plugin can find it. If you suggest a suitable location I can put it there.

I’d rather not make the location itself a preference! But then, equally, I don’t want to have to hard-code it and find that it’s not a good location for most people’s workflow. Since it’s just a JSON (text) file, I’d prefer to keep it outside document root so it’s not web-accessible.

Any reasonable suggestions for a location considered.

uli · 2015-06-09 11:32:49

NicolasGraph wrote #291440:

install and enable sed_cleaner;

_{Pardon for putting in my 2 cents although I’m a rather sporadic reader of this topic and as such might not have understood the essence.}

In his introducing post for sed_cleaner, net-carver wrote #250247:

Removes default content (comments, links, files, articles, images & categories of all kinds)

So this is a theme for completely new websites? I asked myself how would a user theme his existing content?

Bloke · 2015-06-09 11:44:33

uli wrote #291447:

how would a user theme his existing content?

The plugin spawned from this thread is merely a way to add prefs to the Preferences panel. The difference being that, instead of defining the prefs using the admin-side UI, the site designer sets the preference groups, prefs and permissions in an external file.

For people setting up a new site, this plugin can be auto-installed (via sed_cleaner) to inject preference values ready for other admin users to tweak the preference values to taste later. Regular admin-side users do not have control over the prefs that are created, only their values.

Likewise, for people who use something like rah_flat or cnk_versioning to design their sites, the plugin can be installed in a regular manner, and then allows them to set up / edit / change / delete the preference groups, prefs and permissions for the ongoing maintenance of the site via manipulation of the external JSON configuration file. That means the config file can be put under version control if you wish.

It works similar to adi_variables in that it makes values available as <txp:variable>s and the values can be set via an admin-side panel, but it’s more compatible with an external / versioning workflow. Unlike adi_variables, it also sets the values as preferences, for persistence. It merely makes these prefs available via <txp:variable> as a convenience.

An example might be a preference for a per-author theme background colour, which an admin-side theme could read directly from the prefs. Or some variable for customising the site templates that can be output in a Page/Form using <txp:variable> / <txp:if_variable>. In that manner it can be used for “themeing” a front-side template, to some degree.

Does that kind of make sense?

[Edited for clarity]

Last edited by Bloke (2015-06-09 11:48:43)

NicolasGraph · 2015-06-09 11:58:35

Bloke wrote #291448:

Does that kind of make sense?

You are better than me to explain the sense of this thread!

Bloke wrote #291444:

Any reasonable suggestions for a location considered.

You could use the same path as the rah_flat prefs folder but the rah_flat_path is a pref and it can be customized. Beside that, sed_cleaner use the Txp files folder to import everything. At the moment ../oui_prefs is maybe the simplest location to put the .json file in?

Bloke · 2015-06-09 13:14:52

NicolasGraph wrote #291449:

the simplest location to put the .json file in

Had a brainwave. I’ve set it to default to the /files folder, which I wouldn’t recommend out of the box, but at least you have control over it with .htaccess. If you prefer, you can also set a constant in your config.php to override it:

define('SMD_PREFSET_CONFIG_PATH', '/path/to/wherever');

How’s that?

uli · 2015-06-09 13:26:30

uli wrote #291447:

So this is a theme for completely new websites?

Sorry for my sloppy wording! Of course I know that this topic (and specifically this preceded post) is not about a theme but about means of installing/maintaining a theme. Fire me should it turn out I deteriorate that badly ;)

Thanks, Stef, makes sense, totally. Stopping by here now and then, I was hoping for an answer to some new users’ question “How can I give my website a new look?”, maybe a combination of existing and new plugins.

Edited for adding the link. And wording ;)

Last edited by uli (2015-06-09 13:32:31)

NicolasGraph · 2015-06-09 13:44:17

Bloke wrote #291451:

Had a brainwave. I’ve set it to default to the /files folder, which I wouldn’t recommend out of the box, but at least you have control over it with .htaccess. If you prefer, you can also set a constant in your config.php to override it:

define('SMD_PREFSET_CONFIG_PATH', '/path/to/wherever');...

How’s that?

It seems to be a good compromise. Is it possible for you to tell why and how we should “hide” .json files? rah_flat on his side use an access key.

Bloke · 2015-06-09 13:51:50

NicolasGraph wrote #291453:

why and how we should “hide” .json files?

If there’s no sensitive data (no default values athat leak information) then there’s no reason to hide it. Although it might be a good idea anyway so nobody can see your pref definitions if they visit the file from their browser.

If the config file’s in your /files directory, a rule in an .htaccess file like this ought to do it:

Options -Indexes
RedirectMatch 403 smd_prefset.json

NicolasGraph · 2015-06-09 13:59:12

Ok, thanks Stef! I’ll be happy with the coming smd_prefset!

jakob · 2015-06-09 15:04:06

The separate prefs file in definable path is a good idea. It’s important that it doesn’t tangle with another plugin or gets cleaned out inadvertently.

the /files folder

Doesn’t sed_cleaner clear up the /files folder after use? It says it “remove[s] the contents that it loads from the files directory…” but I’m not sure precisely which files that will effect. It does also say it leaves other files alone. On second thoughts, is it actually a problem if that happens, as theoretically the json is no longer needed after the prefs are setup?
The /files directory is really for user uploaded content. I exclude that folder in deploy syncing, so user content does not get mixed up with the repo. But the prefs_config json is the kind of settings file you might want to have a record of in your repo for later use/installation.
If it does survive sed_cleaner and continues to exist in the /files folder, will Textpattern’s Files pane flag it as a file you’ve not yet uploaded? Normal users see that, I believe.

Maybe a /config directory or a config_custom.json file or something.

You could use the same path as the rah_flat prefs folder

rah_flat uses ../templates by default, but makes it definable in a pref so (depending on your server folder structure) you can put it into the level below – ../../templates – and take it completely outside the web root. It looks in all the folders within that folder as shown here, so placing something in a /templates/prefs folder inside that is bound to cause problems because rah_flat will look in there too.

… how we should “hide” .json files … rah_flat on his side use an access key.

I’m not sure that that last part is true. Please correct me if I’m wrong, but I don’t think rah_flat protects the /templates directory in any way.

The “access key” is a public callback hook URL that triggers an update / resync of the templates when the site is in “live” status. On the one hand, that saves the dance of switching back into testing, reloading the front end, and then switching back to live. More importantly, it can be called as a post-deploy hook on a running system after updating the flat files. The complex key is just to make it hard to discover.

I asked myself how would a user theme his existing content?

I think uli’s ~~question~~ concern is still valid, especially if people see this / present this as a way of packaging themes. It’s fine for startup scenarios, but it will cause major grief if people don’t read carefully and inadvertently reset their installation.

I don’t think that editing prefs values via the Txp interface goes against the idea of managing flat files when these prefs are dedicated to users.

Sure, I agree with you, and also totally understand what you want to achieve in the end. I meant it the other way around: rah_flat facilitates a workflow where choose to use a file editor to make changes, overriding the admin area. That basic principle is broken when changes you make to a file no longer have an effect on the site. Then again, I can’t think of a good reason why you’d want to set a pref permanently, as it’s then no longer a “preference” but a “variable” or a constant (which is probably why I’ve not used that bit of rah_flat before). Have you tried settings prefs with rah_flat?
I’d be interested to know if sets up prefs once for later use or whether it resets them to whatever is specified in the flat file like it does with forms, pages, etc. I have a feeling Jukka probably thought that through…

Textpattern CMS

Textpattern CMS support forum

#49 2015-06-09 09:42:44

Re: Theme prefs plugin

NicolasGraph wrote #291440:

#50 2015-06-09 10:12:14

Re: Theme prefs plugin

Bloke wrote #291442:

#51 2015-06-09 10:35:49

Re: Theme prefs plugin

NicolasGraph wrote #291443:

#52 2015-06-09 11:32:49

Re: Theme prefs plugin

NicolasGraph wrote #291440:

#53 2015-06-09 11:44:33

Re: Theme prefs plugin

uli wrote #291447:

#54 2015-06-09 11:58:35

Re: Theme prefs plugin

Bloke wrote #291448:

Bloke wrote #291444:

#55 2015-06-09 13:14:52

Re: Theme prefs plugin

NicolasGraph wrote #291449:

#56 2015-06-09 13:26:30

Re: Theme prefs plugin

uli wrote #291447:

#57 2015-06-09 13:44:17

Re: Theme prefs plugin

Bloke wrote #291451:

#58 2015-06-09 13:51:50

Re: Theme prefs plugin

NicolasGraph wrote #291453:

#59 2015-06-09 13:59:12

Re: Theme prefs plugin

#60 2015-06-09 15:04:06

Re: Theme prefs plugin

Board footer