Plugin preferences tab

Mary · 2009-02-17 00:33:15

Martin: Because plugins are not loaded on the plugins tab. This is so that plugins don’t even try to monkey with the plugins page.

wet · 2009-02-17 10:46:22

I’ve sent a patch around, see http://lists.textpattern.com/mailman/private/txp-dev/2009-February/000874.html.

wet · 2009-02-19 10:01:45

To sum up the discussion on the txp-dev mailing list so far:

The patch looks reasonable to plugin authors.
Open a few bits of the flags column up for a plugin’s private use, save the rest for core (e.g. 0x0fff).
Investigate the possibility of events firing at the plugin install and delete moment.

graeme · 2009-02-19 10:34:49

wet wrote:

To sum up the discussion on the txp-dev mailing list so far:

The patch looks reasonable to plugin authors.

Open a few bits of the flags column up for a plugin’s private use, save the rest for core (e.g. 0x0fff).

Investigate the possibility of events firing at the plugin install and delete moment.

Patch does look good. One concern regarding the events on install/delete. Couldn’t a plugin potentially mislead the user (hijacking the code/help preview) to what they are installing or stop them (txp_die() or just bad coding) from deleting a plugin? Events on activate and deactivate might be a safer option.

Mary · 2009-02-19 14:19:46

It all depends upon how it is implemented. I assumed that install wouldn’t get run until after the plugin is actually inserted in the database, not before/during preview. But, on activation is a good idea, since then a user could read the plugin help first and possibly decide they didn’t want to install the plugin after all, and not have their db tampered with.

On de-activate might be stickier. If they’re just de-activating and not uninstalling, that would mean they may want to re-activate it later and depending on what you’re using the event to do (like mess with the db) might not want that stuff removed just yet.

There’s a question: what do we all want to use that for?

For myself, modifying the database is what I was originally thinking of. But perhaps there are others that would want to do something else.

One thing that occured to me just now that you might want to further nudge users to read the plugin’s help doc. But then, maybe that’s something that the core should really do?

e.g, if help contents are detected:

You’ve successfully installed ext_plugin_name! Now "read the documentation":link to learn how to use it.

wet · 2009-02-19 16:42:45

Mary wrote:

One thing that occured to me just now that you might want to further nudge users to read the plugin’s help doc. But then, maybe that’s something that the core should really do?

Rather not, at least not for me. This would be the first thing ever which Textpattern would enforce.

graeme · 2009-02-19 16:43:22

Mary wrote:

It all depends upon how it is implemented. I assumed that install wouldn’t get run until after the plugin is actually inserted in the database, not before/during preview. But, on activation is a good idea, since then a user could read the plugin help first and possibly decide they didn’t want to install the plugin after all, and not have their db tampered with

On de-activate might be stickier. If they’re just de-activating and not uninstalling, that would mean they may want to re-activate it later and depending on what you’re using the event to do (like mess with the db) might not want that stuff removed just yet.

Un/install or de/activate, I think it should be clear what’s about to happen – people are used not worrying about crud being added to the database from the plugin tab. Some sort of message/warning would be good if a plugin has registered a callback which will be run if I click.

There’s a question: what do we all want to use that for?

For myself, modifying the database is what I was originally thinking of. But perhaps there are others that would want to do something else.

Same here installing tables etc… MLP uses a wizard tab to do a number of installation/uninstall steps and gives the user visual feedback on what the pack has done. So, and bear in mind I just thinking out loud, maybe instead of defining callback events plugin authors could define install steps which TxP uses to provide a standardised “wizard” UI to the user?

One thing that occured to me just now that you might want to further nudge users to read the plugin’s help doc. But then, maybe that’s something that the core should really do?

Yes, or nudge users to install a required dependency…

Mary · 2009-02-19 23:55:52

This would be the first thing ever which Textpattern would enforce.

I wasn’t suggesting that the entire ui was locked out until they viewed the help doc. I was suggesting a prominently placed, one-time message on the page. Once the user clicked something else, the message would disappear.

…people are used not worrying about crud being added to the database from the plugin tab…

Some sort of message/warning would be good if a plugin has registered a callback which will be run if I click.

I agree that large modifications shouldn’t be done silently. But some plugins already do, so it’s not like we’re creating a new problem.

We already have a plugin preview before install, so it’s assumed if the plugin got past that point, it is trusted.

Depending on how this would work, a plugin author himself could show a warning to the user before doing major work on the database (altering structure or adding new tables). That way it’s still optional, so if you’re just adding some prefs, for example, the user doesn’t have to be bothered.

wet · 2009-02-24 08:59:26

Commited plugin preferences. Plugin install and delete events are yet to be beaten into shape. Please open a separate thread if you wish to contribute.

Bloke · 2009-02-24 21:00:42

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)

wet · 2009-02-25 12:43:41

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.

jsoo · 2009-09-02 19:53:21

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?

Textpattern CMS

Textpattern CMS support forum

#16 2009-02-17 00:33:15

Re: Plugin preferences tab

#17 2009-02-17 10:46:22

Re: Plugin preferences tab

#18 2009-02-19 10:01:45

Re: Plugin preferences tab

#19 2009-02-19 10:34:49

Re: Plugin preferences tab

#20 2009-02-19 14:19:46

Re: Plugin preferences tab

#21 2009-02-19 16:42:45

Re: Plugin preferences tab

#22 2009-02-19 16:43:22

Re: Plugin preferences tab

#23 2009-02-19 23:55:52

Re: Plugin preferences tab

#24 2009-02-24 08:59:26

Re: Plugin preferences tab

#25 2009-02-24 21:00:42

Re: Plugin preferences tab

#26 2009-02-25 12:43:41

Re: Plugin preferences tab

#27 2009-09-02 19:53:21

Re: Plugin preferences tab

Board footer