plugin localisation, version numbers, huge plugins

Skubidu · 2006-03-17 09:25:32

I know that there have been many topics discussing this issue, but I never found a final answer to the following questions:

Are there any conventions about

how to help people localising a plugin
how to create the version number of a plugin
how to handle huge plugins

localisation:

I know, that many developers are writing their own gTxt() function. I would like to see, if there was a consitent way for plugin translations. What about an extra file, that can be installed via the plugin tab? Not as an extra plugin, but as add-on for a plugin (new column in the plugin table). Of course, I could translate a plugin for myself. I know how to do it, that’s not the problem. But how to share translations? Plugins get updated often, but the translations often keep the same. If I export a translation as a new plugin, I have to redo that every time, the original get’s updated.

version numbers:

There are so many different concepts around. Just starting with 0.1, some people are adding a “beta”.
How do I see, if a plugin works on my TXP install (RC 3, 4.0, 4.0.3)?
When should a plugin’s version number be 1.0?!

huge plugins:

Once I got the problem that a plugin couldn’t be installed on some installations because the textfile was to huge. What about plugins that need extra stuff like images, external scripts. Textpattern’s way of putting everything in one file is very limited at some point.

What do you think? Are there any possible ways to harmonise the plugin development and handling?

tranquillo · 2006-03-17 10:12:54

“how to help people localising a plugin”
If I have fix strings I add a language file to the plugin, that can be installed through txp admin interface. In zem_contact_reborn, where the output of the translations include variables, the gTxt function is in a separate plugin.

“how to create the version number of a plugin”
It seems that in crockery plugins will be <a href=“http://forum.textpattern.com/viewtopic.php?id=15287”>checked for compatibility</a> in a way, that the plugin will be loaded in all txp versions equal or higher to the set parameter.

“how to handle huge plugins”
As elements in crockery. For now, I split a huge plugin into a public or admin plugin and a plugin library (type = 2). The library is only loaded if necessary with require_plugin(). I use this i.e. in the next version of my poll plugin to load the admin side functions only in the admin interface.

Sencer · 2006-03-17 10:33:50

With the capabilities of the 4.0.x line, my proposed answers would be:

huge plugins: Decomposition into multiple plugins. There are special functions like require_plugin that can help make sure nothing is missing. Extra stuff like images and external scripts can be encoded into the plugin and ouputted from there. Yes, currently tose things may require a bit of manual labour, but it’s possible.
Plugins will likely improve in crockery.

version numbers: It’s the authors responsibility to include the information which version of txp is requiredinto the documentation. He can also use version_compare in the code, to ensure compliance. As for numbering: Since there is no way to enforce a certain scheme, or to gently nudge plugin authors towards one, this is a bit of a moot point. There are several good reasons for alternative schemes. The textpattern way is: Use X.0+, when considered stable for production-use. Increment minor numbers for backwards-compatible maintenance releases. (Ignoring the middle-initial for the moment)

localisation: As long as the requirement is to use only one language at a time, decompose the language-items into a seperate plugin. The language-plugin could be as simple as an array of language strings that are then added to the global Textpattern variable $textarray (in the form of $textarray['abc_myplugin_actual_name'] to prevent nameclashes), and which can then be called via regular gTxt(). Alternatively this can also be done the same way and squished into one plugin with the language stuff at the top, which then would require the user to edit and/or copy/paste the language strings.

—

While I am not working on the elments-code, I think some people are making some wrong assumptions about elements. Let me quote the relevant portions from the elements-weblog-entry:

In a nutshell, Elements [are] included as part of the Textpattern distribution, and thus have no install or uninstall mechanism, but can be turned on or off […]

The point is [internal code-organiztion inside the core] and [to] make it easier for users to customize a Textpattern installation by disabling features they don’t need.

While it is possible that dev-shops make their own elements, if they feel it enhances the re-usability of the code they write for clients, that is not the purpose of elements. And it it also is not the intention to be a good and easy way to share extensions for textpattern – there is no point in offering two competing extensibility/plugin standards. Specfifically Elements do [b]not[/b] solve (and do not attempt to solve) any of the following problems:

localisation
versioning
compatibility-checks
external files (like css, js, images)
installation/uninstallation
portability/distribution

Frankly, I don’t see why anybody would prefer to write their extension as an elemnt, rather than a plugin. The exception being people who maintain their own private branch/fork because of client-needs.

Skubidu mentions some good questions above, some of which have been discussed before, but all of which deserve their attention with respect to crockery. Hoefully we’ll be able (timewise) to have them ready for crockery. However those changes will happen with plugins, not with elements.

Skubidu · 2006-03-17 11:01:26

Thanks, Sencer, for that clear definition of the element concept. I’m not aware what’s planned exactly for crockery concerning plugins, so please forgive me if I propose things that have been discussed earlier.

