Experiences of Using PHP in Large Websites: This is a well-written, well-researched, but ultimately damning indictment of PHP’s use in “large Web sites.”
The conclusion arrived at is that, in some circumstances at least, PHP’s tendency to create more problems than it solves makes it an inappropriate choice. However, we also recognise that there are some situations in which PHP is to be used.
I agree with a lot of what’s written here, but they’re not roadblocks that have ever really hindered me. If you abstract your code well, and you’re not working on a site with a lot of other people (I usually work alone), most of these problems are non-events.
Yes, function naming is goofy. Yes, there are no namespaces. Yes, the whole magic quotes concept is a pain. But I still write better stuff faster with PHP than with any other langauge.
They talk about templating and code separation early on, and the perfectly describe what has become my de facto templating method:
Divide every PHP page up into two parts: the former performs database queries and does whatever else is needed to calculate the content for the page, before storing the calculated content into a series of variables which — and this is crucial — contain no markup. Then the latter part of the page can simply embed variable values into HTML markup, using loops where appropriate to traverse potentially-complex data structures containing the actual content.
I actually have two files — the actual code, then a “.tpl” file that’s included at the bottom of the code. That way, two vastly different sets of code can use the same template. I know this isn’t perfect, and Joe never hesitates to tell me that I should be using Smarty instead, but it works well for me without the (1) need to learn another language syntax, and (2) the additional overhead required for template processing.
Thank to Jonathon Hollin for this link.