Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Plugin preferences tab
wet wrote:
Commited plugin preferences
Nice, thanks. I’ve added support for this to the plugin composer so people can tick a box if they want their plugin to have $plugin['flags'] set in the exported template. As and when the number of flags expand, the number of checkboxes can grow accordingly and everything’s bitwise OR’d together.
I’m a trifle confused on the actual usage though. Is there a dedicated tab we should use for all plugin prefs? Or are they designed to be tab-less? It seems like there’s not much point registering a new tab for each plugin’s prefs or there’ll end up being more tabs, and I think gomedia’s original request was to reduce tab clutter by consolidating plugin prefs.
I figured there was going to be, like, one page with all interested plugin prefs listed on it… e.g. event=prefs&step=plugin_prefs and then each plugin would have its own section of that page and a handful of parameters to edit in a table. Dunno if that would work though.
So far, if I want to add some prefs to smd_where_used:
add_privs('plugin_prefs.smd_where_used','1,2');
register_callback('smd_wu_prefs', 'plugin_prefs.smd_where_used');works a treat and I can then paint the interface on the screen, albeit with only the top row of tabs visible. Is that how you envisaged it being used?
When the prefs are saved, would you prefer returning the user to the plugins tab with a “prefs saved” message? Or keep the user on the prefs page (with associated ‘saved’ message) and supply a separate link back to the plugins tab? I have added a link to this event directly from the plugin composer tab so people can visit this section during testing… in that case it might be better to return control to the composer’s tab instead, which implies some kind of ‘where was I called from’ memory.
It seems like the wrong approach to add, for example:
register_tab('admin', 'plugin_prefs.smd_where_used', 'WU Prefs');to stick a permanent tab under ‘admin’ just for this plugin. I can do that already, without this feature.
Apologies if this question seems naive, but I think I’m missing the point of this commit somewhere ;-) Please advise on the best practice, thanks.
Last edited by Bloke (2009-02-24 21:05:21)
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: Plugin preferences tab
Bloke wrote:
Or are they designed to be tab-less?
I don’t think it requires a separate tab.
and I can then paint the interface on the screen, albeit with only the top row of tabs visible. Is that how you envisaged it being used?
Exactly. Eventually we could come up with a more suitable decoration for plugin prefs. Suggestions?
Or keep the user on the prefs page (with associated ‘saved’ message)
Depends. Some plugins will need only a very limited user interface with little interaction, so there’s little use of keeping users on the plugin_prefs page once they have POSTed, while other plugins might require more elaborate interactions and therefore keep a user on the prefs page while offering a link back to the plugin tab as a convenience.
Offline
Re: Plugin preferences tab
wet wrote:
Depends. Some plugins will need only a very limited user interface with little interaction, so there’s little use of keeping users on the plugin_prefs page once they have POSTed, while other plugins might require more elaborate interactions and therefore keep a user on the prefs page while offering a link back to the plugin tab as a convenience.
Needing some help with this: what is the best way of saving changes to the plugin but returning the user directly to the main plugin list?
Code is topiary
Offline