Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: The obvious way of adding preferences to one's plugin
cXc wrote:
I’m trying to understand how set_prefs work now, are they just core functions that do the same thing as what I’ve put in my plugin?
set_pref() is a core function that inserts or updates a row in txp_prefs.
Are the 3 if blocks the same in the following blocks?
AFAICT, yes. FYI, when calling a function that has default values in the function signature, as does set_pref(), you don’t need to duplicate the signature, as in your first version. You just need to provide the values, and only those that differ from the defaults. So:
set_pref('cxc_tpl_current', '', 'publish', 2)and
set_pref('cxc_tpl_current', $dir, 'publish', 2)As far as get_pref() goes do I even need it since I’m using global prefs; in the function, and I can get it much easier just using the standard $prefs[‘cxc_tpl_current’] call?
The feature of get_pref() is that it returns a default value if the pref isn’t set. So, for instance:
the third if is there because without it I get a notice when I first access the “Templates” tab
So use get_pref('cxc_tpl_current') there. If the pref isn’t set, it returns an empty string. No notice. (BTW, I misread && !($prefs['cxc_tpl_current'] = '') as && !($prefs['cxc_tpl_current'] == ''), because the first is not a construct I would use. I’m all for concise and clever code, but within limits.)
In general I think it’s best practice not to alter Txp globals, i.e. $prefs['foo'] = 'bar';. Probably doesn’t matter with this plugin, but I think it’s a bad habit. What I tend to do instead is put the prefs I need into an array, say global $cxc_tpl_prefs;, and use that throughout the plugin.
Will I need to add a remove pref option?
It’s good practice to offer some way of doing a clean uninstall for any plugin that adds stuff to the DB. Admittedly, a lot of plugins fail to clean up after themselves in this way. At the least, you should have install/uninstall instructions in the plugin help file that tell users about the pref. In your case, it would be a nice touch to just automatically delete the pref if the plugin itself is deleted, by setting the appropriate flag in the plugin manifest:
defined('PLUGIN_LIFECYCLE_NOTIFY') or define('PLUGIN_LIFECYCLE_NOTIFY', 0x0002);
$plugin['flags'] = PLUGIN_LIFECYCLE_NOTIFY;then registering a callback:
register_callback('cxc_tpl_uninstall', 'plugin_lifecycle.cxc_templates');and having cxc_tpl_uninstall() remove the pref. (I’m assuming the plugin is named ‘cxc_templates’.)
Should I use the set_prefs() function instead of what I’m using now?
I would. For one, it’s a shorter line of code, as I show above. For another, using a built-in function is more likely to be future-proof. If, for example, Txp adds another column to txp_prefs in a later version, set_prefs() will be updated and your plugin will probably still work as expected.
I also notice that the set_pref() is also capable of setting the user column based on the backend user so I’m thinking maybe that is something I had overlooked.
No, I don’t think you want this to be a per-user preference. That’s used for things such as how each user likes the Write panel to appear.
Code is topiary
Offline
#14 2011-01-13 14:10:21
- ~cXc~
- Plugin Author
- Registered: 2010-12-27
- Posts: 39
Re: The obvious way of adding preferences to one's plugin
Thank you for such a helpful post Jeff I think you answered almost every question I had or would have except for 1 ;)
Is $plugin[‘flags’] = PLUGIN_LIFECYCLE_NOTIFY; the same thing as $plugin[‘flags’] = 2; that was set by ied_plugin_composer?
… cause that’s what I have now and it seems to be working properly, I decided to remove the pref on disable or delete since if they disable my plugin and use one of the other templates plugins it will give a false result anyway and just in case they delete without disabling first it still gets removed ;)
I’m not sure whether too leave the pref creation in by page access or place it in install uninstall, I wanted to leave it in page access cause I can output errors whereas when I do it the other way it messes with some admin template layouts if I use error messages.
Last edited by ~cXc~ (2011-01-13 14:13:23)
Offline
Re: The obvious way of adding preferences to one's plugin
cXc wrote:
Is $plugin[‘flags’] = PLUGIN_LIFECYCLE_NOTIFY; the same thing as $plugin[‘flags’] = 2; that was set by ied_plugin_composer?
Yes. For now. But I think it’s better to use the PLUGIN_LIFECYCLE_NOTIFY constant. For one, it makes it makes your code self-documenting. For another, if for some reason the value ever changes and is defined elsewhere, your plugin will still install correctly.
Code is topiary
Offline
Re: The obvious way of adding preferences to one's plugin
cXc wrote:
… just in case they delete without disabling first it still gets removed ;)
NB: when a plugin is deleted, both the disabled and the deleted event are fired in sequence. We do not assume that users will disable plugins prior to deletion.
Offline