Lets start out with the basics...

What version of PHP are you using?
What version of Xoops are you using?

Chances are that the module you are looking at is old and hasn't been updated in a while and if you are using a newer version of xoops will need to update or have the module updated.

Rodney

mysql_real_escape_string is depreciated and really should be changed to the XOOPS function that calls the proper function.

ANY Mysql code will fail when running under PHP 7.

There are Xoops functions for just about every MySQL call for 2.5 and should be used instead. Calling mysql or mysqli directly is a bad idea and may not work with 2.6.

Using the Xoops functions will work in all 2.5.x versions of xoops. And will not only work with php 5 but should also work with php 7

Wish I could help but I am swamped with school right now...

Rodney

This is not entirely true... There is a MySQLi compatible database connector that I did a while back that will be compatible.

There is a chance some modules if written poorly will clash with MySQLi but they should be simple fixes.

Only way to know for sure is to try it out. I know after I wrote it some people tried it and it seemed to work fine with anything tried..

So there IS another option to keep you going until 2.6 is available...

MySQLi is the supported driver that has replaced the MySQL driver...

Rodney

With 2.6 Profile SHOULD make use of the new Service manager..

The service manager should allow flexible use of items like this so it won't be an issue.

Rodney

Those sound like Module issues and not core issues... Core provides permissions but the module has to actually use them.

A couple more notes about MVC that we worked on in class...

The idea was that any one of the portions could be replaced with totally different code that had the same entry points.

This also makes things MUCH easier for unit testing as well as we had to demonstrate in our projects.

For our first MVC project we had to make the code work with a GUI and with a console based text output. It was a pretty complex program and it had to work equally well in either View...

Then we could take our Model and totally change the functions in another project and make it do something totally different with the same Controller and View.

It made the power of MVC very visible and made it make a lot more sense. If ADR is capable of this then I certainly wouldn't be against it either but the main point is that the change to the structure of the module makes for much easier testing, maintaining and updating.

MVC is what is being taught currently in school so ADR must be relatively new. We had extensive work in an MVC Java based environment last year and I expect it to be pushed further as I finish my degree. Doesn't mean schools can't be a little behind especially if the professors are not familiar with it either.

But in any manner. MVC, or whatever similar structure would be much better than the current structure.

As to modules... There really are significant changes that need to be made to them to take full advantage of 2.6. Things such as Smarty 3, Services Manager, Doctrine, Composer just to name a few...

So really, modules need to be better configured so they can be more easily updated to take advantage of what 2.6 has to offer.

The biggest things about future modules is that they MAY work with little updating with 2.6 but there are a BUNCH of things that are changing with 2.6 that will make rewriting many of the modules the best choice but before that happens we need to lock down some items within 2.6 more so we only need to rewrite modules once.

I would suggest any modules that do get rewritten to follow a strict MVC model so it makes things much easier to modify down the road. By making a module fully MVC you are forced to group things together in the same area instead of threading them through the code and it will make life MUCH easier down the road.

In Brief, MVC seperates a program into three sections...
M = Model - The code that does the actual work.. This should be the code that uses a lot of Xoops API. This will save variables, load them, and do all of the calculations etc...

V = View - This is the interface to the program. This would be written mostly in Smarty but setup with some basic PHP. There should be NO HTML code anywhere other than in here.

C = Controller - This is the decision making portion and basically interfaces between the View and Model. The View communicates with the Controller and based on what it needs the Controller communicates with the Model to actually do the work.

This forces you to NOT sprinkle HTML code throughout and by the grouping required should make things much easier to upgrade down the road. When you clone a module you may be able to just clone a portion of it instead of the whole thing too.

Rodney

It is nice to see some people taking interest in helping out for sure. I have not been available myself for a variety of reasons but would like to help out. Just have been stretched to thin with too much going on while working 40 hours a week and going to school. But I do know that the current Github version of 2.6 is NOTHING like 2.5.7 or even the older 2.6 alphas. Going in a great direction just taking a while to get there because of all of the old code in place. I doubt there is a file in the source that hasn't been touched.