1
redheadedrod
Xoops 2.6 , Theories, Definitions and how modules are likely to break.

It was mentioned to me that I might cause a panic about 2.6 not working with older modules so I thought I would start this thread to explain. First of all at this point I am NOT a core developer and everything I write here should be assumed to be my Opinion and my opinion only.

First of all I thought I would mention a few things and what my view is on them. They MAY or MAY not be accurate for xoops but hopefully I am closer to being accurate than not.

Core - I believe 2.6 is moving well into this direction but in essence core should only be the bare minimum required to make the system work and contain only functions that are to be used by all installations in one form or another.

Extensions - these are optional components that are not required but are added to help extend the functions of the core. Operationally they should appear as if they are part of core and the system should see them as part of core. By being separate they make it much easier to improve them without requiring changes to core and they can be tracked as versions of the extensions. I believe 2.6 is moving in this direction but I haven't looked through the core to see if this is the case yet. These are extensions of the core/system and not to be confused with modules or add-ons for the modules.

Modules - These are programs added to the site to perform a specialized job. These generally are only loaded when needed and are treated much differently then the core. They should be able to make use of extensions as if they were part of the core since they are extensions of the core. Modules may contain their own extensions/plug-ins but these should be contained withing the module directory.

Frameworks - These are packages of code that are intended to do functions that are commonly done. Hopefully with 2.6 somewhere along the line a new framework intended to make Module building much easier will be created. We have a couple alpha/beta frameworks that have been made available in XMF and RMCommons but hopefully we can combine them together at some point and make a really well done framework.

Libraries - This is a proposal I have been pushing and probably won't be utilized until I show it works and design a system. We can look at windows DLL files to see how something like this might work. A Library system can make module interactions and code reuse much easier. The idea is that you pull all of the core code out of a module and place it into a reusable library. This library then can be used by ANY module to produce the results intended. If we then make sure our modules use templates to do all output then the module becomes a MVC structure with the templates being the V, the Library being the M, and the actual module being the C part. I have explained this further elsewhere..
https://xoops.org/modules/newbb/viewtopic.php?start=0&topic_id=73281&order=ASC&status=&mode=0

Attending College working towards Bachelors in Software Engineering and Network Security.

2
redheadedrod
Re: Xoops 2.6 , Theories, Definitions and how modules are likely to break.

A word about databases...

Wishcraft talks about ADOdb here:
https://xoops.org/modules/newbb/viewtopic.php?topic_id=70909
And more here:
https://xoops.org/modules/news/article.php?storyid=6098

I go into this extensively here:
https://xoops.org/modules/newbb/viewtopic.php?post_id=344906

Basically in short...
If you think of Database connectors as similar to drivers I will list the ones that important and make short descriptions.

MySQL - This connector is bases on MySQL database 3.x and does not include support for new features that came with 4.x or 5.x. This is the connector that Xoops is based on. This connector has been under a "soft depreciation" for years, has been rumored to be truly depreciated as of PHP 5.4 and rumored to be removed as of PHP 5.5. When this is removed the database will no longer work which means Xoops will stop working. While this connector does not support new features is it NOT a bottleneck. Anything that replaces it without major core modifications will not run any faster. Speed increases will come with the use of new features supported by other connectors within the core. Unfortunately, the vast Majority of Tutorials, books and Classroom type classes still teach MySQL connector instead one of the newer ones.

MySQLi - This connector was built to take advantage of MySQL 4.x and 5.x databases and is the preferred replacement for the older MySQL connector. This has both OOP and Procedural based methods which allow it to completely replace MySQL in most cases by simply replacing code as well as allowing for newer OOP programming when necessary. I have seen references to this in the 2.6 code I have looked at. All new features of the newer database versions are supported. This will NOT increase the speed of the core without making use of the new features in the core code.

ADODB - This makes accessing databases similar to windows based connections. There is a version available through source forge as well as a similar project with the same name available as a PEAR extension. This code is unsupported at this time and written in PHP for both versions. This does allow use of many different databases with the same code so it becomes very simple to change databases with minimal code changes. It also supports MOST of the features of the newer databases but since they have been unsupported for years some of the most recent features may be missing and any future features will not be supported as well. This is not a normally installed library and needs to be installed by the user. Speed increases for this connector require not only changes to the core code to take advantage of the new features but also requires a PHP compiler or something similar to speed up the PHP code.

