My biggest objection to PHP is the anti-Apache2 FUD that they spread. Indeed, they seem to be the ones primarily responsible for the anti-Apache2 FUD. This is unfortunate, since there are few remaining legitimate reasons for avoiding Apache2, and it’s a shame that they feel the need to manufacture one.

So, to quote the PHP docs:

Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.

This is further clarified in the FAQ with a long description which starts, unfortunately, with a misconception, namely:

The major feature that draws people to Apache 2 is threading.

It then goes on to explain why threading is, potentially, a problem with PHP, why this is not, technically, PHP’s fault, and so PHP cant fix it. All very correct, really. And, so, very logically, it concludes that there’s no reason to move to Apache 2, and that everyone should stick with Apache 1.3.

This argument suffers from one main flaw. That is, that the initial assumption, from which everything flows, is just plain wrong.

Yes, threading is cool, and is a major shinyness with Apache 2. However, it is not, by any stretch of the imagination, the only, or even the main, reason for moving to Apache 2.0. There are a *lot* of other much better reasons for moving to Apache 2.0, none of which pose any threat to PHP. I’ve covered those in my OnLamp article, and so won’t repeat them here. Apache 2.0, running with a prefork MPM, works great with PHP, and gives you all those other benefits.

The additional benefit is a little more subtle. Apache 1.3 is becoming “legacy”. Meaning that the real developers are focusing more on 2.0. The 2.0 docs are better. 2.0 (and 2.1) gets the new features, the documentation improvements, and the newly clarified directives and error messages. Thus, 1.3 becomes harder and harder to support. So, increasingly, the PHP questions are coming from folks that are running 1.3, and the solutions offered just don’t work, because they are things added in 2.0 to solve exactly the irritations that these folks are having.

So, I entreat the PHP folks to remove this incorrect anti-Apache 2.0 tirade from their documentation, and replace it with a more balanced and correct explanation of the issues involved, and the recommended solution. Namely, that people go ahead and move to Apache 2.0, but stick with a Prefork MPM. This gives them most of the benefits of Apache 2.0, but removes the irritating threading issues. Nobody blames PHP for those threading issues (at least, people who have taken the trouble to actually understand the issue don’t), so there’s no slight on the PHP developers implied here. I’d be glad to participate in this to any degree that you like. I actually enjoy writing documentation, and I’m increasingly using PHP for my own work.

Please?

I’ve started using PHP lately, and I find that I quite like it, as a language. However, there’s a lot of anti-PHP sentiment on #apache (on freenode.net), and folks often wonder what the source of that is. Well, there’s several main reasons, some of which are:

1. The anti-Apache2 FUD spread by the PHP folks
2. The #php redirect effect
3. The “scripture with commentary” nature of the documentation
4. The misuse of AddType vs AddHandler

The first one of these, the anti-Apache2 FUD issue, is one that’s important enough that I’ll probably write as a seperate article.

The next one, the “#php redirect effect,” is pretty irritating. On #apache, we attempt to be very helpful, and so we end up answering questions on a variety of topics which are, strictly speaking, off-topic. Invariably, however, when we refer someone to #php for questions which seem to be likely to be more in the experience of folks familiar with PHP, they say, that’s an Apache problem, and send them back to #apache. This is very irritating behavior, and results in a lot of frustrated people with unanswered questions. There are indeed questions which are, strictly speaking, Apache questions. However, when they are configuration issues which would necessarily be more familiar to frequent users of PHP, it would be courteous if they were to be willing to handle those questions.

The third issue is one on which, obviously, a lot of people disagree with me. I find the PHP documentation deeply irritating. The model that they have chosen, which I call the “Scripture with commentary” approach, works kinda like this. Someone – the authority, one presumes, writes a brief piece of official documentation. Then dozens of the masses write additional commentary as addenda to that official documentation. These comments might be correct, or they might not. Who’s to know? There doesn’t seem to be any official method for resolving those comments back into the official documents. So you can’t actually know which bits are true, and which bits are uninformed ignoramuses. Then, too, there are a lot of heretical remarks, which simply criticize or complain. These are not only unhelpful, but they distract from the main flow of the truth, and so further serve to confuse the issue.

However, I should say that the PHP docs get a lot of acclaim for being wonderful, so there are obviously a lot of people that disagree with me.

Finally, there’s something that amounts to not much more than a pet peeve. The PHP docs recommend the use of AddType to enable php parsing:

AddType application/x-httpd-php .php

That’s just *wrong.* The correct way to do this would be to use AddHandler. Using AddType confuses people about what AddType means. So you should instead use:

AddHandler application/x-httpd-php .php

What’s especially irritating is that both work. But it’s still wrong.

AddType associates a Content-Type with a file extension, and that tells the browser how to deal with a particular data stream. AddHandler, on the other hand, maps a handler to a file extension.

Stated more simply, AddType tells the browser what to do with a file, and AddHandler tells the server what to do with a file. PHP is handled by the *server*, not by the browser, and so AddHandler is more appropriate.

So, you see, none of these are technical objections with PHP itself, but more deal with the community. It’s a shame when technical communities are divided by community issues, rather than technology issues. But it seems that that’s almost always the way of it.

So, once again, for the record, I’m becoming quite fond of PHP, almost in spite of myself. It makes development quick and easy. If one can get past other objections.