Latest News: (loading..)

Archived

This topic is now archived and is closed to further replies.

Harald Ponce de Leon

Supporting PHP From 4.1 Onwards

16 posts in this topic

We've always had compatibility as a priority when working throughout the codebase of the project, and have only dropped PHP 3 compatibility a few months ago for the 2.2 Milestone 3 release.

 

Dropping PHP 3 compatibility has allowed us to secure and optimize the codebase which has proven to be a beneficial step during the 2.2 development path.

 

We are interested in further dropping support for PHP 4.0 webservers, to take advantage of the offerings PHP 4.1 brings, to further strengthen and optimize the core codebase.

 

The main changes dropping PHP 4.0.x support bring will be the removal of the session and session_compatible classes, and utilizing session variables natively with the super global $_SESSION variable. The great thing about doing this is not only cleaner code, but also natively using the session support PHP brings, and using native PHP session functions to control the storage of session data (file-, database-, memory-, .. based).

 

It will also allow the removal of PHP 4.0 compatibility code that sets the compatibility super global variables as globals within functions and class methods. Example:

 

 ?function some_function() {
? ?if (PHP_VERSION < 4.1) {
? ? ?global $_GET;
? ?}

? ?....
?}

 

This would then allow the use of super global variables as intended.

 

A further benefit dropping 4.0.x support is utilizing sprintf() to it's full potential, in regard with argument swapping.

 

This is important for the language support osCommerce has, as it allows the following scenario:

 

$format = "The %2\$s contains %1\$d monkeys.";
printf($format, 3, 'zoo');

 

Support for argument swapping was brought in PHP 4.0.6. We think this is an important feature to have for multilingual support, and think if a PHP 4.0.6 requirement is needed, that it should be done at the 4.1 level to gain benefit in other areas of the core codebase.

 

We would like to hear your thoughts on this issue, as we don't want to leave anyone behind, but also need to "get with the times" due to the long development cycle 2.2 has.

Share this post


Link to post
Share on other sites

Harald,

 

PHP stable release is up to 4.3.9 (and beyond to 5.0.2)...if a host will not upgrade PHP past 4.1.0 it's time for the store owner to find another host :) After all, v4.1.0 was released 10-December-2001! If that host has not upgraded software / hardware in 3 years what does that say about their committment to quality service?

 

IMO, the support and use of superglobals as they are intended will yield better performance not only on the customer side but also with respect to server resources (especially for high volume servers).

 

...with respect to argument numbering: I've been revising sites on the fly with that technique and could not understand why it wasn't used to begin with. Long overdue but a nice addition to the code base.

Share this post


Link to post
Share on other sites

I think that you should go forward. If someone needs to stick with an earlier version of PHP, then they shouldn't have a problem sticking with an earlier version of osC. :)

 

-jared

Share this post


Link to post
Share on other sites

Well, I guess sticking with logic which is years old would be ok, if you are planning to add in all sorts of supporting logic. Heck, why not support PHP3, 4 and 5 while you are at it?

 

Keep with the times and suppoort what the majority are currently using, 4.3.9 and above...

 

Using old logic does not make the system better and more robust, rather it makes it more clunky and obsolete, get rid of the old support (I know you have done so for PHP 3...).

 

Use of newer logic and narrowing down the support for the PHP logic will only make debugging and support easier for people to manage....

 

Like all things on the net, old is left behind, new is used and advanced.....

 

cheers,

 

Peter M.

Share this post


Link to post
Share on other sites
Using old logic does not make the system better and more robust, rather it makes it more clunky and obsolete, get rid of the old support (I know you have done so for PHP 3...).

 

Actually, having kept PHP3 compatibility previously has helped with securing the codebase and having a coding standards set that was forced to be applied.

 

As much as we'd like to use PHP5, we can't as it is not as common as PHP 4. We are however looking at providing PHP5 classes alongside PHP4 classes, if the benefits outweigh the extra maintenance work.

Share this post


Link to post
Share on other sites
Actually, having kept PHP3 compatibility previously has helped with securing the codebase and having a coding standards set that was forced to be applied.

 

Securing the code base and using old logic and mutually exclusive in nature. Secure code, does not imply using old logic.

 

