We are talking about the same thing with different names. you call it draft i call it wish not because nobody did it before but because we dont have a standard coding style for them.

So all have clear instructions are not Alpha or Draft.
I think you can publish all your documention from moduleadmin class as final version.

Now IMO just 2 parts are not covered.
1- filter show/hide: i take a look to that mastop_go2 module and i saw that it is not that filter i guess before. It is simply just an inline form in the header. I can add it to userlog because it is very easy. I was thinking about a real js filter.

2- inline editing. It would not be too hard. but it would be harder for someone like me rather than some experienced developers like Mage.

Also IMO you run into this standardization because you had many issues in bug fixing old and outdated modules. But the GUI and navigation facilities are not the root of this problem. this problem is because of not using XOOPS API.
so we need to document other more important xoops classes. moduleadmin class is one of the simplest core classes.
You are a fan of GUI but i more think about under-laying codes!

The new tutorial "How to update tables to follow XOOPS' new naming scheme" is good. thank you Mamba.
I just have some opinions to make it complete and more standard and understandable.

you suggest such a name for the update file:


i prefer to change it to:

because:
while the name of this file can be anything but it is not used just for update. you can use it for onUninstall and onInstall too. so it would be good to standardize it in all modules in one file, i suggest include/module.php
IMO it would be more understandable and will do the job with one file instead of several files for each update/install/uninstall

Also there is one small issue in your way in using update function.
every time the user click on update your script will execute and the user will see nothing but this. for example in news:

but he should just see it in the first time. and if the module is the recent one the module developer should state that.

also you can explain the naming structure of the fucntion more.
e.g.:
$func['onUpdate'] = 'xoops_module_update_' . $dirname . (&$module, $oldversion = null)

$func['onInstall'] = 'xoops_module_install_' . $dirname . (&$module)

$func['onUninstall'] = 'xoops_module_uninstall_' . $dirname . (&$module)

$dirname: is your module dirname.

$module: is the handler for your module. so you have all your module information ready in the function.

$oldversion: is the old version in user database. it is very useful when you want to upgrade your module and need to know what is the user version of the module in database. It will get the old version in the installed old module in user database and you will choose what to do next.

see an example from newbb as an historical module:


also there are 3 less important functions for developers just for your information:
xoops_module_pre_update_
xoops_module_pre_install_
xoops_module_pre_uninstall_

which run before the main functions.

anyway back to the top, to solve the issue when user try to update a module several times. you can write the function like this:


It would be a MUST if you have important updates in your module that should run just one time or updates have performance impacts. e.g.: alter database with queries.

The above can be copied/pasted to any module in the head of its update function.

Also it show the usage of $module and $oldversion to module developers.

side note about version:

as you can see xoops core can just accept 2 decimal points to play such a games i described above with versions.

so the above for news 1.68 and news 1.687 and news 1.688 and ... would be the same eg: if ($oldversion == 168)

so module developer should care:
IF your module need an update you must at least change the second decimal point of version.
e.g.:
news 1.67 to news 1.68 => update will be run
news 1.68 => news 1.683 => no update

I hope the above be a complete tutorial for all update/install/uninstall functions.
also i hope you understand me

Irmtfan, thank you so much for all your comments and suggestions. This is very helpful, and I hope, more people will add their feedback, so then we can consolidate it and update the tutorial, and use it for all our modules.

Moving to XOOPS 2.6.0 we'll need a lot of similar short tutorials, explaining people what we are doing, and why, and giving them short "code recipes" that they could reuse in their modules.

That was something that i learned when somebody ( I think peekay) asked about the version issue in his module.

tutorials are good but more importantly developers should read xoops classes more and they can find many of their needs.

I would like to suggest that as part of our module standardization, all new XOOPS modules are clonable, i.e. they have structure that enables them to be cloned by the "SmartClone" module (see this thread)

We will also look at the existing modules, and as part of refactoring/rewriting, we'll look at ways to make them clonable as well.

Ideally, all XOOPS modules should be clonable, so the user can have several of them installed in parallel, if needed, with no name conflicts.

What do you think?