Greetings!

My job is making me croak at a snails pace! .. :evilgrin: Here's my problem, I've been given the task of using PHP with Oracle for a web application. Oracle is not the problem, having me work with PHP v4.3.9 is!!! :evilgrin::evilgrin::evilgrin: When I started this tast, the first thing I suggested was to upgrade PHP. Not only was the version unsupported but it had its quirks.

Needless to say I'm asking how easy/difficult it would be to upgrade? Seems my suggestion to the "powers-that-be" has been pushed to bottom, I want to know if there is anything that's keeping them from upgrading. If it helps any, it's on a Unix server ( both PHP and Apache needs to be upgraded!)

Thanks in advance,

V

    VAC357;11019785 wrote:

    I'm asking how easy/difficult it would be to upgrade?

    How easy is... what? How easy is it to update the PHP binaries from one version to another? In most cases, it's pretty simple - even if you're accustomed to building PHP from source rather than just grabbing it from your distro's normal repo via a package manager.

    How easy is it to examine every PHP script in use under the old version and ensure that the PHP upgrade won't break those scripts without making any changes? Depending upon a number of variables (no pun intended), that could certainly be a non-trivial task. The best way to proceed is the common method of deploying the change to a development server, testing out your code base, and only once you've ensured everything works as expected will you then make the change "for real" in your production environment.

    It's really hard to say "what will it take to upgrade?" without seeing the code. If it wasn't written using best practices (which, at the time, may have appeared more as "forward-thinking" practices), then you'll probably run into problems. The PHP language has grown and evolved over the past few years (IMHO, at least), and the "best practices" have of course adapted to these changes over time as well.

    VAC357;11019785 wrote:

    I want to know if there is anything that's keeping them from upgrading.

    Change. That's what stops a lot of people from doing a lot of things. From management's perspective, upgrading PHP can take time (time == money) that will probably yield little to no gain for the customers/end users.

      One thing that would be needed is a review of the code base, with the migration guides in mind ([man]migration5[/man] ff.), particularly the sections on "backward incompatible changes". The Changelog [man]changelog5[/man] provides a more thorough (but much more terse) list of changes.

      A test suite for the code base would be a valuable asset at this point, to ensure that existing code still behaves the same (PHP has been known to silently start functioning differently from version to version; this is one reason why many organisations are leery of change just for the sake of it).

        bradgrafelman;11019793 wrote:

        How easy is... what? How easy is it to update the PHP binaries from one version to another? In most cases, it's pretty simple - even if you're accustomed to building PHP from source rather than just grabbing it from your distro's normal repo via a package manager.

        How easy is it to examine every PHP script in use under the old version and ensure that the PHP upgrade won't break those scripts without making any changes? Depending upon a number of variables (no pun intended), that could certainly be a non-trivial task. The best way to proceed is the common method of deploying the change to a development server, testing out your code base, and only once you've ensured everything works as expected will you then make the change "for real" in your production environment.

        It's really hard to say "what will it take to upgrade?" without seeing the code. If it wasn't written using best practices (which, at the time, may have appeared more as "forward-thinking" practices), then you'll probably run into problems. The PHP language has grown and evolved over the past few years (IMHO, at least), and the "best practices" have of course adapted to these changes over time as well.

        Change. That's what stops a lot of people from doing a lot of things. From management's perspective, upgrading PHP can take time (time == money) that will probably yield little to no gain for the customers/end users.

        Thanks for the reply. In my estimation, the upgrade wouldn't be costly as the current page is running using html exclusively. PHP allows me to use Oracle which is what has been asked. The impact would be minimal as I'm the only one who is working on this.

          Weedpacket;11019819 wrote:

          One thing that would be needed is a review of the code base, with the migration guides in mind ([man]migration5[/man] ff.), particularly the sections on "backward incompatible changes". The Changelog [man]changelog5[/man] provides a more thorough (but much more terse) list of changes.

          A test suite for the code base would be a valuable asset at this point, to ensure that existing code still behaves the same (PHP has been known to silently start functioning differently from version to version; this is one reason why many organisations are leery of change just for the sake of it).

          Thanks for the reply. A test environment would be ideal (can 2 versions of PHP exist?). I've been plugging away using PHP 5.4 along with Oracle on my network at home, so you can only imagine the frustration I'm encountering using v 4.3.9!

          Points of change are valid. As explained in my previous post, I'm the only one currently using PHP for this project and I would think an upgrade would have minimal downtime... especially since I've been asking before committing to excessive amounts of coding.

            VAC357;11019907 wrote:

            A test environment would be ideal (can 2 versions of PHP exist?).

            You can install PHP in two different locations and configure a webserver to use both (one as an ISAPI filter, one as a CGI binary), however you'd probably want to use an entirely separate server (virtual or otherwise) if possible so as to minimize any impact (intentional or otherwise) between your existing environment and the new one.

              Virtual man, virtual! Again I say, Virtual.

              (I use the latter ... I can set up whatever environment I'd like --- those who've been around here a while, or use the search feature, can probably make a fairly respectable guess what that usually is....).

                Write a Reply...