The PHP 4.2 Issues In Detail
Last updated: 6/26/2002; 10:05:43 PM
The FuzzyBlog!

Marketing 101. Consulting 101. PHP Consulting. Random geeky stuff. I Blog Therefore I Am.

The PHP 4.2 Issues In Detail


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, 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 []

> 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:

> Site:

> Blog:

> Yahoo IM: fuzzygroup

> AOL IM: fuzzygroup

> Emergency:

> * * * * * * * * * * * * * * * * * * * * * * * * * *


Email 2: From Maxim to Scott

-----Original Message-----

From: Maxim Maletsky []

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 - 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...



Maxim Maletsky

Founder, Chief Developer // where PHP Begins

Email 3: From  Scott to Maxim

-----Original Message-----

From: J. Scott Johnson []

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


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.


Email 4: From Maxim to Scott

-----Original Message-----

From: Maxim Maletsky []

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.



Email 5: From Scott to Maxim

-----Original Message-----

From: J. Scott Johnson []

Sent: Wednesday, June 26, 2002 4:44 PM

To: Maxim Maletsky []


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


Case in point: Have you fixed every single script on 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.


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.


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.




Maxim Maletsky

Founder, Chief Developer // where PHP Begins


Copyright 2002 © The FuzzyStuff