I'd like to ask for some feedback from the community regarding the continuation of support for PHP 4.0 in XRMS 2.0 (pending).
As some of you may be aware, the release of PHP 5.3 has marked a departure from PHP 4.0 for the PHP Group. A number of functions and extensions used in PHP 4.0+ have been deprecated starting with PHP 5.3 and, while they still do work, will eventually be dropped altogether. Those of you installing XRMS today on environments with PHP 5.3+ have to work around the deprecated messages that the XRMS code base generates. We have started to whittle away at the deprecated list but it is quite long. In addition, some of the libraries that XRMS depends on have their own issues with deprecated functions and syntax.
One particular conundrum is with ADOdb. The latest ADOdb version (4.992) which still supports PHP 4.0 flavours still contains deprecated code and syntax. All newer versions of ADOdb are PHP 5.0+ oriented only. I am about to look into the latest ADOdb version (5.11) which, from the Changelog, appears to have addressed those but, if we are to go with that version of ADOdb, we will no longer be able to officially support installations sitting on PHP 4.0 flavours. Sticking with PHP 4.0 means that we will have to hack-fix the deprecated code in ADOdb ourselves, duplicating work and possibly ending up with a library that is not as stable as the original.
Support for PHP 4.0 is likely coming to an end in other projects as well. Wordpress has announced that they will be dropping support for PHP 4.0 as of their next major release, scheduled for some time this year.
So, to make this as short as possible, if ADOdb 5.11 proves to be PHP 5.3+ worthy, we would like to simply implement that, cutting down on the work to release XRMS 2.0 and staying with a stable, officially-supported library rather than one we hacked on our own. Of course, that potentially means no more PHP 4.0 servers!
Could everyone please chime in and let us know just how important support for PHP 4.0 is in their environment so we can have an idea on the impact such a decision will have on the community?
Thank you, all, and have a wonderful day!
I have been hoping for an official update to XRMS for a long time now. I think that letting go of php4 support makes the XRMSdeveloper's job easier, so go for it! The only reason I can think of that someone would need php4 support would be if XRMS lives on a server with another app that _requires_ php4. I'm sure there are apps still running on the web (or in someone's office) that do not support php5, but please, let's not allow that to slow down the XRMS dev. team!
Regarding ADOdb, one of the greatest strengths of open source is projects building on other project's work. I think the XRMS devs should use the latest ADOdb features in the latest version of ADOdb for the benefit of XRMS.
Thank you Ivaylo, thank you Brian, thank all of you XRMS developers!
Forget about PHP4. Let's move on.
For now, this little change in include-locations.inc seems to do the trick for me (running PHP 5.3.6 on Mac OS X):
error_reporting(E_ALL ^ E_NOTICE ^ E_DEPRECATED);
Update: No, not quite - some features are still broken (e.g. reports)
The XRMS core code in CVS has been completely refactored for PHP 5.3. The plugins have not been but, at this point, I would wager that the code in CVS is considerably more stable than the old 1.99.2 Stable version. I am aware of only four bugs that are outstanding and they are relatively minor. If you are running on PHP 5.3, you are much better off running the CVS code.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.