Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#13 2009-02-16 14:40:57
- masa
- Member
- From: Asturias, Spain
- Registered: 2005-11-25
- Posts: 1,091
Re: Plugin preferences tab
I like that a lot.
Would be a great shortcut as at the moment you need to first click Admin (or other) to even get to the Extensions tab.
I never quite understood why Extensions was hidden while you’re looking at the Plugins tab.
Offline
#14 2009-02-16 17:53:27
- redbot
- Plugin Author
- Registered: 2006-02-14
- Posts: 1,410
Offline
#15 2009-02-16 20:42:15
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Plugin preferences tab
wet wrote:
Like so?
Looks good to me.
Offline
#16 2009-02-17 00:33:15
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Plugin preferences tab
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.
Offline
Re: Plugin preferences tab
I’ve sent a patch around, see http://lists.textpattern.com/mailman/private/txp-dev/2009-February/000874.html.
Offline
Re: Plugin preferences tab
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
flagscolumn 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.
Offline
Re: Plugin preferences tab
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
flagscolumn 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.
Offline
#20 2009-02-19 14:19:46
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Plugin preferences tab
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":linkto learn how to use it.
Offline
Re: Plugin preferences tab
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.
Offline
Re: Plugin preferences tab
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…
Offline
#23 2009-02-19 23:55:52
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Plugin preferences tab
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.
Offline
Re: Plugin preferences tab
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.
Offline