Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Theme prefs plugin
jakob wrote #291456:
Doesn’t sed_cleaner clear up the
/filesfolder 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
visibilityof-1to 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_namefield 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)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Theme prefs plugin
jakob wrote #291456:
Doesn’t sed_cleaner clear up the
/filesfolder after use?
No, it clears up only the files used by the plugin. Tested
rah_flat uses
../templatesby 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/prefsfolder 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
/templatesdirectory in any way.
I think you are right. I misunderstood the sense of the key.
I think uli’s
questionconcern 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)
Offline
Re: Theme prefs plugin
jakob wrote #291456:
I think uli’s
questionconcern 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)
Offline
Re: Theme prefs plugin
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?
TXP Builders – finely-crafted code, design and txp
Offline
Re: Theme prefs plugin
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Theme prefs plugin
Bloke wrote #291463:
Regarding the post-install system, yes that would work for new setups, but as it only gets run during the actual
/setupor 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)
Offline
Re: Theme prefs plugin
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Offline
Offline
Re: Theme prefs plugin
NicolasGraph wrote #292396:
Is
smd_prefsetusable?
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Theme prefs plugin
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.
Offline
Re: Theme prefs plugin
@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.
Offline