homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

PHP 5.0.0 Released

 9:45 pm on Jul 13, 2004 (gmt 0)

it seems the date is wrong on the site ([18-Mar-2004]) so who knows if I am asleep on this one. It is also only listed on www.php.net not the ca version so who knows if it is somehow up by accident

Some of the key features of PHP 5 include:

  • The Zend Engine II with a new object model and dozens of new features.
  • XML support has been completely redone in PHP 5, all extensions are now focused around the excellent libxml2 library (http://www.xmlsoft.org/).
  • A new SimpleXML extension for easily accessing and manipulating XML as PHP objects. It can also interface with the DOM extension and vice-versa.
  • A brand new built-in SOAP extension for interoperability with Web Services.
  • A new MySQL extension named MySQLi for developers using MySQL 4.1 and later. This new extension includes an object-oriented interface in addition to a traditional interface; as well as support for many of MySQL's new features, such as prepared statements.
  • SQLite has been bundled with PHP. For more information on SQLite, please visit their website.
  • Streams have been greatly improved, including the ability to access low-level socket operations on streams.
  • And lots more...
  • changelog [php.net]



     9:51 pm on Jul 13, 2004 (gmt 0)

    I suppose I could update RC1 now on the test box...


     9:55 pm on Jul 13, 2004 (gmt 0)

    sounds like a plan ;)

    I have to run full regression on some software in a dev environment in a couple weeks then I guess. Sounds like a barrel of fun.


     2:24 am on Jul 14, 2004 (gmt 0)

    I haven't been keeping track of the PHP5 development at all. Is it 100% backward compatible with PHP4?


     2:40 am on Jul 14, 2004 (gmt 0)

    And how long before my webhosts upgrade? :(


     2:51 am on Jul 14, 2004 (gmt 0)

    Hopefully not to soon. I like to let other people be the fodder for .0 releases :)

    A big reason why I manage my own servers. I can be sure all apps work before I do an upgrade.



     4:10 am on Jul 14, 2004 (gmt 0)

    Is it possible to run PHP 4 and PHP 5 on the same machine at the same time using different extensions?


     5:23 am on Jul 14, 2004 (gmt 0)

    >> same machine at the same time using different extensions

    I wouldn't, sounds painful, different boxes, fine.

    >> And how long before my webhosts upgrade?

    1 - 5 yrs I would guess ;)

    >> Is it 100% backward compatible with PHP4?

    as far as I know it should be, I will tell you if I have any horror stories.


     5:37 am on Jul 14, 2004 (gmt 0)



     8:57 am on Jul 14, 2004 (gmt 0)

    PHP 4.3.8 has also been released.


     12:24 pm on Jul 14, 2004 (gmt 0)

    I can tell you one issue that I've seen during testing on RC1. PHP 5 introduces private and protected member variables as well as private and protected methods, and have deprecated the
    var keyword. So, in STRICT error_reporting mode, something like this...
    class myClass { 
    var $days = array("Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat");

    ...results in this...
    Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in ...

    Just a heads up for those going down this road.

    A good resource regarding this:


     2:27 pm on Jul 14, 2004 (gmt 0)

    Hmmm... PHP 5 has some great features, and PHP is fantastic for web programing... but PHP 5 is losing probably the biggest advantage of PHP... that it is ubiquitous.

    The fantastic thing about PHP is that it is extremly common. Every webhosting company out there offers your standard L.A.M.P. server. If I write a web application, and I need a new server, or I switch to a new host, or whatever the situation may be, I know that my project is extremly mobile. I can switch my PHP/MySQL apps to a new server in less than an hour.

    If PHP 5 isn't immediatly adopted and quickly becomes part of the ever common LAMP platform, then using it is pointless. If I need to dramaticly reconfigure my server to use PHP5, and I can't easily migrate to another server without a load of trouble, then why shouldn't I use Python, or Ruby, or even a custom web server in C++? If I am going to do the work for an uncommon configuration and limit myself to only custom configured machines, why not just make the jump to a better technology?

    PHP 5 is of course nessicary in order to keep PHP modern, but it could also bring a quicker death to PHP.


     2:32 pm on Jul 14, 2004 (gmt 0)

    You can always change the configuration options to what you require for your particular installation. STRICT mode is not "on" by default. The code will still run just fine on PHP4 or PHP5.


     2:58 pm on Jul 14, 2004 (gmt 0)

    Yes, but if you want to use PHP 5 features, then PHP is no longer ubiquitious.


     3:14 pm on Jul 14, 2004 (gmt 0)

    Ah. You're saying web hosts should always upgrade right away to the latest and greatest to utilize new features. Being a hosting provider with multiple users on a single server causes issue there, my friend. I would say the best thing to do is manage your own and you can upgrade whenever you desire.


     3:19 pm on Jul 14, 2004 (gmt 0)

    Yes, but if you want to use PHP 5 features, then PHP is no longer ubiquitious.

    And if you want to use PHP4 only functions, they won't work in PHP3. Some recent additions to PHP4 won't work in earlier versions of PHP4. Such is life. To add anything to PHP means a previous version won't work with whatever is added. What can we do. Some servers are still on versions of PHP pre-the change to register_globals being off by default. I imagine if they were to upgrade, many users' scripts would fail (unless they used $variable = $_GET['variable']; at the head of their pages).


     3:37 pm on Jul 14, 2004 (gmt 0)

    That's not the big issue. The big issue is backwards compatibility. If I write an app in PHP4.3.1 I expect that it will work the same in PHP4.3.7.

    The big question is will it work in PHP5.0.0

    If you use new features you can never expect that it will work with other versions.

    To get around this I've used function_exists() and if it doesn't I create a small hack function that does the job. Off the top of my head I can't remember what I needed to do this for but a new (and simple) function was created in newer versions of PHP but for backwards compatibility I wrote a PHP function to do the same and the built in function and only created it if it didn't exists.

    Anways that's something different, Trying to get new code to run on old version you should expect to have issues.

    Running old code on new versions you should expect to have it work :)


     7:44 pm on Jul 14, 2004 (gmt 0)

    Is it possible to run PHP 4 and PHP 5 on the same machine at the same time using different extensions?

    Not a big problem at all. I've had 3 or 4 different versions of php going before. You just need to have a separate apache install for each php install. The trick is more in getting your httpd.conf files right. If you want to test php 5 try having your new apache install listen to a different ip address or port (ie 8080).


     5:55 am on Jul 15, 2004 (gmt 0)

    For you guys that have been working with 5.0 for awhile... in your opinion what's the best reasons to migrate? Do you notice an increase in performance? New features that you can't live without? Anything else?


     8:52 am on Jul 15, 2004 (gmt 0)

    Running old code on new versions you should expect to have it work

    I hadn't thought of it the other way round. There could be problems with PHP5 then as it introduces new (replacement) things like the new Zend engine and XML parser.

    Again, it's a case of having to accept this in the name of improvements. It's like you can't expect your VCR tapes to play in a DVD player.

    The PHP online manual is handy for finding alternative scripts when new features aren't available. Often I've seen users post workarounds for missing features.

    Ideally a multi-function script might be written that queries the version of PHP and uses the correct script to match. Now that would be compatibility!


     1:31 pm on Jul 15, 2004 (gmt 0)

    I guess people are unduly worried about backward compatibility. PHP 5.0.0 Beta 1 came out more than a year ago. It was followed by 3 betas and 3 release candidates. Thousands of developers have been playing with it and filing bug reports and fixing bugs. I don't think it will break any applications out there.


     1:44 pm on Jul 15, 2004 (gmt 0)

    The PHP Options/Info function set allows you to get a lot of information about PHP itself, including the version [php.net]. I've seen it used quite often in exactly the manner you describe here -- determine the version and use features in your application accordingly.

    You ask a tough question, and you'll get a million different answers, but I'll give you my take on it. I've been running the beta with little or no issues so far. (First off, why subject yourself to beta? Well, to help further the development for one, but that's a whole new thread). The best reasons to migrate to any new release will not just be feature-set, although that can often be a driving factor. As a matter of fact, that is often what drives new releases -- a customer has a requirement that they forward to development and the dev team says, "yeah, we should add that to our product in the next release". The dev team gets it ready and does a beta release. Customer realizes it is "ready" and puts the beta in place to start using the new feature. Bugs get worked out, etc. and eventually a version release is approved and published. Does that mean you or I should get on that release? Not really, not if I don't need the feature. If there were security updates or performance enhancements that tickled our fancy, now that would alter our decision-making quite drastically. However, with any software upgrades or rollouts, you really need to assess the changes and the impact to your particular installation before anything else. Then if the decision is to implement the upgrade, you first need to test, test, test before GO LIVE. That said, the single area that I would take under serious consideration for anybody using PHP objects is going to be in the area of the New Object Model, as I mentioned earlier. The Zend article states that PHP's handling of objects has been completely rewritten, allowing for better performance and more features.


     2:56 pm on Aug 28, 2004 (gmt 0)

    Back to using pre 5 script version in a 5 environment

    this can be used a quick fix
    not the most elegant but should save time
    your opinion?

    if (!function_exists('version_compare')) {



     8:33 pm on Aug 28, 2004 (gmt 0)

    Is the above function
    Daisho's function?


     2:21 am on Aug 29, 2004 (gmt 0)

    That ones not mine. I never used the $HTTP_ variables. I went straight from register globals to the super globals.

    But that's the type of idea I've done to make sure I didn't have to worry about the php version to much.


    Global Options:
     top home search open messages active posts  

    Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
    rss feed

    All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
    Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
    WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
    © Webmaster World 1996-2014 all rights reserved