The Bare Essentials
First things first. Before you can do any PHP development, you'll need to set up PHP and a web server to run your scripts. As all but the simplest of sites are database-driven, you'll want to set up a database server as well. Typically, that's your AMP stack; Apache, MySQL, and PHP.
If you're on Linux, installation is about as easy as it gets. Everything you need will be provided by your package manager. Note that CentOS usually ships with fairly old versions of, well, everything. Fortunately, Rémi Collet has a great repository of newer versions availble.
OS X actually comes with PHP, Apache, and SQLite3 installed though, again, those are likely to be old versions. You can get newer versions easily enough using Homebrew. Alternately, there's MAMP which bundles Apache, PHP, and MySQL in a single installer package. It also allows for switching between various versions of PHP.
Most of you, I suspect, will be working in a Windows environment. You can get Apache, PHP, and MySQL set up as individual components under Windows, though I remember that being somewhat finicky. In a similar vein to MAMP, XAMPP is available for Windows and greatly simplifies things, allowing for installation of the whole stack (with reasonable configuration defaults) in one go. Please note that PHP mostly works under Windows. Some things -- mail comes to mind, but there are others -- either don't work at all or have different behaviour under Windows. Something to keep in mind if you're developing on Windows and deploying to Linux.
Perhaps the best option, though admittedly perhaps also the most complex, is Vagrant. Vagrant allows you to create customized, disposable virtual machines for use in development. This is ideal for a number of reasons:
- It keeps things clean and neatly separated, eliminating the need to install a bunch of server packages on your personal machine.
- It allows you to mirror your production environment very closely in development. The closer your development environment is to your production environment, the less likely 'surprises' will occur during deploy.
- You can have as many different development environments as you need without filling your computer with junk, and without having to worry about conflicting requirements across projects
Again, while I think this is a much more robust solution, it is also more involved. If you're just getting started and would rather stick with the simplicity of a single installer, that's perfectly fine.
Lastly, and this is important, now that you've got everything up and running, keep it updated! Keep an eye security updates. Keep an eye on end of life. Stay on top of things before they have a chance of blowing up in your face.
Now that you've got your server up and running, it's time to get to actually learning PHP itself. There are TONS of PHP tutorials online. And they're almost universally terrible. No, really. Many of them were written years ago, not maintained, and are full of old practices. Many of them are full of worst practices, SQL injection vulnerabilities, etc. Rule of thumb, if you see mysql_query in a tutorial, close the tab and walk away. Pretend you never saw it. You're just learning now, you don't want to have to go back and unlearn a bunch of bad habits a few months down the road. Good tutorials do exist, though. The best tutorial I am currently aware of is PHP: The Right Way. This tutorial is a living document, contributed to by dozens, and kept up to date. You'll see only the latest techniques and best practices. Many of the subjects covered will contain links to the official PHP site. This will singlehandedly be the most useful tool in your toolkit. Bookmark it, refer to it, learn how to read it and understand it.
Just about every project you work on is going to be database driven, and you're going to need to learn how to interact with it, to retrieve whatever information your application needs, and write back whatever changes your app needs to make. Indeed, a well-designed database generally needs to be in place before you start writing any code at all. SQL Zoo has an excellent series of tutorials for getting you up to speed on the SQL language. Equally worthy of note is SQL the Hard Way.
It doesn't matter if you aren't using Linux as your desktop, you will almost certainly be deploying any site you build to a Linux machine and you simply must know your way around. Linux Command has a good command line tutorial to get you started. Also, Vim. You don't need to adopt Vim as your every day editor, but the time will inevitably come that you need to make some edits on your production server and Vim is all but guaranteed to be available. It's the lingua franca of system administration and you must know at least the basics. Derek Wyatt has some great video tutorials, and there's a small tutorial for complete beginners inside Vim itself. Just open it up and type :vimtutor.
Tools of the Trade
If you're going to be spending a bunch of time writing code, you need a good editor. Syntax highlighting is a must. Code completion is pretty clutch. Linting? Must have. Anything that allows you to keep your hands on the keyboard and away from the mouse will definitely increase productivity. There are a number of choices, including the aforementioned Vim, but it's generally agreed that Sublime Text is among the best available, if not the best outright. It has syntax highlighting and code completion, of course, and support for a huge number of languages for both of those features, but it's also extensible and there are a ton of plugins available to help automate or facilitate just about any task you can come up with.
While I use Sublime Text for small projects and quick edits, I tend to prefer full-blown IDEs over simple text editors. Yes they're heavier and take longer to load, but they also offer additional functionality you simply won't find in a text editor. VCS integration, Vagrant integration, code inspection, inline documentation, all kinds of great stuff. PHP Storm is widely accepted as the best PHP IDE out there, and while I feel it's well worth the price tag, it's not free. If you spend all day every day writing code, it's a no brainer. If you're just starting off, maybe something free makes a little more sense. While NetBeans may not have all the bells and whistles of PHP Storm, it's still a solid IDE.
You're going to be working with SQL quite a lot and, while you can certainly access it through the command line, tables with a large number of columns, or with columns containing long strings don't always display very well. Sequel Pro (Mac) and Heidi SQL (Windows) are a lot nicer to work with than the MySQL CLI or phpMyAdmin.
Not optional. Seriously. Sooner or later you're going to break something and you need an easy way to recover from that. .bak files are not the way to do this. Git is probably the most commonly used version control system these days. GitHub and Bit Bucket both offer free repositories, and both have Git tutorials to help you get started. While both also offer GUI interfaces, I strongly recommend learning Git's commandline functionality as well. Bit Bucket also supports Mercurial repositories, and Joel Spolsky has a great Hg tutorial.
Composer is PHP's de facto package manager and makes handling third party libraries a breeze. In addition to hosting a huge number of libraries through Packagist, Composer also handles setting up auto-loading for all the packages you include in your project. Speaking of third party libraries, don't fall victim to Not Invented Here Syndrome. There is a ton of good code already written and readily available, meaning not only do you not need to reinvent the wheel but, especially for more complex components, you really shouldn't. A dedicated team of developers incrementally improving a project over time will always produce better code than one person writing something project-specific. When at all possible, write only the code you need.
To take the idea of only writing the code you need one step further, once you have a good grasp of PHP's basic concepts, I encourage you to look into one of the many frameworks available. Why frameworks? They provide you with a solid base upon which to build, removing the need to write the same boilerplate code over and over (user authentication, routing, database abstraction, etc) and freeing you to get to work writing application-specific code. Additionally, digging into the framework's API is both a requirement for using it to its fullest and an excellent way to learn more advanced PHP concepts and techniques.
Laravel is easily the most popular at the moment, is exceptionally well-written, and has a thriving community around it. Dayle Rees' Code Bright is an excellent primer on working with Laravel, and Jeffrey Way's Laracasts is billed as "Netflix for Developers". CakePHP was falling off the radar as its codebase was becoming dated, but version 3 is on the horizon and really helps bring Cake back into the fold of modern PHP frameworks. No list of frameworks would be complete without mentioning Symfony. Arguably the best framework available, it can be a bit of a bear to work with, especially for new users. Whether you opt to use it or not, however, Fabien Potencier is a smart, smart man and worth paying attention to. If any or all of those feel too heavy for your next project, there are also great micro frameworks like Slim and Silex that provide some of the same boilerplate while mostly staying out of your way.
Clean, legible code is important. It's important for anyone trying to figure out what's going on in your code, be that someone trying to help you sort out a problem, or yourself going back and making changes to your code six months down the line. Proper indentation matters. Proper spacing matters. More than either of those, consistency matters. Which style you ultimately adopt is of less importance than sticking with it. That said, unless you have a specific coding style you're bringing over from another language, the PHP FIG has a reasonable and well-adopted set of standards. Of particular interest are PSR-1 and PSR-2. Once you have committed to a coding standard, tools like PHP CodeSniffer will allow you to quickly detect places where you code has become inconsistent.
Invariably there will come a point when you get stuck on a problem and need a second set of eyes to help you work through it. That's what we're here for. When you do ask for help, though, please make the effort to ask a smart question. Be specific. Show your code. Tell us what you've tried, what hasn't worked, where you're getting stuck. "It doesn't work" doesn't tell us anything. 3 lines of code is probably too little for context. 1,000 is far too much.