r3133/r3134

Bloke · 2009-03-10 15:42:09

Thanks wet, much appreciated. The notification system is going to be very handy. And I think even I’d struggle to fill 16Mb of code in a plugin. For now… ;-)

wet · 2009-03-10 17:47:04

I’d love to see field reports, maybe we’d have to adjust one thing or the other until this proves stable.

Bloke · 2009-03-10 23:10:13

wet wrote:

I’d love to see field reports

It’s holding up very well under the plugin composer so far. If I enable the notify flag from the composer’s interface, export the plugin then install it in another TXP, the composer’s prefs are automatically installed courtesy of the ‘installed’ step. Similarly, I’ve told it to blat the prefs on plugin deletion, which it does dutifully. Marvellous! Not tested enable/disable rigorously (no need for it in this particular plugin) but I’ve no doubt it’ll perform fine.

The only thing plugin authors need to be wary of is that the install/delete steps cannot fail, nor can they be interactive (e.g. upon deletion, offering the choice of keeping or removing the plugin’s prefs in case you are intending to upgrade but have been advised to remove the plugin first). There is no ideal way of indicating either situation to the user because pagetop() is called by the Admin tab and it uses its own $message.

I can see one way of perhaps getting round this, though it’s a bit messy and potentially confusing: in the install callback, drop users directly to a ‘welcome’ page by manually calling pagetop(), rendering content, then ending the callback function with a die to stop it returning to plugin_list(). Would this be ill-advised?

One reason I might want that is if someone installs a plugin and there is some secondary step required to make the plugin work that is too complicated to do without user interaction; perhaps it requires some kind of feedback (e.g. an installation wizard). Even just displaying a simple message to say Don’t forget to run the installation wizard first would be handy. I don’t think this kind of thing can be done cleanly — even from the ‘enable’ step — because it always lists the plugins afterwards.

One way out is adding a little message that appears above pagetop on install. Nice, but not ideal (or maybe it is!) :

// -------------------------------------------------------------
register_callback('ied_plugin_welcome', 'plugin_lifecycle.ied_plugin_composer');

function ied_plugin_welcome($event, $step) {
	switch ($step) {
		case 'installed':
			ied_plugin_prefs_install(0);
			echo 'Thanks for installing the plugin composer. Please read the docs :-)';
			break;
		case 'deleted':
			ied_plugin_prefs_remove(0);
			break;
	}
}

(btw, the ‘0’ argument is so the install/delete routines know not to display their own pagetop output, since the same code is called when a user manually installs/deletes the prefs from the plugin composer interface itself)

Other possibilities:

Allow plugins to set a global ‘message’ variable that is appended to the “plugin installed” message. UI real estate is an issue here
Allow plugins to return ‘false’ from the callback, which suppresses the default plugin_list() — is this a security risk? Maybe not, since by the time the list is displayed, the plugin has already executed its installation payload
Something else I’ve not thought of

Even as it stands, this is incredibly useful for simple automated installation/deinstallation steps. Thanks again for the functionality. Rockin!

Last edited by Bloke (2009-03-10 23:12:32)

Bloke · 2009-03-10 23:52:19

Oooh, one thing I have just spotted. I have this at the top of my plugin:

add_privs('ied_plugin_composer','1,2');
add_privs('plugin_prefs.ied_plugin_composer','1,2');
register_tab('extensions', 'ied_plugin_composer', ied_plugin_gTxt('ied_plugin_composer'));
register_callback('ied_plugin_composer', 'ied_plugin_composer');
register_callback('ied_plugin_setup', 'plugin_prefs.ied_plugin_composer');
register_callback('ied_plugin_welcome', 'plugin_lifecycle.ied_plugin_composer');

When I’m on the Admin-> Plugins page, if I click Active Yes/No the Extensions tab appears. Is there something I should do to avoid this, or is it just a byproduct of having a plugin execute on the Plugins tab?

Last edited by Bloke (2009-03-10 23:52:36)

wet · 2009-03-11 06:48:14

Bloke wrote:

I can see one way of perhaps getting round this, though it’s a bit messy and potentially confusing: in the install callback, drop users directly to a ‘welcome’ page by manually calling pagetop(), rendering content, then ending the callback function with a die to stop it returning to plugin_list(). Would this be ill-advised?

As a plugin author, you are solely responsible for the user experience of your plugin. Throwing users around beyond their well-acquainted expectations is commonly considered poor user experience, so you’d better have a valid reason to do so ;-)

One way out is adding a little message that appears above pagetop on install.

Quite useful suggestion, Mr Bloke. I think r3136 addresses your concern nicely. As the custom message returned by the event handler isn’t restricted at all, you can get creative here, even to the extent of drawing a fat thickboxish welcome splash screen – if you dare.

wet · 2009-03-11 06:50:50

Bloke wrote:

When I’m on the Admin-> Plugins page, if I click Active Yes/No the Extensions tab appears. Is there something I should do to avoid this, or is it just a byproduct of having a plugin execute on the Plugins tab?

This is a not so nice, maybe even unavoidable byproduct.

wet · 2009-04-06 08:54:01

Bloke wrote:

When I’m on the Admin-> Plugins page, if I click Active Yes/No the Extensions tab appears. Is there something I should do to avoid this, or is it just a byproduct of having a plugin execute on the Plugins tab?

Fixed in r3171.

Bloke · 2009-04-06 08:58:01

Storming job, thanks wet.

Textpattern CMS

Textpattern CMS support forum

#1 2009-03-10 15:42:09

r3133/r3134

#2 2009-03-10 17:47:04

Re: r3133/r3134

#3 2009-03-10 23:10:13

Re: r3133/r3134

#4 2009-03-10 23:52:19

Re: r3133/r3134

#5 2009-03-11 06:48:14

Re: r3133/r3134

#6 2009-03-11 06:50:50

Re: r3133/r3134

#7 2009-04-06 08:54:01

Re: r3133/r3134

#8 2009-04-06 08:58:01

Re: r3133/r3134

Board footer