Theme prefs plugin

Bloke · 2015-06-09 15:41:24

jakob wrote #291456:

Doesn’t sed_cleaner clear up the /files folder after use?

Hehe, maybe. That could be potentially annoying in this case!

The config file can live anywhere really, I just need to know a good default location. I’ll shift it, uhhh, somewhere.

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

Textpattern itself could really do with having a standard folder for customisations. You can put post-install scripts, named to a specific pattern, in the /update folder, and you can edit your config.php which is untouched by upgrades, and you can define a plugin cache directory. But after that we don’t seem to have any standard way to put stuff like this. Granted it’s outside the scope of Txp itself… sort of… because it wouldn’t use it, but having a dedicated, secure folder tucked away for config things seems like a nice idea. Thoughts?

It’s fine for startup scenarios, but it will cause major grief if people don’t read carefully and inadvertently reset their installation.

You mean the proposed plugin could reset something? How so? Or do you mean by switching over to a versioned workflow (which I understand has the potential to trample on your DB stuff!)

That basic principle is broken when changes you make to a file no longer have an effect on the site.

I see where you’re coming from, and that is indeed a concern at the back of my mind.

Regarding the specific notion of setting up prefs in this case, surely this goes hand-in-hand with (re)designing a site? If you’re adding a pref to allow a client to configure, I dunno, a login name and password to a third party resource (like we did recently, jakob) then the site template or a plugin itself will use <txp:variable name="third_party_login" /> somewhere to pass that value on. If the login credentials change, the admin has the ability to do so without sullying themselves with trawling code or wading through a Form chock full of other settings.

If the third party then decide to add a secret value to their login process, you’ll need to provide a field for it. So the site designer would configure one in the config file and it’d get added automatically next time you visit the Prefs panel. Any such changes made to the config file won’t affect the existing user/pass prefs, nor their values because they already exist.

So the config file does affect the DB but will not have an effect on the site until you alter your template to pass on the <txp:variable name="secret" />. The site designer would need to do that anyway as part of the Page/Form changes in the versioned file system, otherwise the site won’t work any more with the third party service. After that, any changes to the secret key can be managed by regular (client) admins from the Prefs panel.

So the plugin does read the config file every time and populates new prefs with default values if they don’t exist, but it won’t touch existing values. The only time the file affects existing values is if you:

specify a visibility of -1 to indicate you want that pref to be deleted (could use anything here, I’m tinkering with using numbers or explicit names to see which is best).
specify that you’ve renamed a pref. I’ve no idea how best to do this, probably by specifying an old_name field or something like that.

Maybe there’s some facet of this process I’ve missed, not being a user of rah_flat and such like. Insights welcome, especially on whether there’s even a need for this plugin at all if rah_flat does prefs natively in a way that NicolasGraph can hook into.

[Edited for clarity]

Last edited by Bloke (2015-06-09 15:46:52)

NicolasGraph · 2015-06-09 16:05:36

jakob wrote #291456:

Doesn’t sed_cleaner clear up the /files folder after use?

No, it clears up only the files used by the plugin. Tested

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.

I’m not fluent but I think that is more or less what I meant when I said : 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.

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.

I think you are right. I misunderstood the sense of the key.

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.

If I’m “people”, sorry. I’m confident (to much?) with forum users to read closely the thread they are interested with and I didn’t realize that it could “cause major grief” to anybody.

Have you tried settings prefs with rah_flat?

Yes and as I said, if I understand well (I think I do), it does not set prefs, it only affects existing prefs values like rah_flat_path. Look at the rah_flat_path.json file in the rah_flat folder.
I also had a problem using it with smd_tags but I’ll talk about it later if I can’t figure why.

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…

I didn’t look at that; I can’t say for now.

Edited to add links and correct typos :-/

Last edited by NicolasGraph (2015-06-09 16:50:09)

NicolasGraph · 2015-06-09 16:39:08

jakob wrote #291456:

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.

Reply is in my previous post but I’ve also edited this post to add a warning message.

Last edited by NicolasGraph (2015-06-09 16:40:32)

jakob · 2015-06-09 20:46:09

Sorry, I must apologise. I was the one polluting the thread and not choosing my words carefully enough. I don’t think any of this applies really to this theme prefs plugin you two have been building. I think it’s great and if it can effectively replace adi_variables (which I like and rely on a lot) for rah_flat use, then brilliant. The use case is clear to me.

