First let me say that this is a copy paste of an email I've sent to Nicolas and Mage. Since I forgot to include all the core team and because I think this deserves the attention of module developers and the whole community, it follows:

1 - I would like to convert 'mymenus' module into 'menus' and use it as an official menus module. It will hold the actual system mainmenu and it will use the plugin system to get dynamic menus from modules. One less item in xoops_version.php. The idea of xoops_version is not to execute logic. Sometimes modules don't respect this condition and we get hits on performance by having code executed that is not required,

2 - I would like to remove onUninstall, onUpdate, onInstall hooks from xoops_version. They should be implemented as plugins of the system module, just like search, notifications, comments and menus

3 - We should consider dropping extensions and find an effective way to navigate on the admin side. For performance reasons, I would like to remove drop down menus. I would prefer a single entry page with all modules icons. Then, after clicking on the module, we should get access to preferences and other options. A drop down just for listing modules is acceptable. We could use a separation line for modules that have no main, this way the modules(that are now extensions) will be displayed in the bottom, they are usually the less accessible modules.

/************/
Well, regarding extensions:

I find it very confusing. Some times I want to change preferences on some module(example search) and I don't know if it is a module or an extension. How can we distinguish modules from extensions? At this moment I assume extensions are modules that have no main content. Search and tag sound to me like extensions, but they are modules just because they have front pages.If we were going to create separate folders, we should also have to create separate db tables, separate methods of getting configs, of loading handlers, of getting forms etc. For me, it does not make any sense doing that because there is just one difference in the way we code both of them, a single line saying extension = 1;

The idea of using extensions was to simplify the navigation on admin side. I think the goal was not accomplished. For me it is revealing to be more confusing.

I would like to propose to list the modules as it was done before but with one difference. Modules with main on top, Modules with no main on bottom. The sorting of the weight of modules should be done as before, with drag and drop. Weight of modules is important, it is not just for menus, it affects the order of the execution of preloads, the order how they are displayed on a sitemap, and perhaps the order they will display in the front page of the admin side.
/*************/

4 - Add back the module sorting(weight) with drag and drop. We need to sort modules not just for menus, but also for priority on preload, sitemaps, etc.

5 -Remove the system waiting block, we can/should make a module for that (that uses the plugin system)

6 - Making mail module(extension) not uninstallable. We need this as core module because webmaster may need to retrieve their passwords. We don't want to support users asking how to enable the mail module when they can't even login!

7 - Refactor preload to use simple names like beforeCacheCheck, afterUserLogin, etc. The actual method of naming preloads following the module/file is not good. We are moving files around and getting preload names that are not coherent anymore.

8 - Look for preloads in module/class/preloads.php. I guess there is no need to support preloads on several files like core.php, sytem.php, etc. Modules will not be using preloads to hook with each other, they will use the plugin system now.

9 - At the moment xoops_lib path is asked during installation for users that may want to put it on private folder. Problem is that we are using classes that are located on this folder for the install process. If the folder is moved, the install will fail to load the required classes. On the future perhaps all classes will be moved to xoops_lib, so it is not a solution to copy/paste the missing class to the install folder.
We have 2 options:
- Don't ask for the path of xoops_lib, assume it is on public folder, If users wants to relocate it, they can do it after installation.
- Don't make use of core classes until the users have inputed the correct xoops_lib location.

I would like to say that xoops_lib is totally ok to be on public folder, security is not an issue. Users could move it if they want to share a unique location for different xoops installations. Only xoops_data is essential to be private/htaccess protected.

10 - It would be nice to have the install completed in the less steps possible. It would be great for promotion if xoops could be installed in 1 step. After step one we could have a "go to site button" or a "configure your site" which would lead to extra steps(install modules/themes/etc). 1st page would do the requirements checking and if positive ask all the data needed (db, username, etc). It would have also have a language select box that if changed, would refresh the all page. It would be simple, effective, amazing and again(kick wordpress on the but)

11 - Translations. Should we go for ini files? My choice is ini files. There are some drawbacks from dropping defines, we loose smarty.constant for templates (although we can make a smarty plugin to get language) . We loose editor autocompletion, we will never notice a typo until we see it on the rendered page. The advantages are great, we can override items that are not yet translated. If missing from french file, just get the english version of it.

