Quote:

There will be no problems with 2.6, just make sure you also change the class names because, if you have 2 modules that use the same approach, you will get fatal error of 'class already defined'.

Thank you very much!
if the module is not updated by the developer, I will use this solution

Actually, I am not a php-programmer. As soon as 2.6 will be published (or even earlier), I can upgrade to actual version of modules or convert to current, standard ones.

News, Extcal, Extgallery and MyLinks will be upgraded (that is what is understand from the discussion above), since they are in the Basic Module Pack.
Smartsection: should I switch to Publisher ?
Smartfaq: will it be compatible with 2.6 ?
Wfdownloads: what will be the standard download module in 2.6 ? I don't see a standard download module in the Basic Module Pack.

Thanks !

SMEDrieben

Quote:

Most of the modules in the repository are unsupported and without developer support material from the core team, other users are unlikely to be able to fix them.

Some focus on developer support is long overdue and badly needed IMHO.

Quote:

At this point it has been mentioned that the road map for 2.6 has not been defined yet. The work that Trabis has done is preliminary to the rest of the work they will be doing. There are plans to document and bring the developers up to speed. With the current crop of Developers we have a good group that is willing to share what they know but at this point a lot will be changing as things get updated so it will be hard to provide developer documentation until after the transformation is complete. Or at least the full direction can be given. As it is now, you can update modules to run with the 2.6 updates as they exist now but you can expect to have to update numerous times until the 2.6 branch is set.

There has been talk of trying to combine the XMF framework that Trabis has been working on and the Framework that Red Mexico has been working on. One of the weakest points that keeps Modules from being developed in a common manner is a lack of an all inclusive core supported framework. However last time I heard from Trabis or Mamba about this there was no roadmap set yet for 2.6 and the Module Frameworks would be developed after significant progress was done towards 2.6.

So for now writing documentation for module developers is kind of like hitting a moving target. Do you want to write stuff for the 2.5 branch that would need to be updated for the 2.6 branch or Write for the 2.6 branch that isn't set yet so it will require constant updating or just kind of wait it out...

Quote:
I agree that support here on XO is very good, but the task of consolidating that wisdom into proper documentation has been put off for so long I can see some real problems on the horizon.

When only experienced developers associated with the core team are able to release or update modules in official 'packs', the Xoops project is heading for a dead end.

I understand that some elements of the core may well change, but most other CMS applications already have developer documentation that covers their current release. The biggest threat I can see is that building a module or plugin for them is far more attractive than struggling with Xoops.

I totally agree with you Peekay,

My biggest issue with "growing" with XOOPS is the lack of documentation.

I came into this environment about 3 years ago and Mamba offered some suggestions to get me started and I am at a point now that I am writing some interesting software myself to help push xoops along. I hope to be at a point I can be helping with coding of the core within a year.

With that in mind I have been talking to a couple of the board members about helping to develop documentation for developers.

My intent is I am currently trying to totally revamp the install system. I won't be satisfied until I have evolved the xoops install to a whole different plane than it is now. After that I have some other things I am working on. I will likely start working on my uModules project after I get the main install script where I feel comfortable with it and it works well. I plan to use the TDMCreate program and document every step of the way. Because of the nature of the uModules project I will be getting involved very intimately with a variety of the core entities. At this point I plan to fully document my progress with this which should help others. I won't go into my uModules concept here because that has already been done in another thread. Towards my Programming Degree I will be taking some classes on advanced documentation techniques, giving classes and writing technical documentation. I plan to FULLY use these skills and fully document Xoops. At this time I plan to start with the 2.5 series and add additional information for 2.6 as well as how to change older modules to the newer 2.6. I will be trying to work with board members and core developers as I work on this to help understand and present the best ways to do things. Especially if I become a core developer myself.

There is a list with all deprecated functions in xoops 2.5.4?
Thank you.

@Roby73

That would be a good starting point. We shouldn't have to wait for an error message or a blank screen to find out what has changed.

I am confident most PHP savvy users will be able to fix modules broken by a core change if they are told what has changed, the errors it might cause and suitable replacement code.

@redheadedrod

Quote:

That's definitely the right way to do it.

The core team are very precise in their coding and we should all be celebrating their enhancements, but without documentation the changes just cause problems and kill more modules with every new release.

I agree Peekay,
There is documentation available but it is hard to find and most of it is related to the 2.0.18 series. I won't get into my uModules project here but because I see the same issue that you do I planned the uModules project to get around this.

I will be documenting most everything that I do so that I can help other developers. I do hope to provide this to the core developers to offer suggestions on so that I can feel pretty confident that what I present is an accurate representation of the intentions. I believe the core developers are going through the "basic modules" pack to update them to work with 2.6 but I don't see them doing the full on rewrite that some of those modules could use. I want to see where the RMCommons and XMF frameworks go before I get too serious about my projects but in my mind the framework that comes out of that should propel module development beyond whats available for other CMS's.

Trabis said elsewhere that he was going to be adding inline documentation to the code to help as well unless I read that wrong. Which means documentation done with one of the automatic documentation creators should make usable documentation for xoops automatically. It isn't a tutorial or a "This is how you do it" sort of thing but can be a very useful reference guide.