Trabis, in one sentence you speak from my mouth especially about "extensions" and I don’t have anything to say but thank you.
At this time xoops is moving forward too fast and im really sorry for myself because I cannot find some time for xoops now.
Anyway I like to promote your ideas:
1- mymenu is great. Xoops should get rid of the old menus. Currently we have system blocks and module blocks. We should make it more general and better customizable.
2- If I correctly understand, you want to move onUninstall, onUpdate, onInstall for each module as plugins in system module? I totally agree. It is much easier for module developers to write a plugin.
3- In my post months ago I said all about the extensions. At this moment they are just a different name for modules and nothing added more than a cosmetic feature.( a new look in module admin menu)
https://xoops.org/modules/newbb/viewtopic.php?post_id=348920#forumpost348920
Quote:
and that is because of adding 2 options in xoops_version.php.
/*
Manage extension
*/
$modversion['extension'] = 1;
$modversion['extension_module'][] = 'system';
those 2 options in xoops_version.php is seems very confusing and its little nice looking advantage is not necessary in compare with a lot of confusing that will bring up in 2.6.
@ redheadedrod
Your definition from "extensions" is good. Whenever we have such a thing in xoops we can name them extension. But honestly believe me the current extensions are just modules with all the same structure.
4- Ability to sort modules is very needed backward feature indeed. We missed it and I think some people requested that after releasing 2.6.0 alpha 1
5- The old hardcoded waiting in xoops is really old and unusable. We need a very good waiting contents module. I suggest something like " Extensible Waiting Block" module from GIJ
http://xoops.peak.ne.jp/md/mydownloads/singlefile.php?lid=38&cid=1
6- IMO mailusers, maintenance modules should be installed with system module on the core installation and remain forever. Also "logger" module should not be uninstallable or at least the log data should not be removed after uninstall because maybe somebody in the webmasters group did malicious activities and the main webmaster like me want to find all activities.
7- Simplicity is good and I think nobody have any argument about that. Just you should think about compatibility and legacy support.
9- IMO webmasters should be able to move xoops_lib folder outside the wwwroot. You said security is not the issue but it is an issue because some modules like GIJ modules and all D3 modules (from xCube) use xoops_lib/modules folder and many of them have private/lazy codes in xoops_lib. Or perhaps you want to drop xoops_lib/modules feature? I mean you just want to have XOOPSCORE/modules folder? If you want to drop D3 feature from 2.6 we can discus it more. IMO the best way for cloning a module is D3 way. Of course trabis use a different way in publisher module but IMO D3 way is more effective. XOOPS core team definitely needs to define/introduce a method for module cloning.
read my post about the advantages of D3 modules here:
https://xoops.org/modules/newbb/viewtopic.php?post_id=346495#forumpost346495
10- Installation in one step is a long wish of everybody. Keep the good work please.
11- Please use INI files and we think about what we lost after we see it working in 2.6. As a long term member and user of xoops I can tell you all local communities need it a lot and if we want to move forward we don’t have any choice other than get rid of php definitions ASAP.
12- As I said before, we name the next version 2.6.0 but changes are so huge that we can consider it as XOOPS 3.0
IMO core team did big changes already and now you dont have anyway to make xooops255 modules compatible with the new core. It is just a waste of time and honestly xoops waste many times in the past.
To make xoops255 modules compatible with new 2.6 core you have to remove some already features in 2.6 and postponed them for the next version which I don’t agree. The current changes make life easier for module developers.
When Trabis said his xoops255 publisher as a recent MODULE will not work in 2.6, im sure other modules will not have a chance to be survived.
Also we all know that PHP team may drop the mysql extension at any moment so it will break all old modules sooner or later.
Please move forward and drop the compatibility completely
Quote:
redheadedrod wrote:
If the changes required to make old modules (2.5.5 compatible) work can be documented well in a manner that someone not very familiar with PHP can make the changes, then I am all for it.
I hope it too.
Quote:
Trabis wrote:
By completely I mean dropping support for GLOBALS, TEMPLATEOPTION, language files.
If we do drop compatibility we should assure the upgrading of old modules by the core team, when requested.
+100
Edit:
maybe we can continue 2.5.x and release 2.5.6 , 2.5.7 , ... until we make sure there are enough modules working with the stable version of 2.6? IMO it will save time for core team and module developers.