Coding standards are set by yourslves, and as such, really do not have anything to do with version compatability issues.

 

I understand you want the system to work on as many platforms as possible, but it is time to move forward.

 

As much as we'd like to use PHP5, we can't as it is not as common as PHP 4. We are however looking at providing PHP5 classes alongside PHP4 classes, if the benefits outweigh the extra maintenance work.

 

This is fine, but I would say that the next version should be PHP 5 ready, maybe not completely compatable yet, but ready to use the newer logic, when it does become more universal in use.

 

As for the two classes (PHP 5 and 4), I would suggest that a well written class, should be pretty much compatable with both. I know there will be some differences and incompatabilities, but I would leave the full compatability for future MS releases, and leave the MS3 fully PHP4 workable.

 

Then when you start to implement the MS4 release, look to add in more PHP5 compatability, since this will allow the Internet community time to catch up to the newer logic as well.

 

cheers,

 

Peter M.

Share this post


Link to post
Share on other sites

In the abscence of any 3rd party information on what versions of PHP are most common on web servers, why not run a poll here to see what people are using.

 

Personally I can't see any reason why a jump to v4.3.0 couldn't be made, which is already over two years old. You can't keep supporting old versions for ever, and is there any justification for someone running a pre v4.3.0 version?

 

I'm not sure of what benefit there would be to writing any v5 code at present, as I doubt many web servers have it installed (except alongside v4 for testing purposes). Though getting the coee changed to take advantage of v5 features in advance could be useful for when people do start migrating.

 

Jon.

Share this post


Link to post
Share on other sites

The general impression for supporting PHP 4.1 onwards has been positive.

 

Supporting PHP 4.3 onwards is a drastic measure to take, and does not really introduce anything new to really say that PHP support should be from 4.3 and not 4.1.

 

I would love to support PHP 5 however I personally think that 2 years would be needed before it is as mainstream as PHP 4 is today. That does not mean we can take advantage of it today though, and will have classes built for PHP 4 and PHP 5 to show that even though that public project development releases are slow, that we are indeed with the times :D

Share this post


Link to post
Share on other sites
That does not mean we can take advantage of it today though, and will have classes built for PHP 4 and PHP 5 to show that even though that public project development releases are slow, that we are indeed with the times 
Harald, you and the project are more then just "with the times". You have provided a leadership and vision which has brought a powerful tool which enables the ecommerce for all people without financial bariers....

cheers to you and the team.

 

Peter M.

Share this post


Link to post
Share on other sites

Live stores shouldn?t be running with a hosting company which doesn?t keep up to date with the latest software versions. The only problem I can see is that people might be running old PHP versions on development machines (OS X comes with PHP version 4.0.6), but anybody doing this will be more than capable of upgrading. It should also be noted that phpMyAdmin requires version 4.1.0 and there can?t be many osCommerce users who don?t this.

Share this post


Link to post
Share on other sites

Is the code currently compatible with PHP v5?

 

Whilst using the new features of v5 isn't too important at present, compatibility is.

 

Jon.

Share this post


Link to post
Share on other sites
Is the code currently compatible with PHP v5?

 

Whilst using the new features of v5 isn't too important at present, compatibility is.

 

Jon.

 

The MS3 Snapshot works under PHP 5 (well what is working in it at least). MS2 does not.

Share this post


Link to post
Share on other sites

Thanks for all the feedback! We will be making this change and osCommerce 2.2 Milestone 3 will be the first project release to have a PHP 4.1 minimum requirement.

 

The PHP 4.0.x compatibility logic existing in the codebase will be removed and logic in other areas will be improved in time for the Milestone 3 release.

Share this post


Link to post
Share on other sites
The MS3 Snapshot works under PHP 5 (well what is working in it at least).

Can you tell us where to find this MS3 Snapshot? I see only MS2 in the downloads.

Share this post


Link to post
Share on other sites
Can you tell us where to find this MS3 Snapshot? I see only MS2 in the downloads.

 

agreed... i need an ecommerce solution that works on PHP5 and since osc REQUIRES reg globals i cant use it

 

and for a further note things need to be done to speed the software up... 100+ db calls per page is ridiculous

Share this post


Link to post
Share on other sites