Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
plugin handling
I’ve seen some recent changes to the standard plugin template and plugin handling (help preview, textile parsing, compression etc…).
So here are a few questions concerning the plugin handling:
improvement of the install and uninstall process (db tables)
Many of the newer plugins create their own tables in the database. Until now there is no standardised install and uninstall process for these tables. Is there a chance that the plugin template will be extended to automatically insert new tables during the plugin installation process. (In addition it would be necessary, that these tables would be deleted if an plugin was uninstalled.)
plugin compatibility
As we are getting closer to a new release there will be again the problem, that plugins won’t work anymore (some are just abandoned by their author, but still very useful). I think it would be nice to have some kind of version controll that displays a warning if a plugin is not written for the TXP version you are using. (This won’t help with the next release but will be very usefull the more release we get.) Is there a chance to get this functionality (similar to the way Firefox handles its extensions)?
plugin localisation
Will there be a way to localise a plugin without having to edit its source code or to install a seperate language plugin that enlarges the plugin list enormous, if you have many plugins that need to be localised. (The idea of separate language plugins is very nice, but – in my opinion – there should be a standardised way that they do not show up as regular plugins. May be there could be a new column in the plugin list where you can see if you’re running a localised version and which language you have installed.)
I know that some of the things I’m asking can be handled on a per plugin base. But I think it would very useful to have a coherent and official way plugin creators should be dealing with these issues.
Offline
Re: plugin handling
You have my vote on the first issue. When I want a table created for a plugin, I add a query in the plugin to check if the table exists and create it if not. That works, but there’s really only one time that check has to be done… right after installing the plugin (or even better: when enabling the plugin). Right now, that check happens way too often.
Perhaps use a standardised function name for post-install and pre-remove actions. Say your plugin is called txp_myplugin, then you could add functions called txp_myplugin_post_install and txp_myplugin_pre_remove and let TXP check if these functions are callable and execute them at the appropriate time. And if they don’t exist, no actions are executed.
I suppose that if the plugin would be loaded directly after it is installed (during that same page load), then you could let the plugin itself register a callback that would be triggered right after the event its installation without the need for a standardized post-install function call.
Deleting the table on deinstall is not something I’d do, personally, especially not for plugins that store a lot of valuable info in a table, like rss_unlimited_categories. If I’d accidentally remove that plugin, I’d be very unhappy if the table was gone as well ;)
Unless of course there’s a way to make TXP ask for confirmation before removing the table, so the choice would be up to the user.
Last edited by ruud (2006-08-30 10:05:34)
Offline
Re: plugin handling
We are open to patches as long as they maintain full backwards-compatibility and are of a size that can be reasonably reviewed (probably makes sense to tackle the problems one at a time, after you draft out the specifics of the ideas). The more changes such a patch contains the more likely it is to be moved into crockery (where things like compatibility checking are a must anyway).
Also I’d like to see some discussion and consensus among plugin-authors for how to best solve those problems before we bind ourselves to a specific way of doing things.
Notice: Given that we currently only have a single major release that we are maintaining, I don’t think plugin-compatibility is much of an issue – it can be on case by case basis, but not in general. The main issue you’re going to have to tackle is getting plugin authors to include the necessary information in their plugins (in the comment above the encoded plugin for example everybody could have included that info for a while). As I wrote in another topic I am not to keen on comforting people that insist on using outdated (textpattern) software, because that can harm a lot more people than only themselves.
Once crockery goes live and we’ll have two independently maintained major releases, we will need a way to handle this better, as I expect and encourage new plugins to appear for both versions for a while. For crockery I would also like to make creating and exporting plugins from inside textpattern easier, which should spare several of the repetitive tasks involved now – as always the scarcest resource is time…
Offline
#4 2006-08-30 14:21:30
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: plugin handling
Skubidu
Re your third point, Graeme and I are working on a plugin for MLP and we have made a lot of progress on it already. We realised that people would need this feature — especially for popular plugins like zem_contact_reborn—so we have built support for this into the forthcoming plugin already. Ok, it’s not standardised into TxP but it’s a step in the direction of having a coherent l10n standard for plugins.
The protocol for plugin authors is simple and does not tie the plugin authors to the presence of the MLP plugin, if MLP isn’t present in the target system, the plugin can still operate — but the admin won’t get the neat string localisation features provided by MLP. I have converted a local copy of zem_contact_lang to use the MLP services (if available) and it will be bundled as part of the MLP package when it is released.
We have also made the stringsets exportable/importable so that admins who translate plugins can share their efforts.
There are some teaser shots in the l10n thread.
Last edited by net-carver (2006-08-30 14:38:47)
— Steve
Offline
Pages: 1