PHP's warts are shallow — syntactical quirks, disorganized standard library, idiotic config options.
In practice you disable stupid options, don't use quirky parts of the language, set up your IDE to autocomplete functions, and PHP stops getting in the way.
What you're left with is a decent OO language, which recently got namespaces and closures.
It's OK speed-wise (with APC) and has got stable implementation.
If you have to go learn what things are dangerous and must be shut off, and what parts of the language to avoid, surely it would be better to just use a system that doesn't have these kinds of issues?
Imagine buying a car where the salesmen was saying "this is a great car, it will get you where you want to go cheaper and faster than anything else out there. The only thing you have to remember is; 40% of the buttons, pedals and handles in the car will actually make it explode into a rolling fireball if used. Don't do that. You'll also need to open the hood and physically remove 2 or 3 things that are even more dangerous. Oh yea, don't ever put anyone or anything in the back seat. If you remember all that, this car will be a dream!". Would you use such a car? I wouldn't and I wouldn't use a language like that either.
There's php.ini-recommended in the distribution and it's well-commented.
Not using variable-variables, undeclared variables, globals, unsanitised variables in paths, SQL without prepared statements, etc. is common sense and applies to other languages too. PHP might just bite harder if you lack that common sense.
>Not using variable-variables, undeclared variables, globals, unsanitised variables in paths, SQL without prepared statements, etc. is common sense and applies to other languages too.
This is a subset of what you have to avoid in PHP. Further, things like globals can have uses. That's the difference with a really poorly designed language: there are things in there that have no good use case. Not things that are only used in rare cases, things that should never be used.
PHP will bite you, common sense or not. The language has serious misfeatures – platform-dependent integer sizes, or cgi.fix_pathinfo=1 by default allowing the interpreter to execute files without a .php extension, just off the top of my head – that require knowledge and action well above and beyond "common sense" to work around.
And all of these faults in the language, even the minor ones, just contribute to the unnecessary cognitive load of using the language. So the way I see it, if I'm starting a new project then why not just pick a sane language like Perl or Ruby or Python instead and save myself all the headaches? It's not 2004 any more, we're no longer constrained to languages that have good Apache modules, and with that constraint gone there are very few reasons to pick PHP over the competition.
How about buying a car with a standard transmission. There is a lot to learn! It actually takes both hands and both feet just to drive it. You can permanently damage the transmission by shifting carelessly. In some cases you can wear out the clutch over time merely by driving with your foot in contact with the clutch pedal. How could you guess that on your own?
Yet despite these warts standard transmissions are quite popular in most of the world, and people get around just fine in them.
But because of PHP's internal design, you can't cleanly shut off features or add new ones. You can mentally ignore the parts you don't like, but you can't fix them.
Compare this to Perl, which everyone hates, but which has a modular-enough core that you can override core behaviors. The community has recently added all sorts of new features -- a new metaobject protocol, hooks on opcodes, macros, etc. Every day, it keeps getting better.
I might agree that PHP's flaws, from a language design standpoint, are okay. Who cares what character you use to separate namespaces from class names? But the deep design without any hooks for extensibility is a killer. Every day, the language will get worse and worse, because the other languages can be extended in themselves. PHP is stuck as what it is forever. And that's the deep problem.
(Actually, I'm not willing to concede that the language design failures can be worked around. A lot of the language design quirks are boneheaded enough that they're a deal killer. I had to use PHP for two projects at two jobs. They were both my last project for those companies.)
> Compare this to Perl, which everyone hates, but which has a modular-enough core that you can override core behaviors.
Also note that mod_perl for Apache provides several really good features for efficient web applications that are missing in all other language modules (including mod_php).
You can hook on any internal apache processing step, not just the final page generation (as with mod_php, mod_rails, etc). This allows you, for example, to use Perl code instead of Rewrite Rules, and still using Apache's fast to finally deliver static content. Moreover, you could theoretically provide the whole Apache configuration via Perl code.
Although that kind of stuff may sound complicated, it allows for great flexibility and I've been told that this actually simplifies things.
PHP-powered sites accounted for a lot of vulnerabilities through the years. Part of it was due to its popularity (like VB was back in the day), but part of it could also be blamed on certain design decisions e.g. register_globals.
That true, but also consider that the especially idiotic "register_globals" has been disabled in PHP for many years. If people are still enabling that manually, it is solely because they use very outdated scripts which depend on this. Then, however, the real problem is relying on those crappy old scripts, and not the usage of PHP itself.
On the other hand, there's still other stupid stuff like "magic_quotes_gpc" that has only recently been deprecated.
For new development you should disable all legacy/noob options, enable all error reporting and use PDO with prepared statements.
If you have application that relies on register_globals or magic_quotes, you can assume it's vulnerable. PHP allows enabling these on per-directory basis, so at least you can somewhat isolate the legacy code.
In practice you disable stupid options, don't use quirky parts of the language, set up your IDE to autocomplete functions, and PHP stops getting in the way.
What you're left with is a decent OO language, which recently got namespaces and closures.
It's OK speed-wise (with APC) and has got stable implementation.