PDO - This is very similar to ADODB but has no connection to Microsoft's database connection system. This supports many databases and is written in C code and compiled. PDO has been included since at least PHP 5.2 and possibly sooner. PDO is currently supported and being further developed. It should work fine with any new databases or new features that come out. Minimal code changes are required to make this work with other databases.


Attending College working towards Bachelors in Software Engineering and Network Security.

3
redheadedrod
Re: Xoops 2.6 , Theories, Definitions and how modules are likely to break.

There are two different reasons for Modules to break with 2.6. But before going into that I will mention that it is my understanding that the core developers will be doing their best to Depreciate the current code with the intent of removing it totally for 2.7. This means that we can expect MOST modules to work with 2.6 if they work with 2.5.5 but they will need to be upgraded totally to work before 2.7 and there will be "depreciated" warnings given when in debug mode. But as with 2.5.5 it is likely thinks will still need to be tweaked somewhat.

Two reasons for Modules to break:
#1 Database code. If the code uses anything other than the true Xoops API they will stop working when any other database connector is used. Due to the lack of documentation when building modules and some missing features some developers required they accessed the MySQL connector directly. If the module does ALL of its own Database code then it will still work as long as the Database is MySQL and the connector is still supported. Once a different database connector is used or a different database then the Module will error out unable to connect to the database. The solution here is to make sure only Xoops API code is used. When a module is upgraded to "blue move" the database code needs to be modified to only use the API code.

#2, with the changes to the core from using many Global variables to incorporating all of them into one class, Modules will not work with the old syntax and will require changes but these changes will be very simple. Anyone with the experience to be a web master will be able to make the changes required.
For more details go here...
https://xoops.org/modules/newbb/viewtopic.php?post_id=342559#forumpost342559
Attending College working towards Bachelors in Software Engineering and Network Security.

4
irmtfan
Re: Xoops 2.6 , Theories, Definitions and how modules are likely to break.
  • 2012/8/24 9:04

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Quote:

Extensions - these are optional components that are not required but are added to help extend the functions of the core. Operationally they should appear as if they are part of core and the system should see them as part of core. By being separate they make it much easier to improve them without requiring changes to core and they can be tracked as versions of the extensions. I believe 2.6 is moving in this direction but I haven't looked through the core to see if this is the case yet. These are extensions of the core/system and not to be confused with modules or add-ons for the modules.

I wrongly thought so. but after installing 2.6.0 alpha 1 i saw that they are common modules and nothing more.
Please see the code of new modules. it will take just 5 minutes for you.
I wish the extensions will be something you describe them in the 2.6.0 final version.

about MySQL:
Quote:

has been rumored to be truly depreciated as of PHP 5.4 and rumored to be removed as of PHP 5.5.

it is really dangerous for us. once we can be sure about it we should do some immediate actions. therefore i think we should move ASAP to other connectors.

about ADODB:
Quote:

This code is unsupported at this time and written in PHP for both versions.
.....
This is not a normally installed library and needs to be installed by the user. Speed increases for this connector require not only changes to the core code to take advantage of the new features but also requires a PHP compiler or something similar to speed up the PHP code.

very bad. we should leave it.

about PDO:
Quote:

This is very similar to ADODB but has no connection to Microsoft's database connection system.

this is very good!
Also IMO core team must move from MyISAM and add Innodb.

Quote:

we can expect MOST modules to work with 2.6 if they work with 2.5.5 but they will need to be upgraded totally to work before 2.7 and there will be "depreciated" warnings given when in debug mode.

From what i see in codes the above is not done correctly.
I can see many errors in installing some new modules that worked fine in 2.5.5
Core team should correct them. Also some members like me and you should test more and report.

Quote:

The solution here is to make sure only Xoops API code is used.

we should promote that more.
I cannot see any module that use only Xoops API. module developers dont know Xoops API completely and Xoops API in 2.5.5 is rather more complex than 2.6.0 with some parallel methods (eg: global variables and classes and functions.)
I hope in 2.6.0 all module developers just use Xoops API to connect to database.

Also core team deprecated all useful functions like formatTimeStamp and promote to use XoopsLocal::formatTimeStamp instead which i still dont know the reason.
could you tell me that great reason?

I have more to say but now i have not time.

5
redheadedrod
Re: Xoops 2.6 , Theories, Definitions and how modules are likely to break.

Quote:

irmtfan wrote:
Quote:

Extensions -...

I wrongly thought so. but after installing 2.6.0 alpha 1 i saw that they are common modules and nothing more.
Please see the code of new modules. it will take just 5 minutes for you.
I wish the extensions will be something you describe them in the 2.6.0 final version.