12 - Compatibility with 2.5.5
Although compatibility is planned for 2.6, there are things that will mostly like break modules:
- code is ready for php 5.3 using proper type checking on methods, CriteriaCompo does not accept strings anymore. This was enough to stop publisher from working-
- Re factoring of XoopsForm introducing interfaces. Modules that use custom forms that extend the core ones will fail because they do not implement some of the methods. Again, this was enough to break publisher.
- Search, Notification and Comments . This will not work without changing modules.
- Translations. We should use en-Us, pt-pt, etc for language folders. Should we support inclusions for legacy folders?

It seems that compatibility will not work for the big modules but it should work for simple modules.
My issue is, should we consider dropping compatibly completely? 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.

very good proposal..long awaited features

for me as a end user i support what is best for xoops.......

2.6 will be the best release

Trabis, I will respond to your points 1 at a time then elaborate more afterwards.

1. I agree with you here. I never was able to use mymenus with my systems but I used a similar system and I agree here with what you say. Although I am unsure the difference of pulling the menus out and putting them somewhere else. I thought the concept of putting the menu's in the xoops_version.php was to be able to load the menus into the database at installation time.

2. I do not understand what you mean here. I am under the understanding that these calls are related to a module install and need to be there in case a module needs to do some setup or tear down at installation, update, or removal. I was under the understanding these are more to tell the module system to run an external script if necessary. This may not be as much of an issue when you use xoop specific modules but when you take an external program and turn it into a module there can be some additional work that needs to be done to mate the external program to xoops. Such as Wordpress or mediawiki. Something to consider adding is a dependency system. Modules can depend on other modules or extensions existing in the system. There are two types of dependencies... One is where a module can offer enhanced options when a dependent module is installed (ex. cbb and xoopspoll). Or the module will not work without the dependent module. (ex. Commons with any of the red mexico modules that depend on it.) We should be building a dependency checking system into it that won't allow modules to be installed unless the module/extension/framework they depend on is already installed. They should only warn about modules that can enhance its options but still let it install. Then when the dependent modules or extensions are removed it should check that nothing requires them to be installed to operate. If something is dependent on them then THAT module should be disabled and not allowed to be enabled until the dependent module or an equivalent is loaded. As I am aware, there is no way for xoops to check for this as is.

3. I suggested the extensions in the first place. The intent was to pull code out of the core that really didn't belong there. My impression is that the core should be a bare framework with the tools to get the job done. Anything else complicates the core and should be separate. I agree that the current implementation is confusing and asked about it when they were presented the way they are now. We should revisit the structure of these and look at a more efficient way to accomplish the same thing. And do they really need the full support that a module normally needs or can they be reduced some. So I guess we are in pretty much total agreement on this one.

4. Not sure what is meant by this.. Aren't the modules given weights now with the drag drop system? I haven't looked at the code but I assumed they were the same as before just the interface to change them is different. So the weights are now invisible to the user but are still there just behind the scenes.

5. Not familiar with the System Waiting block but I am going to assume this is a good idea. Although should maybe not be a module but an "extension" since it is a very lightweight option.

6. The lite code for the PM and Profile code should be removed and the PM and Profile modules should be required. Both for security reasons. If PM or Profile are removed the system should go into offline mode and only the webmasters be able to log in with the offline login screen and only be able to access the admin menu. The user screens should be disabled until the PM and Profile modules are reinstalled and active.

7&8. preloads should be simple.. I have no clue how these work so I can't respond any further. I have a basic understanding of what they are supposed to be but I really am clueless with preloads. But we do need a method for allowing modules to talk to one another to allow modules to use the resources already installed easier than it is now. (See CBB/XoopsPoll for example... CBB contains much XoopsPoll code in order to add polls to forums. This is not a clean way to do this.)

9. lib/data folders.. We need a little more discussion on this.. Data there is no question... But I wonder if the Library isn't better being out of public out of prying eyes so if a hacker gains access to the root directory they don't have access to this code. After playing around with some security tools I think we should be moving towards moving ALL of the code base out of the public folders and only leave code that is absolutely necessary in the public access directory. It is too easy to change the software if you have access to it. And some of the tools we have been using in class I can take advantage of bad settings or a lazy admin and get access to the web directory. With an MVC style format you could easily move the code for the View and Model to lib in a private folder and leave just the controller code in the public directory. (Install comments after..)

10. Install... See below... More discussion needed...