Actually, my ‘worry’ (hopefully unfounded as you say) was triggered by what uli asked, and that is the power of sed_cleaner to both serve as a wonderful streamliner of getting to an “instant starting point” as well as a way of instantly resetting a site if not used with care. It is potentially usable to set up a txp installation with a blank front-end theme from scratch, so if the plugin gets packaged with themes offered online, it needs to be configured so that a user in a hurry to try out a theme doesn’t inadvertently wipe their own site. It happens (weirdly, also to those people who don’t have a backup…) If that’s not possible, then it should be labelled clearly. With ‘people’ I really meant ‘in future’ when this way of doing things might be out ‘in the wild’.

—-

Nicolas, thanks for clarifying both that:

sed_cleaner doesn’t clean out the json file from the /files directory.
rah_flat / prefs only affects existing prefs values.

I took a closer look, and it seems that rah_prefs compares the filename.json to see if matches a pre-existing pref and only safe_updates it from the flat file if it does. It also overwrites any user changes, so it’s like setting a permanent pref. Those both rule it out as a way of setting manual prefs on setup.

It threw an invalid json error (in debugging mode) when the json file was not usable, so probably not a good place to put the prefs config either.

I like the idea of a prefs config file in the way you suggest with a default value, that the user can overwrite and it won’t overwrite (it would be perfect for the situation we had recently).

