Mean! Can't wait for the latest release. Thanks heaps for your hard effort

Our latest changes to the core for supporting lazy loading of modules on the frontend has been one of the biggest changes to the API's in a long time.

Unfortunately, it also means that we've broken some backwards compatibility.

a: The $gCms->modules array that previously contained a list of all of the installed modules, along with a reference to their objects has been removed. A new API in the ModuleOperations class replaces this functionality. Unfortunately, this WILL break some modules and user defined tags that rely on the old $gCms->modules array.

b: At the same time, we've gone with PHP5 style constructors for modules. i.e: __construct() vs. the old PHP4 Style CMSModule() constructor. This will break a few modules, but most modules did not need constructors, so hopefully there won't be many.

_________________
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.

I totally understand these choices and I appreciate them

the main concerns about the modules is the mismanagement of the maximum version of CMSMS authorized by developers

I'm also concerned as a developer of module. We MUST specify our modules for a minimum version and max for better compatibility. We MUST keep in touch with news from the cmsms-core to offer consistent version with the API.

it is not easy but we must do and unfortunately the forge does not help us... I know this is not the subject and I won't start another debate here.

Otherwise can you give us an indication on how to do a better code for a call to a other module?

Instead of $gCms->modules

http://www.cmsmadesimple.org/apidoc/CMS ... duleLoader maybe ?

Which version will be concerned? I'm a bit confused about "CMSms 1.10".. are wo going back to Stone Age?


This also means that we have to offer a version for older cms installations along with a one for newer installations... Not so nice!

I'm not sure, but are you misreading the version? It's one-point-ten. The current version is one-point-nine-point-four-point-1. So 1.10 is newer than 1.9.x.x.


If this concerns you then simply stop supporting/developing the older versions. Develop for the current version and leave the older versions for anyone who needs them for their older system.

I was speaking primarily to make our module with a maximum version (the minimum version is anyway required)

backward compatibility to your module ? : it is your job. You can also make your code for differents versions of cmsms, I never said that we must do our module for a unique version of CMSMS! reread my mesage.

I say, I repeat and I insist that developers must stop pretend that their module will be compatible with all future versions of cmsms. If I develop a module today, I must necessarily specify a maximum version: 1.9.4.1

the message of Calguy1000 is the consequences of errors of module developers

Oups


Okay, right.

There are new functions in the ModuleOperations class. Some of them include:

_________________
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.

A few more of changes that are coming in 1.10

a: The ability to have a separate admin url preference
- With support for SSL. Though we aren't going to guarantee that IE won't complain about image tags etc, not using ssl.

b: Salted Passwords
- On NEW INSTALLS (upgrades will not be effected) you will have the option to salt all passwords (for added security). with salted passwords there will be NO METHOD TO RESET THE PASSWORD other than the one built into the CMS admin panel. it will be critical that a valid email address be associated with all important admin accounts.

c: Cleaning up the module class some more.
The $this->db and $this->smarty and a few other internal variables have been replaced with a simple __get() accessor method for compatibility, but deprecated. This in itself will not break any modules, they will just be slightly slower.... However, doing a print_r on a module object should work nicely now as we've removed that nasty circular loop between the modules and the $gCms object.

_________________
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.

Update:

Though we're still working on the finishing touches. We've seriously revamped the core modules, module manager and module loading process:

a: ALL modules are essentially lazy loaded upon request.
b: For compatibility reasons, modules that are marked as 'cant lazy load' (which is almost all of them at this point) are loaded on a frontend request. All modules are still loaded for admin requests (so that the navigation can be built. Still haven't figured a solution to this).
c: Minimizing the size of the XXXXX.module.php files has started
(this chews up WAY less memory for just building a navigation in the admin, or registering routes)
d: Got rid of nuSOAP from the core (ModuleManager was the only thing that used it) and replaced it with a RESTFUL interface.
e: Rewrote ModuleManager to be alot more memory efficient, and faster.
f: Rounding out the functionality for the Module Manager (downloading older versions, upgrade respects dependencies, etc).

This functionality, as mentioned before means that some of the older methods people used to access modules: like the $gCms->modules array has been removed. if you have user defined tags or modules that used this methodology, then they may be broken on upgrade.

Module developers should be part of the beta process so that they can be sure to upgrade their modules properly in time for release.

_________________
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.

Here we go again with another update:

We're enhancing the admin log functionality... making it more flexible, and easier to use. Also, we're making sure that we're adding admin log entries in many more places, making this more valuable for every day use. Also, the admin log entries from the core, and core modules will always be in English, independent of what the currently logged in users selected language is.

We've changed the smarty mechanism to better take advantage of lazy loading. in 1.10 ALL of the user defined tags, and plugins will be lazy loaded. This is a big thing for memory optimization.

Additionally, we're continuing to play with module lazy loading. Here's what I have working as of now (still to be tested by our QC team, lets hope it works):
A: No modules are loaded by default in the admin interface
B: In order to build an admin navigation, modules are loaded and evaluated.. the results of that evaluation are cached for each user. This means that for subsequent requests no modules have to be loaded until they are called. The cache is automatically cleared when a module is installed/upgraded/uninstalled, and in a few other places.
C: Module capabilities are cached in a similar method
D: On the admin, when a module does have to be loaded (i.e: to display the module admin console) all of its dependants are loaded (so that it can register it's smarty plugins, set it's state etc).
E: Notifications will be rewritten to be a pseudocron task. Threfore modules will not have to be loaded for each admin request to build the notifications, only when pseudocron says it has to.

We are making every effort to ensure that modules are by and large backwards compatible (except for the $gCms->modules array). so we may have to back out a couple of these enhancements if we find we've broken stuff too much. However, we expect to see significant performance and memory improvements for the majority of admin requests.

Edit: Some custom admin themes may be broken in the upgrade (because methods were rewritten to adjust for the $gCms->modules, and the lazy loading and caching stuff). So users who manage custom admin themes WILL need to test these before upgrading their customers sites.

_________________
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.

That's what I am talking about! Thanks a million!

Where can I/we (as developers of 3rd party modules) find the sources for download/test?
Will there be a 1.10 forum part (as there was for 1.8 and 1.9)?

Duketown

There will be a formal beta process for 1.10, that will probably be a public beta. And a forum attached to that that will be highly moderated. The beta process will be for testing of stability, not for requesting features.

The brave can still check out 1.10 from SVN but please don't report problems at this time. The feature list isn't complete and some stuff is still broken or incomplete.

_________________
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.

Will the backend be Smarty-fied?

The work is already done - look here

viewtopic.php?f=5&t=54764