"I don’t even bother writing tests for most of the PHP I write (obviously, I would be a bit more thorough if this code were destined to be used in a more mission critical web site). Not writing tests is not the only software taboo that I break when I write PHP: I happily mix up presentation and logic all the time. That’s just how PHP is supposed to work"
And this is why everybody else hates PHP. It tempts you to write bad code, and so most people working in the language end up doing so. I have to periodically stop myself when I'm writing PHP and make sure I'm not falling into bad habits. It's possible to write good code in PHP, and I know some people who do, but the pull to write sphpghetti is too strong for most. And there is no real corresponding benefit (aside from "noobs who don't care about code quality can still write programs") arising from the design choices that cause this.
This is unfortunately true. I'm a PHP programmer (currently writing a book, A Highly Negative Book About PHP, that I've been billing as "like Essential Java but tells you what not to do") and, I like to think, a fairly good one; reading this article made me cringe because this guy is emblematic of most of the problems in the PHP community. He:
-accepts uncritically gobs of code dredged up via Google
-considers something "robust" if it doesn't break old code, when the rest of us hate it because we have to live with register_globals and other horrors
-considers "universal support" of craptastic versions of mod_php to be a good thing (some, but not all, major shared hosting messes use FastCGI)
-modifies files in production and thinks that's okay
It makes those of us who do know what we're doing and focus on disciplined code look bad, because the article author is what most people think of when talking about "PHP programmers".
The best one has to be running your site from a git repo.
I'm not sure why running old code on an old server that has support for the old code is considered a good thing about PHP. I love BASIC because I can boot up a C64 and the code I wrote 20 years ago still works today!
> The best one has to be running your site from a git repo.
What's wrong with that? `git pull` to update everything to the latest HEAD, `git co -- HEAD~1` to roll back the latest update, `git diff` to see the latest differences, etc...
This repo doesn't have to be the development repo, just a specialized non-bare repo that's used just for production. It works great for simple sites that don't require extensive deployment infrastructure.
I've not read any of the "The Good Parts" series, so I can't comment from personal experience, but I've heard that Crockford's book is the only good one in that series. He wrote it, and he wrote it well, and then O'Reilly decided to base a series about it, but didn't get authors who could write those books to the same standard.
"-considers something "robust" if it doesn't break old code, when the rest of us hate it because we have to live with register_globals and other horrors"
Agreed - as a PHP programmer (mainly in Zend Framework), who is now learning Python... I hate register_globals. With a fiery passion.
More importantly, as someone who hosts several photographer websites, I have a bone to pick with http://bludomain.com/ - congrats on your eighth birthday. Have you updated your code since you were born? It's a travesty that involves turning on almost every deprecated option in a php.ini. :\
Can you please provide me a resource to learn how to fully separate the code from the markup? I learned web development on ColdFusion then switched to PHP. I certainly understand separation of content from design (HTML to CSS) but I honestly have no idea how to do web development without mixing markup (HTML) with the actual programming.
I've done a little C and Java web stuff where my code printed HTML output - ugly. CFML and PHP mingle HTML and code together - also ugly, but better. I can't fathom any way NOT to mix them but would love to have some resources to see what I'm missing. I know there needs to be something better. Thanks.
Some of the other responses link to good resources, but I want to point out that "separating the code from the markup" is the wrong question -- instead what you want to do is separate business/application logic from display logic. It's okay to have an "if" statement or a "for" loop in your markup (in fact, it's necessary for dynamically outputting content), just make sure those things are specific to the display of the data, and not the creation or retrieval or "processing" of the data. For example, gat all of your data from the database first, put it all into a simple array or simple variables, then just loop through arrays and echo variables in the markup. MVC frameworks will have you put the data retrieval and prep steps in another file altogether, but even if you don't do this, at least shove all of that stuff up at the top of the php file and then at the bottom do all of the markup/display stuff.
The doc's fairly incomplete and requires you to actually browse through all the separate libraries that comprise the standard distro to even understand what you can use and where. It being OOP-tastic and brimming with interfaces and namespacing is great, but it is far from friendly to Symfony newbies.
Feels like you have to know Symfony 1 to understand what 2 is trying to do really. I wouldn't recommend it as a good intro to MVC.
On why you might not want to mix your markup with the templating logic (copied from a blog post I wrote a while back ):
- Designers and developers will have a hard time working on the same file, especially the designers who don’t necessarily understand the templating rules language, and can easily break the whole thing when trying to modify the file.
- Also, when provided with a new version of the template text (say, a new version of the HTML from the designers), it’ll be hard to incorporate the modifications into the original template with all the template rules scattered inside it.
Regarding how to generate dynamic markup and not mixing the markup with templating logic, I'll cite approaches like Apache Wicket  (although you still need to add a couple of attributes to the markup) and server-side jQuery like select and transform templating, such as what is done in Enlive  and Moulder  (a pet project of mine)
Of course it is impossible to do dynamic web pages without mixing code and markup, don't let anyone tell you otherwise. It's just that in PHP it is possible to one single file that is both code and markup combined, whereas other languages require a separate logic file that sends data to templates.
That is NOT a result of the language. It is trivial in any language to combine both code and markup. However people using other languages generally work to avoid that.
That said, there is a long-standing tension between keeping logic out of templates, and giving templates more flexibility. Different frameworks take different positions on how to draw the line. PHP can be seen as an extreme position towards giving templates as much power as possible.
PHP is designed to be embedded in HTML. That is why you must use the enclosing <?php ?> tags in all PHP scripts. Even when you run standalone php scripts from the the command line, you're literally embedding PHP in STDOUT.
This is very different from other languages such as ruby where templating uses the ERB module, which is a subset of the ruby language.
Frameworks have been suggested, and are a good option. A good understanding of MVC will carry you through though, and if you are only building small things then an ad-hoc MVC set up will probably get you most of the way to readable, flexible, maintainable code. One good tool for separating code and HTML is using a templating engine of some sort, I adore Smarty and normally recommend it without hesitation, but have to admit that Twig seems to have all the advantages and none of the disadvantages. I haven't used Twig yet though, so I don't know for sure!
Smarty can actually do auto-escaping. Twig was specced in the Smarty 2 era and Smarty 3 and Twig ended up solving the problem in very similar ways. My biggest gripe with Smarty is how damn unprofessional it is - backwards compatibility breaking changes on point upgrades for example, and the code and "API" (I use the term loosely) is a mess.
And this is why everybody else hates PHP. It tempts you to write bad code, and so most people working in the language end up doing so. I have to periodically stop myself when I'm writing PHP and make sure I'm not falling into bad habits.
You've got to keep in mind what PHP (currently) stands for: "PHP: Hypertext Preprocessor". Use it for that, and it's great, but try to make it do more and you run into trouble. IMO, PHP should be used in precisely those situations where nobody gives a shit if the code you write is any good or not, and by my reading, this was a valid point in the article.
The way I like to think of it, PHP is like Bash scripting for the web: an indispensable tool that's supported almost everywhere, useful for a quick and dirty (and sure, ugly) drop-in solution, but not a language you should "seriously develop" in. Once a project is complex enough that you need to think about how to organize your PHP files (esp. if it's real back-end PHP, not just HTML pages with functions) or manage dependencies and build processes, you've probably crossed a line and should be considering other solutions.
But on the other side of the coin, you shouldn't be thinking "Rails app" every time you need to add a hit counter and a "current time" display to a static web page, I don't care how much nicer code comes out in Ruby than PHP (and I love Ruby in comparison to PHP)...I'm getting the sense that many people here (nothing that you said, chc, indicates that, but many other comments on this thread seem to) would do exactly that, though, which is disturbing.
This might be an unpopular opinion, but I truly believe that once in a while hastily flung together spaghetti code is exactly what's called for in certain situations, and PHP excels at making that very easy to whip together and push out the door.
> hastily flung together spaghetti code is exactly what's called for in certain situations
And this, right here, is how you end up with some godawful clusterfuck of unmaintainable, throwaway spaghetti code that has become some poor fool's nightmare in a couple years. If it's worth writing, it's worth writing well. Otherwise, don't even fucking bother. Maybe this is what separates C from PHP. When Ritchie was creating C, do you think he had any idea it was going to be running the world's infrastructure in 20 years? Do you think he ever wanted to just hack it up real quick with some spaghetti code to get it working for his boss's current project? Sure he did, but instead he did the right thing. I can't imagine that Rasmus Lerdorf had more pressing concerns than the guys that were building the Unix operating system, and yet he decided it would be ok to take all kinds of shortcuts and hacky workarounds and poorly thought out design decisions when he was writing PHP. All of which have somehow permeated the language to such a point that you now have people actually defending bad code and critiquing the use of frameworks and admittedly "nicer" code!
> ...thinking "Rails app" every time you need to add a hit counter and a "current time" display ... I don't care how much nicer code comes out in Ruby than PHP ...I'm getting the sense that many people here ... would do exactly that... which is disturbing.
See, I don't find that disturbing at all. I find it reassuring. The two "simple" examples you give are a hit counter and current time. Sure, it's easy to write some PHP to increment a counter every time a page request is made. But what if it was hit from the same IP twice? And wouldn't you really like to know how long they stayed, and which links they clicked? Or maybe what country were they from and what page referred them? Hmm, maybe you shouldn't be writing a hit counter from scratch after all. At least displaying the time should be pretty simple. But wait, what if the user is in a different time zone? Did you account for daylight savings? What if the user wants a 12 hour clock instead of 24? Oh well, just hack something together real quick and I'm sure there will be plenty of time to fix it later on...