Help the Ukraine
The PHP 4.2 Issues In Detail
 |
| Last updated: 6/26/2002; 10:05:43 PM |
|
 |
Marketing 101. Consulting 101. PHP Consulting. Random geeky stuff. I Blog Therefore I Am.
The PHP 4.2 Issues In DetailAll,
As I noted in an earlier blog entry, I got what I feel is HOSED (that's not good) by the 4.2 release of PHP when my ISP installed it today. Maxim, my editor in chief at www.phpbeginner.com, was technically savvy enough to attempt to make this acceptable to me. And he did a great job. But you'll see my final response at the end.
I'd also like to really, really thank Guy K. Haas who was nice enough to both edit this document and confirm that I'm not nuts (at least to him, or we're both nuts). Guy has a history of working at the ANSI standards level for programming languages so it's fair to say that he more than understands this.
Note – This one is real geeky although at least one of the fundamental issues at hand is economic.
– Scott
Email 1: From Scott to Maxim
> -----Original Message-----
> From: J. Scott Johnson [mailto:scott@fuzzygroup.com]
> Sent: Wednesday, June 26, 2002 9:00 PM
> To: 'Maxim Maletsky'
> Subject: PHP 4.2 that sucky ass update
>
>
> Hi there,
>
> Has anyone covered the issues with 4.2 and how form elements
> don't magically become variables anymore? This just broke,
> well, MY WHOLE SITE. And I'm leaving my ISP because of it
> (principles you know).
>
> Scott
>
> * * * * * * * * * * * * * * * * * * * * * * * * * *
> Company: The FuzzyGroup, Inc.
> What We Do: Quality web development / eVectors IdeaTools VAR
> Title: President
> Phone: 781 592 0262 / 617 970 4719
> Email: sjohnson@fuzzygroup.com
> Site: http://www.fuzzygroup.com/
> Blog: http://scott.blogs.at/
> Yahoo IM: fuzzygroup
> AOL IM: fuzzygroup
> Emergency: mobile@fuzzygroup.com
> * * * * * * * * * * * * * * * * * * * * * * * * * *
>
Email 2: From Maxim to Scott
-----Original Message-----
From: Maxim Maletsky [mailto:maxim@phpbeginner.com]
Sent: Wednesday, June 26, 2002 3:21 PM
Subject: RE: PHP 4.2 that sucky ass update
I knew about it because I am the PHP Dev Member. It was also documented.
Too sad these freaks of your ISP did not give a damn and did not bother
letting you know it in advance (or at least change the default settings
in the php.ini). They should be more responsible about such changes. I
can imagine many getting broken sites like you just did...
I saw http://www.fuzzygroup.com/php/faq/ - you better close the accesses
to the site before fixing it. It can be theoretically dangerous.
Meanwhile you are migrating to a better place, try adding the directives
in your .htaccess or directly the scripts if your ISP allows you to...
Sincerely,
Maxim Maletsky
Founder, Chief Developer
www.PHPBeginner.com // where PHP Begins
Email 3: From Scott to Maxim
-----Original Message-----
From: J. Scott Johnson [mailto:scott@fuzzygroup.com]
Sent: Wednesday, June 26, 2002 11:06 PM
To: 'Maxim Maletsky'
Subject: RE: PHP 4.2 that sucky ass update
Oh don't get me wrong. I know how to fix it. I just strongly think
that
the php dev crew blew it on this one. A lot of folks are going to get
porked on this one. One of us should do an article on it.
I know but thanks.
It's not really my isp's fault in my mind. It was a bad change to make
in a
.1 release. That's a 5.0 type of thing.
Scott
Email 4: From Maxim to Scott
-----Original Message-----
From: Maxim Maletsky [mailto:maxim@phpbeginner.com]
Sent: Wednesday, June 26, 2002 5:53 PM
Subject: RE: PHP 4.2 that sucky ass update
Scott, let me explain you why these people at PHP Dev had to do so. (I
have also protested for the first time as I heard of it).
First, there will be no 5.0 - that is what Zeev personally have told me
some year ago on a meeting. Though, I have also heard the rumors/plans
of a work starting up on the skeleton 5.0. But see, and even if PHP 5
comes up, its major changes will be the parser and loads of new and
revised modules.
PHP 4 Parser is already good and with few bugs, however no one thinks it
should not be done better, more complex and flexible. And this is the
performance issue. To change the parser (and compiler) the market should
have a stronger HW. However, that is going to happen considering that
PHP 4 was written 2 years ago. In fact, you might have heard Zend
working on the Engine 2 (marketing again?).
Another reason is Apache 2 which is still far from being called stable.
This makes it impossible for PHP to make a stable Apache 2 module since
right now Apache 2 changes dramatically, jumping between alpha and beta
releases. This will continue for at least a few more months.
In other words, PHP 5.0, if ever released, would have its own
compatibility problems.
Second problem is the security.
Too many people have complained about the security vulnerability. Soon
afterwards, the press started to look down at PHP downgrading it in the
reviews with the excuse that the most popular programming language is
also the most insecure when in hands of those who "learn it real quick".
>From e-business point of view this meant the disaster.
PHP 4.1 was releases with such fix. This in fact wasn't a fix but rather
was a forced incompatibility. It was the first time for PHP to change
the middle digit and was not usual. Magic Quotes were still default. And
here, rumors got even higher mentioning that even PHP Dev Group admitted
PHP being insecure. So, what they did was, month after 4.1.x release,
4.2 was out with MQ set to OFF by default.
I personally think this was way too quick for such major change, but I
do agree it was a must. From both - security and marketing points of
view. True, security is a transparent value, a programmer makes the
application secure, not the language... But too many newbies are out
there learning this still. Such feature, unfortunately, had to be
disabled by default. Yet, never so quickly and unexpectedly. That is how
I think.
Documentation Team also didn't do well documenting this, mentioning it
so alarming that everyone who downloads a new version knows that MOST
(not all, but most because there are also lots of Open Source apps that
rely on such feature) will get screwed up.
That is as far as I personally know and understand this whole thing. As
I said, I also got very frustrated hearing it for he first time, but if
you look deeper into the problem you will find that there were too few
better ways to make this major change.
maxim
Email 5: From Scott to Maxim
-----Original Message-----
From: J. Scott Johnson [mailto:scott@fuzzygroup.com]
Sent: Wednesday, June 26, 2002 4:44 PM
To: Maxim Maletsky [mailto:maxim@phpbeginner.com]
Subject: RE: PHP 4.2 that sucky ass update
Sorry. Don't care. It may be the right technical decision but the handling
was bloody ass poor. This is simple abuse of your developer base. I've
heard the arguments before from James Cox. Still don't care. Backwards
compatibility is important.
If you are going to make this kind of change then what you do is simple.
You RADICALLY increment the version # even if there AREN'T other features to
justify if since it makes people be aware of it. I was majorly porked by
this change and I know I'm not alone. It's crap like this that makes people say
"Whoa! What are they going to do to me next time around when they want to change
something. How much code do I have to rewrite then"
The better way to make this change was simple: Make it NOT the default. If
someone is concerned about security then THEY WILL make the effort to deal
with it. We all know that *nix, 2K, etc are all insecure out of the box.
And then you harden it as needed.
All that is going to happen from this change is the following:
Users are going to react to this change in one of two ways:
* Move backwards in version #. (My response.)
* Override this option so it works like it did before.
I've run engineering teams for 15 years. If you think that we're all going
to go back and fix all our code because so Yahoo or Group of Yahoos decides
it's in our best interest then you're dreaming.
[From Guy K. Haas: I was on the COBOL committee when they tried to get some changes into the
standard that would have allowed compilers to be delivered that would
disallow statements that had worked for 15 years because they had realized that
certain elements of the language had been categorized in the "wrong" division of the
program back then, and now should be in a different division. The THEORY
was that compilers would first report the old-style usage and alert customers
to change it. But the next release of the compilers could just honor the
new way and make the old way an error and the entire insurance industry
erupted.]
Case in point: Have you fixed every single script on www.phpbeginner.com and
at your day job? I'll buy you dinner next month in Venice if you have and
we actually get together.
Your arguments are cogent and technically valid. That doesn't mean they are
correct. According to a partial directory list of my website archive I have
1,683 PHP scripts totaling 10,629,639 bytes. Assuming 1/2 hour to review
every script that's 841.5 hours of work. At my serious development rate of
$110 per hour that's a $92,565 cost item. And I'm one little guy with not
all that much code. A technically correct argument that is not economically
viable will basically fail every time. Anyone on the PHP team look at it that way?
I will, however, blog your response since I think it's valid. Thanks for
the input.
Scott
From Maxim to Scott:
See, Scott, soon or later this had to happen. Even today, there are some
people left running PHP 3. If turning magic quotes to off now breaks 70%
of PHP apps then one year later it would still be braking 30-40%. If you
talk about a complete compatibility then this would not happen anyway,
now or tomorrow.
The whole job in this was the documentation for the change. I wish there
was more responsibility towards those who might not have the habit
reading the docs saying: "new releases are always compatible...".
Would this decision be mine, I would do everything to let users know,
expect, discuss and create their patches BEFORE change it applied
permanently. I made one reverse patch already.
See: http://www.php.net/manual/en/ref.variables.php.
That was the real problem of this change - not giving enough time to
prepare the users for it.
I fixed PHP Beginner by simply turning back Magic Quotes to ON in the
php.ini file and by adding the patch (see the link) to my global
auto_prepend file.
True, I will lose the dinner because I will not have the perfect code
for the site without having to change it. Sadly, I don't even win it by
saying that I use Apache's mod_rewrite to handle ALL the arguments -
there's still one line to edit for me.
Sincerely,
Maxim Maletsky
Founder, Chief Developer
www.PHPBeginner.com // where PHP Begins
|
|
| Copyright 2002 © The FuzzyStuff |
|
Posted In: #php