I still think it would be better to keep it out of the /files directory. My preference would be either a config.file sitting alongside config.php and untouched by updates, or putting all that stuff in a /textpattern/config/* subdirectory (which might have knock-on effects).

You can put post-install scripts, named to a specific pattern, in the /update folder

Might that be useful here?

Bloke · 2015-06-09 21:01:50

jakob wrote #291462:

I still think it would be better to keep it out of the /files directory.

Upon further consideration, I concur. /files is for site content files in the same way /images is for site content images. I think site root as a default location makes sense, retaining the (highly recommended) option to move it using a define().

I do like the idea of a dedicated config directory, but fear it might be confusing to newcomers to have a config.php file in site root and ‘other’ config file(s) in a dedicated directory. If we did have such a location it’d be nice if all config files could go there, including config.php. Probably not going to happen any time soon though.

Regarding the post-install system, yes that would work for new setups, but as it only gets run during the actual /setup or upgrade process, it’s no good if you make changes to your prefs/variables (prefables??!) regularly as it’s only triggered on version updates.

NicolasGraph · 2015-06-17 06:45:20

Bloke wrote #291463:

Regarding the post-install system, yes that would work for new setups, but as it only gets run during the actual /setup or upgrade process, it’s no good if you make changes to your prefs/variables (prefables??!) regularly as it’s only triggered on version updates.

Could the enable/disable events imports the new prefs/variables instead of setup/upgrade?

Last edited by NicolasGraph (2015-06-17 06:46:26)

Bloke · 2015-06-17 08:48:34

NicolasGraph wrote #291590:

Could the enable/disable events imports the new prefs/variables instead of setup/upgrade?

Yes, but that would mean people running plugins out of a disk-based (plugin cache) system wouldn’t be able to play, as they don’t fire events. At the moment, the plugin checks the file every time the Admin->Preferences panel is visited, and makes any adjustments it finds.

NicolasGraph · 2015-06-17 15:34:01

Bloke wrote #291591:

At the moment, the plugin checks the file every time the Admin->Preferences panel is visited, and makes any adjustments it finds.

Clever idea…

NicolasGraph · 2015-06-30 13:48:11

Hi Stef, Is smd_prefset usable?

Bloke · 2015-06-30 19:47:31

NicolasGraph wrote #292396:

Is smd_prefset usable?

Erm, not quite, sorry. Got steamrollered into core stuff and the plugin is still awaiting completion. But since I now (finally, thanks to Bert’s persistence) see a way to bring themes to core iteratively and in a backwards-compatible manner, this plugin might well be dragged along for the ride. I’ll try and give it some thought later this week when I turn to kicking off the themes stuff in core.

NicolasGraph · 2015-07-01 06:49:08

Bloke wrote #292407:

I’ll try and give it some thought later this week when I turn to kicking off the themes stuff in core.

Ok, no worry, thanks for your work into core; it seems to move here and it’s a good thing.

NicolasGraph · 2015-10-23 16:04:22

@Stef, I don’t know if you worked on smd_pref_set but I found a way to set prefs/variables with a customized rah_flat from .json files. It is maybe better to keep only one plugin as this one can manage differents content types.

jakob · 2018-04-01 22:14:13

On my quest to bring some older plugins that are vital for several of my installations into the 4.7 epoch, this is another candidate, but I’m no longer sure what the state of play is, and therefore what to (try and) work on.

I have some sites with oui_prefs (I think this version) with my own variables defined in the plugin source, and other sites where I have used rah_flat/oui_flat’s pref/variable import capacity in my /templates folder.

There’s mention above in this thread of more advanced versions of oui_prefs (or smd_prefset) that store the definitions for site_variables in a file but I can’t find a more recent download, so I am not sure what I could look at bringing up to scratch.
The urgency in getting smd_prefset out probably got derailed by the advent of oui_flat’s ability to import prefs/variables from the flat file folder. Now that themes have been incorporated into txp 4.7, rah/oui_flat is effectively rendered obsolete. However the new themes mechanism doesn’t include prefs/variables (yet) so this bit of functionality is left unresolved (for my sites at least). It looks similar in principle to how rah_/oui_flat worked, so maybe it already includes a lot of the functionality needed for prefs/variables?

What’s the best way of proceeding?

Is it worth going back to oui_prefs/smd_prefset to fill this gap? That would be okay for my own current purposes (see below) – certainly for the moment.
Or is it better to hook into the new themes capacity to accommodate variables? I’m slightly wary of that for two reasons: a) if it was trivial, you/Nicolas would probably have already accommodated it. and b) I find it hard to grok the modularised OOP class-based code, probably because I don’t fully understand how they connect or how to hook into them, so am at a loss as to where to start.

In terms of usage, I see two potential situations:

Theme prefs, i.e. settings that a theme author might provide for customising certain aspects of the theme. That might be a colour picker, a functionality chooser/excluder, a font chooser, a logo ID#, etc.
It would make sense that these are provided with the theme, especially if the page/form code depends on them. As we’ve not had themes until now, I’ve not used this yet in my own sites.
Site variables, i.e. settings specific to a site but not necessarily a theme. These could be things like google_analytics_id, typekit_id, public url etc. I often have other things in here, for example a list of sections to include/exclude in the menu or sitemap, or a timeline of key dates for a course program that are used throughout the site e.g. application opening, submission deadline, etc. These things are specific to a site but not necessarily a theme. They could be saved elsewhere, e.g. alongside the config or in the doc root.

(Aside: I also looked at etc_variables, which I’d never seen before. It looks promising too but requires some modifications to run on v4.7 (prefs_id no longer exists) and provides a pane for defining the settings for prefs, e.g. choices for a dropdown, but the prefs themselves have to be manually added via phpMyAdmin or an SQL editor. If I’ve understood it correctly, the admin sets the prefs definition and another lower-level admin user can then change the value (in the new tab? not as a preferences panel?)

Bloke · 2018-04-02 08:31:45

You’re right, this was forgotten in the all the themes stuff.

In fact, themes can import prefs. They can import all manner of content – everything except files and images – from XML and .prefs files. We just haven’t formalised it as part of the themes implementation yet.

Take a look in the /setup directory, and pay particular attention to setup_lib.php, from line 131 onwards where it checks the datadir. Early next release that’s on our list to make into proper classes that anyone can use, possibly including core during theme import.

For now, copy the relevant bits of that code into a plugin and hack around with it to taste. Hook into the theme import/update callbacks and that’s all you should need to do.

Last edited by Bloke (2018-04-02 08:32:54)

etc · 2018-04-02 08:45:35

jakob wrote #310542:

I also looked at etc_variables, which I’d never seen before.

Oh, I have forgotten this one. You are right, it just allows admins to configure data options for various type of inputs (text, select, checkbox etc). Must be well outdated now, at least it will be when Stef’s input widgets land at master.

Textpattern CMS support forum

#61 2015-06-09 15:41:24

Re: Theme prefs plugin

jakob wrote #291456:

#62 2015-06-09 16:05:36

Re: Theme prefs plugin

jakob wrote #291456:

#63 2015-06-09 16:39:08

Re: Theme prefs plugin

jakob wrote #291456:

#64 2015-06-09 20:46:09

Re: Theme prefs plugin

#65 2015-06-09 21:01:50

Re: Theme prefs plugin

jakob wrote #291462:

#66 2015-06-17 06:45:20

Re: Theme prefs plugin

Bloke wrote #291463:

#67 2015-06-17 08:48:34

Re: Theme prefs plugin

NicolasGraph wrote #291590:

#68 2015-06-17 15:34:01

Re: Theme prefs plugin

Bloke wrote #291591:

#69 2015-06-30 13:48:11

Re: Theme prefs plugin

#70 2015-06-30 19:47:31

Re: Theme prefs plugin

NicolasGraph wrote #292396:

#71 2015-07-01 06:49:08

Re: Theme prefs plugin

Bloke wrote #292407:

#72 2015-10-23 16:04:22

Re: Theme prefs plugin

#73 2018-04-01 22:14:13

Re: Theme prefs plugin

#74 2018-04-02 08:31:45

Re: Theme prefs plugin

#75 2018-04-02 08:45:35

Re: Theme prefs plugin

jakob wrote #310542:

Board footer