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

well, any good ISP provides php5 for ages.
Now with the gophp5 initiative (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)

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...

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

Developer Quotes

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

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.

Quote:

Totally agree. In order to keep XOOPS competitive, we have to move to PHP5 to take advantage of new features/functionality. We have to develop for the future, not for the past. Otherwise we still would be developing in machine code.

But I would love to see a "Conversion Team" that would convert the most popular PHP4 modules to PHP5. Something along the lines of SmartTeam that converted/improved some of the existing modules to Smart modules.

@Giba, implementing things in the xoops_version is not restrictive to previus modules, that feature will not be able, and a warning about that: the compatibility with the "current" version of XOOPS is not SURE, nothing else, i don't think that it has to be in a module...

I had been also talking with dugris and one of my favourites features of xoopsinfo (checking the version), has a little problem, as i know not all the servers allow to read a file in another server, so, the solution is to make it as an rss reader, with xml. I ve done a little test/example and is running in a personal version directly in the module administracion page.

An excellent example that we can have using php5.

One is created install that it could generate a dynamic folder saw install with special access saw ftp that could manage the permissions and create folders TRUST_PATH and thus to be able to install modules and even though to configure the MAINFILE.PHP it are of the root web.

This is only one example that could be to become real in next editions XOOPS and already also counts of our RoadMap. More details can temporarily be seen inhttp://www.xoops.net.br.

[pt_br]
Um ótimo exemplo que podemos ter usando o php5.

Cria-se um install que pudesse gerar uma pasta din?mica via install com acesso especial via ftp que pudesse administrar as permiss?es e criar pastas TRUST_PATH e assim poder instalar módulos e até mesmo configurar o MAINFILE.PHP fora da raiz web.

Este é apenas um exemplo que poderia ser tornar real nas próximas edi??es XOOPS e já consta de nosso RoadMap também.

Mais detalhes pode ser visto emhttp://www.xoops.net.br temporariamente.
[/pt_br]

I agree with Nekro to, but....

Translated by google...

We need with urgency of a stated period to be able to adjust the dependences of suggested the new modules and to add features in the blocks.

For standard I already am bringing up to date some things that are being suggested for the module xoopsInfo by Dugris.

The ideal would be to include this verification in the XoopsInfo module so that it makes the verification in the modules.

If not to include new features in xoops_version, would be considered as being incompatible from one determined date.

Now we need to define from when will be this date?

[pt_br]
Precisamos com urgência de um prazo para poder adequar as dependências dos módulos e adicionar as novas features sugeridas nos blocos.

Por padr?o eu já estou atualizando algumas coisas que est?o sendo sugeridas pelo módulo xoopsInfo by Dugris.

O ideal seria incluir esta verifica??o no módulo XoopsInfo para que ele fa?a a verifica??o nos módulos.

Se n?o incluir as novas features no xoops_version, seria considerado como sendo incompatível a partir de uma determinada data.

Agora precisamos definir a partir de quando será esta data ?
[/pt_br]