I think the first step is to make the XOOPS core 100% php5 compatible. If thats already the case, excellent. Next step is to work on getting the modules php5 compatible, and a conversion team wouldn't be a bad idea since many modules are no longer maintained.

After that, if it is the case that php5 is widely used and necessary in order for XOOPS to stay innovative, then stop supporting php4. However, I don't see that happening in the short term. I've yet to see a major CMS drop php4 support, because doing so would seriously threaten its user base. Thats my opinion, I'm sure some would argue differently.

I would compare XOOPS dropping php4 support to XOOPS dropping mysql3 or mysql4 support. While dropping support for mysql3 is probably ok, dropping support for mysql4 would be a mistake.

However, I do think XOOPS should start bumping up its requirements (and getting rid of legacy code), such as dropping mysql3 support and bumping up minimum php version to 4.3 and higher.

Developer Quotes

"if you were kernel code, cutler would rewrite you."
-Alex Ionescu

Some time ago I've posted on french site support about the coming beta of php6 and the end of "magic trick era" because PHP6 suppress Magic Quotes, Register Globals but support unicode among other changes, alike static bindig and namespaces, both O.O.

With all this in mind, PHP aims to be less permissive and educate developers about the way to code PHP with objects, design patterns and security.

But maybe some think there's nothing to learn from past mistakes and maybe some others think that code review is a painful experience for everyone and should still looking forward. But when you get everything together, alike Mr. Minahito has done with XC Legacy code, most XOOPS 'developers' may find themselves unskilled.

Why audit XOOPS code?

Most of you are able to quote code from the 10 most used modules and show the code style of different developers (i.e. code badly integrated).

And people wonder why XOOPS and modules code are always full of security holes!?

As i've posted on Gijoe forums, referring to lazy developers that, since PHP is easy to learn, everyone can easily write bad php code for XOOPS (alike any other project/language). Most of the times non-professional pick up some code and start "cloning/forking" to create their own module, framework, library, etc. It's a way to learn. Right, but it also contributes to the perception that XOOPS PHP code is crap.

Some developers have done a badly patchwork, some even call it spaghetti PHP. While some Italian mamas may feel offended, it still working just fine for their kids under PHP4. Non-professional programmers will not care that the code is crap.

Why to reinvent the wheel?

As someone said sometime ago: They learn bad habits and then publish their code and teach others bad habits. I mean here, old hack nuke school

That may explain why some of the most popular open source PHP applications ever are really poorly coded and many nuke based cms have decide to re-code ... Drupal and Joomla come to mind.

But who can force developers to do so? It's open source. Looking at the amount of code released by programmers and third party developers, maybe... lazy... sounds not fair, but it's a reality in XOOPS world. Which needs a skilled programmer or professional developers to reduce the gap with Legacy as Minahito has done with XOOPS Cube or Gijoe with altsys and D3 modules.

Have Fun !



Ref.
Walk the Walk before Talking the Talk
"You must be disciplined enough to...
The other key ingredient of a professional developer? Humility."
Effective Code Reviews Without the Pain
By Robert Bogue

Here's my 2 cents...

1) 2.0.17 should be bug fixes ONLY. If there are known issues running with PHP5 then fix them, but do not add any PHP5 only requirements. I believe this should be continued throughout the remainder of the 2.0.x series code.

2) Future major XOOPS releases (2.4,2.5, etc), say anything after the 8/8/8 date, can/should use PHP5 functionality. This is with the caveat that core developers take responsibility to patch security holes in the previous version (say 2.0.17, 2.0.18, etc). At some future date put out a notice that 2.0.x branch will no longer be supported - maybe this should happen at the same time as a stable version of PHP6 is released (but this is something the core developers can decide later). There needs to be an end-of-life plan for previous XOOPS versions (in this case 2.0.x) or it will hang on forever, just communicate the PHP version clearly in the release so everyone knows what to expect.

Just a thought from someone who has managed large groups of software engineers, developing multiple projects and being responsible for customer support too...

well, any good ISP provides php5 for ages.
Now with the gophp5 initiative (http://www.gophp5.org), we have a great window to promote our willing to move. Let's think/promote about future, php4 is not future at all anymore.
i dream to see XOOPS on the list over there, aside phpmyadmin, drupal, flyspray.
Let's show the world XOOPS has a roadmap, on this item (php version compatibility) and on the others as well
marco (heavy dreamer)

php5 compatability << as soon as the permissions get sorted out we will dedicate a portion to this.

Well this current site isn't compatible with Php5 - which is one of the reasons it cannot be moved onto the new servers yet, and one of the reasons why the site development needs to be sorted....

@Davidl2,
This is what we have...

The site is being moved, not in one big chunk but by way of evolution.

One user at a time, lets make sure they end up on XOOPS real-estate that does not have an expiration date in the near future.

Quote:
Woh !
Xoops.org is the last to show the example ...
I understand why I don't have an official answer


Ps : Why this signature ?
Quote:

Quote:
euh what do you mean whith this 'this current site isn't compatible with Php5'?
Do you mean that this code doesn't work with PHP5? or Do you mean that you cannot have php5 on the machine?

If the first one, i think you don't have test it, because there is not great incompatibility with php4 and php5, if you have any bug, you can correct easily.
I repeat, I don't make any correction on all modules I'm using for php5... and i think i'm using a lot of modules on the site.