What about some kind of guideline for plugin developers coming up with crockery (or TXP 4.1). I know, that noone can tell a plugin developer what he must do, but perhaps it would be helpful to define what he should do. I think your concept of using $textarray for localisations sounds promising. There is only one problem, if you source out your language strings in a separate plugin: Probably this could double the number of plugins you have in your installation if you’re working with localisations. There is this string in the plugin template where you can define if the plugin is for frontpage use, admin side or simply is a library. If there would be a fourth options, “plugin translation”, this plugin could be listed a different way in the plugin list (new column as mentioned above?) to keep this list clean and concise.

Concerning the compatibility:
Sencer can you explain, what you mean by saying “He can also use version_compare in the code, to ensure compliance.”?

Sencer · 2006-03-17 12:02:43

I’m not aware what’s planned exactly for crockery concerning plugins, so please forgive me if I propose things that have been discussed earlier.

There is nothing specific planned, just lots of suggestions that people have voiced. Also: There’s nothing to fogive. ;) I think this is a very good discussion to make plugin authors aware of some issues and maybe work towards common solutions forcommon problems. Given that this is in the plugin-forum, I think the focus should be on what can be achieved with what is available today.

As soon as we start changing things about plugins in crockery, there will be concrete things to discuss. Otherwise there’s a thread on txp-dev mailing-list from February called “plugins – rethinking ‘the way we’ve always done it’” from users which propose some changes for crockery in terms of plugins. The only reason I have mentioned crockery at all, is because people keep bringing up elements as a solution for some of the problems that plugins are having, and that’s not really the case. Thinking about it, this thread was probably not the right place to adress that. I hope you can forgive me for hijacking it.

Re version_compare: http://de.php.net/manual/en/function.version-compare.php is a function with which you can compare version-numbers (if they adhere to certain naming-convention). A plugin-author can make his plugin fail with a Warning/Error, when certain pre-conditions are not met, that he thinks are necessary.

Skubidu · 2006-03-17 12:52:13

Sencer schrieb:

http://de.php.net/manual/en/function.version-compare.php is a function with which you can compare version-numbers (if they adhere to certain naming-convention). A plugin-author can make his plugin fail with a Warning/Error, when certain pre-conditions are not met, that he thinks are necessary.

I’ve checked what this function does. That’s a nice possibility. Just one problem: as user I would expect to get an error message after trying to install a plugin – but plugins are (for good reasons) deactived on the plugin tab. So I could promp my error message directly on the website (Is this on good way?! If yes: how to insert the message on the site?) or I insert it anywhere in the admin interface (pop-up, text, anything – how to be sure the user gets to see it?!).

Given that this is in the plugin-forum, I think the focus should be on what can be achieved with what is available today.

Well, that’s why I posted this thread. “The hitchhikers guide to the plugin development” in addition to this topic.

Sencer · 2006-03-17 14:41:13

So I could promp my error message directly on the website (Is this on good way?! If yes: how to insert the message on the site?) or I insert it anywhere in the admin interface (pop-up, text, anything – how to be sure the user gets to see it?!).

You can use trigger_error() which will respect the production-status setting. I would advise to output the message in those places, where the user expects to see the plugin’s output: If it’s a tag, then on the public-side, if it adds a tab in the admin-side, then there etc. etc.

Skubidu · 2006-03-17 14:55:07

So it would be possible to do something like that?

if (version_compare($thisversion, "4.0.3", ">=") = 1) {<br/> trigger_error("The plugin abc_myplugin could not be executed: You need at least Textpattern 4.0.3 to use this plugin.", E_USER_ERROR);
}

hakjoon · 2006-03-17 16:03:34

Sencer wrote:
Extra stuff like images and external scripts can be encoded into the plugin and ouputted from there. Yes, currently tose things may require a bit of manual labour, but it’s possible.
Plugins will likely improve in crockery.

Sencer when considering improvements for plugins please consider things like plugins that interface an external tool/library with textpattern. The tinyMCE integration I support would be a bear if it required recoding every single .js file into plugin functions, not to mention it would break things like how tinyMCE itself handles plugins, and potentialy create it’s own set of instabilities. Granted this is a fairly extreme example.

Anyway I’m sure you all will suprise me with capabilities I never even thought of, since that’s been the track record so far. Thanks for the clarification on elements

Sorry if I’m repeating myself on this. I posted this concern when Mary brought this up in the dev list but I don’t know if it made it to anyone or if it just went into the ether. Everyone probably just blocks me out :)

Bastian · 2006-03-17 17:58:40

Some ideas about how to handle huge plugins

Some plugins used the db to store prefs or even create new tables. We should thinking about a standard for handle these db-stored prefs. Add them to txp_prefs or a new txp_plugins_prefs while installing the plugin and remove them after unstinstall. The used way run a advanced plugin install via extension is quite pedantically. If you uninstall a plugin without running its uninstall function, the plugins prefs stay in db.

Perhaps the plugin install could be extended:

Further to plugin’s name, author, version etc the plugin could contain a flield with some db-queries.
And perhaps a list of needed images is not a bad idea.

Textpattern CMS

Textpattern CMS support forum

#1 2006-03-17 09:25:32