<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
thank you for your support and for your words on PHP compatibility.<br>
<br>
After reading your post i've done some research on PHP.net site to find
out big changes from 5.1.6 to 5.3 and i've only found the changelog. Do
you know if there are resources that can give us some extra
informations on it? Also on the PHP 6 roadmap... just to write
php6-ready code...<br>
<br>
Thank you in advance<br>
SImone Capra<br>
<pre class="moz-signature" cols="80">_______________________________________________________
Simone Capra
E.R. WEB - s.r.l.
P.zza Risorgimento,12
13100 - Vercelli
tel. +39 0161 210090
mob. +39 335 5257182
Mail: <a class="moz-txt-link-abbreviated" href="mailto:capra@erweb.it">capra@erweb.it</a>
<a class="moz-txt-link-freetext" href="http://www.erweb.it">http://www.erweb.it</a>
</pre>
<br>
<br>
Michael Stauber wrote:
<blockquote cite="mid:201107100620.22782.mstauber@blueonyx.it"
type="cite">
<pre wrap="">Hi Chuck,
</pre>
<blockquote type="cite">
<pre wrap="">Are you saying Michael - that they've made so many changes in PHP that code
written under 5.1 and 5.2 won't run under 5.3? What absolute STUPIDITY is
that?
</pre>
</blockquote>
<pre wrap=""><!---->
Hard to say. Ask the guys and gals over at php.net. :o)
I also think that some of the changes in PHP-5.3 are a bit on the stupid side
of things. Others are uncomfortable, but the reasoning behind it is
understandable. Like being forced to switch from Register_Globals "on" to
"off". That change (and the need for it) has been anounced years ago and
finally there is a PHP version that leaves you little choice and forces people
to adapt.
I have less understanding for deprecating all the POSIX functionality such as
the old ereg_replace(), ereg(), eregi_replace(), eregi(), split() and spliti()
functions and forcing people to switch to the respective PCRE compliant
counterparts.
Some changes are simply nuts - such as deprecating split(). Am still shaking
my head over that one.
All in all the changes that PHP-5.3 has forced on BlueOnyx weren't really
funny. It took weeks to go through the code and to find and replace all the
deprecated functions with their modern counterparts, so I understand your
pain.
The roadmap for PHP6 outlines another set of massive changes, which I'm also
not really looking forward to.
</pre>
<blockquote type="cite">
<pre wrap="">I'm angry with whoever is in charge of the PHP efforts! Why in the world
would they update later versions of PHP so they won't run older scripts?
Wouldn't that seem to be a base function of any upgrade development -
"Don't break what's already out there while trying to improve it!"
</pre>
</blockquote>
<pre wrap=""><!---->
Well, PHP is always evolving and they're of course trying to stay at the
forefront of things and to offer new functionality and more advanced features.
At the same time there is the constant need to make things more secure and to
tweak a little more performance out of the existing engine. If one would keep
all the "old baggage" and would make everything 100% downwards compatible, it
would hurt performance and would increase code maintenance efforts. And some
things (Register_Globals) were never a good idea to begin with. If that
wouldn't have been outright dropped from PHP (as it will be), people would
just configure their PHP in a downward compatible fashion and would continue
to run the old and unsecure scripts, which invite abuse and exploits.
Programmers are often a lazy bunch. If something works, then why change the
code? For years I've thrown all scripts away which forced me to run my PHP
with "Register_Globals = On", because if a programmer really insisted on that,
there certainly were other surprises in the code which I wouldn't like either.
Likewise the guys at php.net can't and won't maintain several branches of
their code for all eternity. So while they're working on PHP-6 and PHP-5.4,
PHP-5.3 is the current "stable" version. So that's already three different
code branches that need to be maintained, which is a hell of a lot of work.
PHP-5.2 has already been earmarked as "no longer supported". So it joins the
fate of PHP-5.1, PHP-5.0 and PHP-4, which all are since long phased out.
This kind of forces OS vendors who still ship older versions of their OS with
older PHP versions to mind their own business with patching vulnerabilities in
the respective PHP versions that they may include. Which is nothing new.
RedHat for example has done this for years.
</pre>
<blockquote type="cite">
<pre wrap="">UUHHHGGGG!! More admin work for me - just to keep separate boxes for
different PHP support!!
Any ideas or suggestions??
</pre>
</blockquote>
<pre wrap=""><!---->
Unfortunately the best approach there is to stay on top of things and
personally I wouldn't spend too much effort into maintaining various boxes
with different PHP versions. Personally I'm already getting uneasy with
running PHP-5.2 for much longer, as it's now unsupported. Still running it may
be fine for a little while longer, but sooner or later it'll have to be
retired from production boxes.
Vulnerabilities in old PHP scripts are one of the more common attack vectors
for defacements and hacks. Likewise, bugs in older PHP versions may also
eventually surface and may lead to openings that one would rather not have.
So if you use popular scripts such as phpBB, Joomla, Typo3 and all their
cousins, you are kind of forced to stay on top with updates of said scripts.
Because often if there is a critical vulnerability, a lot of malicious people
will do automated drive by attacks to deface of hack as many sites as possible
all over the place.
Most of the more popular PHP projects keep track with the iffy goings at
php.net and make sure that their newest scripts also run on the newest stable
PHP versions. And usually newer versions of those scripts also add new
features, or fix stuff that didn't work right before. So you can always "sell"
such an update as "feature" update to your clients to sweeten the transition.
If you run all those scripts for yourself, this extra maintenance can
sometimes burn a hole into your pocket, as you may have to set aside some time
every couple of weeks or months to make sure you stay fully updated.
But if it's custom code, or code from some inactive project, or something your
client(s) pieced together themselves, then it sure can become a support
nightmare and/or may lead to client dissatisfaction.
Typically I tend to say: If a client requires me to configure my server in an
undesireable (unsafe) fashion, or requires me to run unsafe or horribly
outdated software (such as PHP-4 for example), then I would exile him onto a
dedicated box that he accepts 100% responsibility at an extra price. At the
same time I'd make sure that the box gets backed up twice as often as any
other box. But that's just my solution and it may not work for everyone. :o)
Not staying on top of things for the sake of simplicity will otherwise hurt in
the long run. Sooner or later the technological gap between what you need to
run (i.e.: old code!) and where you can run it will be unbridgeable.
</pre>
</blockquote>
</body>
</html>