In some rare cases a developer need to patch some data in module table.
For example in userlog newer versions (1.1+) I add a feature to find all login/register attempts so I need to patch all previous logged login/register data in old installations.
So If somebody had userlog installed for one year, when he upgrade to newer version he can find all login/register history.
To implement patch, I decided to not add it in normal ways like:
1- module update process: because a) module update is for database structure not data b) data may be huge and may cause some bad behaviors.
2- a menu and button in module admin area: because it is just needed for one time and after patch is finished, user dont need that menu anymore.

So finally I decided to do it silently thru one file called userlog/class/patch/patch_login_history.php
Every time user goes to userlog > admin > statistics the above patch file will be executed and will patch data 100 by 100.
If patch file find no data to patch it will delete itself from server.
So for example in new installations the file will be deleted in the first visit of userlog > admin > statistics.
IMO this way is effective, accurate and easy.
The only problem I recently faced is a user may have a folder with chmode below 700 and dont let the module to delete a file.
So those users have to delete the patch file manually.(I can add a notice for them)
Please let me know your valuable opinions about this.

Quote:
Huum why not use this in xoops_version.php ?


Quote:
That is just a name and as always IMO names are not important. We can call them anything
But anyway we dont have any pure Smarty Template in modules. we have a mixture of html and smarty.
So maybe we can call it .htpl

About plugins I like to explain more:
I add the 2.6 plugin system in userlog but i also add another feature to find plugins in both locations:
1- modules/{$dirname}/class/plugin/{$pluginName}.php
2- modules/{$pluginName}/class/plugin/{$dirname}.php

so for example to find the newbb plugin for userlog module it will search with this priority:
1- modules/newbb/class/plugin/userlog.php
2- modules/userlog/class/plugin/newbb.php

we can change current tag module to have this plugin system very easy.

You just need to install xoops 2.5.6 or 2.5.7.
Then turn php debug on and install newbb 4.33

About fixing bugs IMO we should speed up the review process.
Many bugs are reported and many bugs are reported with the suggested solutions or patches.
Now we have an active core leader So IMO nothing is more important than reviewing open bugs in 2.5.x or even in 2.6.0

Are we ready to implement this solution?
As I described earlier this solution is not the most efficient way for deleting duplicate templates. (It deleted duplicate templates one by one but they can be deleted at once)
We can improve it if you or core team prefer before implement to 2.5.7
But anyway IMO efficiency is not too important in update processes because update will be done only one time.
In update process accuracy and logs are important.

@Mamba:
1- About plugins:
IMO 2.5.x modules should (or at least can) follow 2.6 plugin structure.
If we think and we accept 2.6 is the future of xoops we should follow its ways for anything (here plugins)

Then modules will be more ready for 2.6+ versions.
plz see Userlog as the only example.

2- About using XoopsFilterInput:
As the name of this class tell us XoopsFilterInput is the security layer for any input variable like $_GET, $_POST, $_REQUEST, $_COOKIE, ... to sanitized them.

sometimes ago every module developer had to struggle with input variables but Trabis introduced request class in Publisher module to make us:
1- free from security issues.
2- handle inputs easier.
XoopsFilterInput answer the first one.

In 2.6.0 Trabis introduced a request class to handle all inputs.
If this class still cannot protect us we should solve the security issues.
So IMO security layers like XoopsFilterInput can be hide inside the request class.

Why I as a basic programmer should know what happens inside xoops core to protect my inputs in my modules?

The usage of request class should be promoted as I recommended in this topic.

Then module developers have the right to use XoopsRequest or XoopsFilterInput.
So again we should follow 2.6 ways in 2.5.x.
we can add request class in 2.5.7 release.
So finally I hope someday we dont see any inputs like $_POST (which increase the risk of attacks) inside any module code.

Hi,
Although newbb is changed too much (has been debugged and modernized) in new version 4.33 but IMO it still should work on php 5.2
Because you cannot provide us any error we cannot help you further.
You have an error in install process. It may be in xoops core or newbb.
Plz try to find an error somewhere.
- make sure debug is on
- look for any error_log file inside modules/system, modules/newbb or even root folder.

huum... strange
you at least should have a error_log file inside modules/system folder.

This fix is for upgrade previous xoops versions.
For a fresh install adding a unique key is enough.

Good fix but it will break the module in previous xoops versions.
I mean module will only works in 2.5.7.
Anyway I think only userlog used this preload.