11. I have no clue the best way to do translation. But I do believe we should have a different system. We should have a core translation system with most of the most common phrases included. This way the core and modules could access this system. If we can find a better way to preload the necessary words needed for a page then we can simplify translations for module, core etc.. By this I mean if someone uses the core library in their module then it would automatically work in any language that has a core translation without need for further translation. As it is now translations are very time consuming and can be memory intensive unless you cut the definition files down into chunks and you have some duplication when you need the same phrases in different portions or you end up with lots of small translation files.

12. As to compatibility...
With this I think I agree somewhat with Mamba's point of view. We should try to break as little as possible in this version. If possible we should try to maintain compatibility with as little modification as necessary.

HOWEVER, 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. Otherwise we need to have support for the old way along with any new way in 2.6. Make them depreciated, well document the changes needed and remove the old code in 2.7. With the limited coders we have right now it is not a valid assumption that someone can easily update a module to work with 2.6 on short notice.


As to the install program..

Next message..

A few months ago I was working on an Install Script replacement as well as a PDO class to replace the current MySQL class. (I translated a MySQLi class and updated the features and put it into beta test. It is in the third party directory of the SVN)
I quit my second job but went back to school full time. I am currently on winter break until Jan 14th so I am going to be working on these and hope to make major advancements and hopefully release versions of both the PDO and Install program before the end of January.

With the install program I am at about 30% on restructuring it. I am incorporating the following changes at this point. I am basing it off 2.5.4 but will be very simple to make the changes needed to work with 2.6.
Full multi-language and multi-theme support. The code was sort of there but I am refactoring the code to better support it.

I have included an AutoInstall config file. This will allow someone to set some or all of the defaults for their site. This optional text file will allow an admin to only add a few defaults and continue with the install as normal or if they set all of the settings they can choose to autoinstall the site totally. This is in a xoops_version.php style file. If it is not there the script will use the current methods of trying to determine the defaults.

Logging... All options will be logged with their results to allow an admin to check for settings that are not working. This has not been coded yet but will be when I have the basic structure finished. This may not be in the first code I release. My biggest priority is to get it out there.

Put all of the variables into a session variable instead of passing it from page to page. The initial results I have noticed is that after the initial setup swapping from screen to screen is much faster.

The other big change will be to make a 3 level installer. These will take into account the auto install file so you can simplify an install. The first screen will be a very simple screen that has everything in it that has to be setup but will default to a local install. At the bottom will be 3 choices, Basic, Normal, Advanced.
Basic: The install will go through and will NOT prompt further until the results page at the end which will display the result and a link to the site. (Will say Site installed with no errors if completes successfully.)
Normal: This install will have a second screen to add more selections to and will then install similar to the normal install but will not require further input.
Advanced: This will have the second screen that Normal has but will have more options. This one will likely end up with more screens since it will allow almost every setting to be set. The intent is this level will allow you to setup the site with no need to go to the admin menu and change more settings.

Added AJAX checks to check file structure of the site.
I added one to check file permissions and another to check the MD5 of the files.
This will insure that the files are all intact before the program installs. These were working but I broke them in one of my last versions. I need to find a better way. Currently it calls a routine that waits until the file checks are done then it returns the results. This can result in a 2 minute delay. Currently disabled until I can code a more friendly version. The intent is that you can make changes to your settings while the checks are done in the background. The BASIC/NORMAL/ADVANCED buttons are not active until the checks are done.

When I release a PDO class for testing I will be hitting this Install Script hard. My classes start back up on Jan14 but I am hoping that since my 4th class doesn't start until March I should be able to get these two projects done and 1 or two more done before I get crunched in March. So if there are any other desires to this script I would like to hear of them.

Rodney

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:

@ 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:
I hope it too.

Quote:
+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.

Quote:
There is XOOPS 2.5.6 at work, with small updates that will make it possible to work on PHP 5.4.x, but I don't think that we have the resources to do anything beyond security updates for the 2.5.x platform.

Once we have a solid Basic Module Pack with all modules working without any errors on XOOPS 2.5.5 and PHP 5.4.x, we need to totally focus our limited resources on XOOPS 2.6.0, as it will be enable us to create new cool modules much faster and with more consistency.

As end user I would like to see some better spam engines as there is so many registered users today that pass the capcha checking and start to spam our portals.
First that I suggest that all posts from deleted user are also deleted, that way we can easly stop spammers and their spam