As I said, I believe they are moving in that direction.. Separating them into modules is a great first step. Not sure how this will impact modules using things like the ratings system though...

Quote:

about MySQL:
Quote:

has been rumored to be truly depreciated as of PHP 5.4 and rumored to be removed as of PHP 5.5.

it is really dangerous for us. once we can be sure about it we should do some immediate actions. therefore i think we should move ASAP to other connectors.

I converted the current MySQL connector to the newer MySQLi connector and tested it with an older 2.5.x variant for about 10 minutes and It worked fine for me. This could be further debugged and used if necessary. It MAY work as is but like I said, I have not tested it with other modules I just tested it with the core and it ran fine.

See here for details:
https://xoops.org/modules/newbb/viewtopic.php?post_id=347185#forumpost347185

Quote:

about ADODB:
Quote:

This code is unsupported at this time and written in PHP for both versions.
.....
This is not a normally installed library and needs to be installed by the user. Speed increases for this connector require not only changes to the core code to take advantage of the new features but also requires a PHP compiler or something similar to speed up the PHP code.

very bad. we should leave it.

Yes and if you look at the code that Wishcraft has made available in the SVN it is hard to follow because he jumps around and can be rather cryptic.
http://xoops.svn.sourceforge.net/viewvc/xoops/ThirdParty/adodb/
When the PDO topic is brought up I think Simon gets confused and brings up the adodb stuff but this would need lots of work to make it worthy of putting into the core if it even works.
Oh and again, we do NOT want ADODB.. It will be SIGNIFICANTLY slower than the current MySQL or MySQLi connector when not used with a PHP accelerator of some type. It is very confusing from the files here what Simon is actually using. I offer the link here so you can see for yourself.

Quote:

about PDO:
Quote:

This is very similar to ADODB but has no connection to Microsoft's database connection system.

this is very good!
Also IMO core team must move from MyISAM and add Innodb.

I saw mention that the databases were getting converted to Innodb but my research shows that ONLY when you are using the new features of MySQL 4.x+ is this a good thing. If you are using a simple database that doesn't need transactions or possibly some types of external (Foreign) keys MyISAM is still substantially faster.

Quote:

Quote:

we can expect MOST modules to work with 2.6 if they work with 2.5.5 but they will need to be upgraded totally to work before 2.7 and there will be "depreciated" warnings given when in debug mode.

From what i see in codes the above is not done correctly.
I can see many errors in installing some new modules that worked fine in 2.5.5
Core team should correct them. Also some members like me and you should test more and report.

I gave the link to what Trabis said but Trabis has not been involved for a while due to other obligations. I believe that it should not be a big deal to provide code with depreciation warnings but I am not a core developer. But for this and other reasons when Module developers develop new modules they SHOULD separate xoops related code into their own classes to make converting to newer versions simpler but that is on the Module Developer. At this time there is very little useable Module Developer Documentation that is up to date. This is a huge problem and one Mamba has been trying to get done for a long time but he needs a module developer to spend the time to develop the resource.

Quote:

Quote:

The solution here is to make sure only Xoops API code is used.

we should promote that more.
I cannot see any module that use only Xoops API. module developers dont know Xoops API completely and Xoops API in 2.5.5 is rather more complex than 2.6.0 with some parallel methods (eg: global variables and classes and functions.)
I hope in 2.6.0 all module developers just use Xoops API to connect to database.

Also core team deprecated all useful functions like formatTimeStamp and promote to use XoopsLocal::formatTimeStamp instead which i still dont know the reason.
could you tell me that great reason?

I have more to say but now i have not time.


I can't speak for the developers here but I believe moving to the all inclusive $xoops class is to simplify things and help get away from extensive global variable use. The more use of global variables the less secure it becomes.

Also, another item that should be mentioned about PDO is that it is SIGNIFICANTLY more secure than the MySQL and MySQLi connectors. I don't know about the ADODB connector in this respect but the security aspect is secondary only to the choice of databases in importance for moving to PDO.

Again, even if 2.6 does break 100% of modules as I expect it does right now at the alpha 1 stage, it is NOT a big deal to convert modules over based on Trabis's comments. But if we don't have transitional code to make it work while showing "depreciated" it will surely need to be well documented and pointed out in numerous places.
Attending College working towards Bachelors in Software Engineering and Network Security.

Login

Who's Online

83 user(s) are online (59 user(s) are browsing Support Forums)


Members: 0


Guests: 83


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits