I recently got an email from a friend asking me to help someone being forced to learn PHP at gunpoint. It's an interesting problem, because while I normally wouldn't recommend PHP, especially not to a seasoned developer with many more appropriate tools at his or her disposal, what if you're forced to learn it?
What follows is a slightly-edited version of the original request (sent to both of us) and my somewhat tongue-in-cheek response.
Eric and Robert,
Please allow me to introduce my friend Robert. He's a good man and a solid programmer.
In the second great tragedy of today (the first being the death of Leonard Nimoy), forces of greatest evil have conspired and sentenced Robert to learn PHP. Do you have any recommendations for him as to the least agonizing way to go about this?
My friend Eric is the author of phpsadness.com. Despite his distaste for the language, he has seen success in subduing it to his will.
My first recommendation for you would be to find a way to avoid using PHP with a fury proportional to your appreciation of sane anonymous function support, language consistency, any sort of debugging capability, or documentation that matches implementation. If you don't have a great enough appreciation for these things to produce said fury, don't worry — you will very soon.
Barring the various online "resources", "tutorials", and other such options which are invariably written by people who barely understand the difference between a forward and backward slash, let alone a syntax tree, your primary choice becomes the so-called "PHP Manual" located here:
Before you try to ingest any of the data on those pages, though, please consider a few warnings.
First, always assume that the authors of the documentation are in some secret competition to who can include the largest number of subtle errors to mislead the reader. Their skill at this is truly unprecedented among documentation authors, and truly there is some special level of hell for which they vie. Because of this, I cannot more strongly recommend that you experiment and verify anything you read. Have you ever heard the ghost stories of software where the only "documentation" is the implementation? They are real, and the ghost is PHP.
Second, PHP has a longstanding tradition of never breaking backwards compatibility (as is evidenced, for example, in Sadness #30). By "never", of course, I mean "only when the maintainers feel like it"; thus, be ever vigilant about the version of PHP in which your code must run, the version of the documentation you are reading, and any changes that were made between the two. Including changes nobody thought were important enough to document.
Third, on each page of the PHP Manual, there exists a section titled "User Contributed Notes". Among my most important recommendations for you is to ignore this section entirely under every circumstance. The extent to which those sections deviate wildly from anything true or even rational is difficult to describe with even the larger of the Aleph numbers.
Given these warnings, though, it is sometimes possible to extract enough value to proceed with your task that you can at least discern the next thing to try. The closest thing you get to a REPL will be your good friend,
php -r, which you can use to evaluate simple expressions. This will let you discern the truth on at least the specific versions and configurations of PHP running on your systems.
Depending on your preferences, you might also consult a tome constructed of ink and wood pulp. While I cannot recommend any in particular, as it is my preference to learn by doing rather than reading, I am forced to assume that the authors of these texts were forced to use some subset of "verifying what they're saying is actually true" before being allowed to publish their work. Specifically, O'Reilly is known to have some above-average reading material:
(I notice, after typing this, that a book titled "Becoming a Better Programmer" appears in that page's results. I can only assume that such a book is returned from a query for "PHP" because it contains such strings as "to become a better programmer, stop using PHP and never use it again", rather than actually using PHP as part of the book's substantive content.)
Finally, for a list of pitfalls that I have personally encountered, I notice Joel has already pointed you to this excellent and entirely un-biased resource:
Treat those pages much like you'd treat a survival manual after surviving a plane crash in the deep Amazon jungle — especially the parts that tell you which bugs to not eat. Hopefully, a rescue team will find you soon.