@irmtfan:
After you see the new PDO class released for testing I will be working to get the Install script out for testing. It will still need to be refactored but I want to get a working version out there for comment. I will consider it to be Alpha and looking to make sure it works and to see if how I am implementing things works well. I am changing a lot of the structure of it and I am combining many of the pages. At the current count I combined the original into 8 pages and have not even touched anything past the database settings yet. I expect to decrease the install script to about 5 pages with the advanced install. But we shall see how it goes. I am using the 2.5.4 install script as my base for now. When out as alpha I will look look at the 2.6 install and try to incorporate any additional changes to make it compatible with both the 2.5 series and the 2.6 series. Hopefully it can be moved to Beta quickly. I hope to have the PDO class in FINAL form by the time the 2.6 Alpha is done so I can forward it to the core programmer to check the code quality before incorporating it for the Alpha 3 version.

I will wait until the install program is available for testing before further discussion on it. I believe there is already a thread and I will just revive that when it is ready.

@sadistiko:
I believe a rewrite of the Profile and adding to the Protector module will take care of most of the robot spammers from getting online. I have some ideas but I don't have the time at this point to do this my self. There are suggestions for this in the forum but it is a constant issue.

Quote:
It is not. It is used on the fly by mainmenu block. Xoops Coding standards say that no code should be executed on xoops_version but for having dynamic menus(like news, submit permission, etc) logic must be performed(db calls). This is -1 for performance and therefore, should be removed from xoops_version.

Quote:
And they are, I need to update you and irmtfan about what I mean with plugins!
In this alpha 2 version we have a new class called Xoops_Plugin.
Why?
We have modules like 'waiting', 'tag', 'search', 'sitemap', 'whatsnew' and many others that use some kind of plugin/hook system that other modules can use to attach functionality for that module. The methods/ways on how modules implement this plugins vary from module developer to module developer. Xoops_Plugin is the new class responsible to provide this hook/plugin functionality and unify modules plugin systems!

How?
The pluginable module has to create a file named class/plugin/interface.php. In this file an interface is provided for modules that want to implement it.
The modules that want to plugin into the pluginable module have to create a file named class/plugin/name_of_the_pluginable_module.php . In this file they have to create a class that implements all the methods that the interface requires.

For the pluginable module is super simple to execute the plugins:


So what I'm saying is that system module can make use of this plugin system to get modules information. I believe this Plugin system is more effective for modules interaction than preloads. Preloads are more effective for core hacking! Xoops_Plugin does all the file inclusion, interface checking, loading language files. It is very nice :)

I have to run to work now, I'll continue to comment on this latter. Thank you for replying :)

@trabis:
I just got out of work so I will go over the plugin stuff again when I wake up and hopefully it will make sense.

I never really understood the preloads and how those worked either.
But then again I am still trying to wrap my head around things like namespaces, interfaces, templates (php object, not smarty), autoloaders, and some other newer PHP stuff that aren't well documented in any of the books I own.

As to the extensions etc....

As I see it the stuff we are currently calling extensions that were pulled from the core really fall into one of two categories.

Things that extend the admin menu.. Such as the Image handler... These SHOULD just be plugins and not full blown modules since they really are seen just by the Admin and in essence just extend the Admin stuff.

The other things really are more extensions of the core than anything else. But they are depended on by modules as well. These too are more plugins than full blown modules but they are different than the admin plugins and should be treated differently. They MAY also have a user interface in some cases. This would include the ranking system.

The extensions just mentioned really goes back to the idea of Libraries I keep trying to push. I really think these should be libraries of functions that can be called by modules. I am interested in seeing how you suggest we link Modules together to share information. I have suggested turning modules into a MVC architecture with the View and Controller remaining with the Module as is normally done and the Model is moved into a Library file. This Library file then can be utilized by the original Module as intended or can be accessed by other Modules as if the library was as much a part of the second module as it was the first one. But in essence the Library can live on without the original module. So you could have libraries of functions that don't really belong to a specific Module but could be accessed by any module as if it was apart of it. This would be a good example of the Ranking system. If it was a Library as I mention then it could be accessed by any module as if it was part of the module. Then when someone writes a replacement module that is compatible they could use this new module to replace the functionality of the old module by supporting the same library functions as the original.

Ok I am tired so I am going to bed but I look forward to hearing more.
Rodney