While RoR is getting better in this respect, PHP is vastly better documented (both officially and all throughout the web) and the community is (at least, for now) superior to RoR. This is something that simply requires more time for RoR, as PHP has had quite a few years head start to get to where it is.
In practice, it honestly boils down to what you're doing and what's easier for you (and your team). If you want to test the waters, follow a few tutorials for each that you're unfamiliar with, and see what suits you better.
If you're using a shared server, you also have to make sure that your host supports RoR (most hosts don't). So that could be an extra expense to consider.
Me personally: I'm a php person. I prefer PHP + CodeIgniter, and I'm all happy :) RoR is fine and dandy, imo, but wasn't worth 9 years of PHP experience when PHP works amazingly well for everything I've ever asked of it.
I've run server ops (and do development) for significantly loaded RoR and PHP applications (and still do), and I can say that there is more quality information available for RoR than there is PHP for setting up high scale and stable setups.
When setting up a RoR stack, all the information I needed was available, the infrastructure was pretty stable and was easy to debug problems. PHP on the other hand, had close to no information on dealing with high load. The optcache libraries are poorly documented, nobody is really talking about it, and running anything but Apache (for performance, of course) under fcgi was horrifically problematic.
In the end we had to write our own monitoring tools to deal with all the oddities we discovered with the standard fcgi spawner (there were many), and when trying to mitigate memory leaks we discover that there are 'many known leaks in the PHP stdlib, but that's OK because everyone runs short-lived processes and restarts them regularly so we don't need to fix them'. My idea of a robust (fcgi) server would be that it doesn't require constant restarts, but that's just me.
RoR is only one framework in the vast number of Ruby libraries. I have worked in both technologies and there are more well designed, useful and current libraries and tools surrounding Ruby than there are PHP.
Quite honestly I'm sick of people apologising for it and pointing to the 'big players in web' as proof that PHP is OK. In my opinion it really needs to go away. In the years I worked with it, it taught me nothing but bad habits. I'm not the only one.
EDIT: Two Ruby libraries I used recently that were very high quality were Nokogiri (HTML/XML parsing) and Typhoeus (HTTP library wrapping libcurl). I don't recall ever seeing anything like those in PHP that had such intuitive APIs. Can anyone provide any counterpoints of better libraries in PHP that don't exist in Ruby? P.S. Wordpress is not an answer.
I highly disagree that PHP has more quality information available than Ruby on Rails. Any time I've ever looked for anything on PHP all I get is ExpertsExchange quality (with the occasional gem on Stack Overflow), but a search for nearly any problem in Rails turns up a multitude of amazing blog posts, Google Groups posts, or gems that solve my exact problem. Failing that, IRC (or just digging through Ruby code which is easier to read than almost any language I have worked with) has been very helpful.
Whilst you may have an easier time finding PHP developers I actually think it is harder to find good/great PHP developers in comparison with Ruby devs. The reason for this is that Ruby/Rails development seems to focus more on TDD, CI, logic/display separation and other good practices, where as PHP, being older, hasn't traditionally had this approach. Having these practices at the core of what you do (IMO) makes you a better developer (not necessarily programmer).
It's hard to find good/great developers period and when you find them language is rarely a concern. It's easier to find PHP developers though and dispite wanting to you'll never get to staff your team with just great developers once you grow over a couple people.
Say you have a job posting and you get 100 php developers and 5 Ruby ones. Of those 5 ruby ones 3 will people people who watched the screen casts. 2 will be intermediate/senior. Of the 100 php developers 50 of them will be horrible. 40 will be junior level. 10 will be a mix of intermediate to senior.
(In my experience anyhow, my company currently uses primarily php for services and RoR for control panels so we hire for either and cross train)
> It's hard to find good/great developers period and when you find them language is rarely a concern
Totally correct, however, with Ruby I think it's easier to find them primarily as there are less Ruby devs about, and using your example above, more or them are intermediate/senior (40% for Ruby, 10% for PHP). Then again intermediate/senior != good/great.
(Disclaimer: we're a PHP shop, but know a lot of really talented Rubyists)
From my experience, a good way of weeding out the 50 horrible php programmers, is to ask about (even simple) OOP.
Then to differentiate Junior from Senior just ask them what testing tools they use (testing is not [as] ingrained in the PHP community [yet]). If they can talk intelligently about PHPUnit, mocking, etc. they are more than likely senior level, or at least passionate enough to learn more than most PHP developers.
An rdoc is only as useful as it's included use-cases. About the best thing about PHP is the fact that there are zillions of included comments on the php documentation pages. While most are not at all what should run in production, a single good comment can give you a lot of insight as to how to use some code.
Tests != actual usage.
This is actually why a readme for a gem, plugin, extension, module etc. is so important, and why I think Github has been good for the developer community at large.
This has been my experience developing with PHP for many years. Especially in the early years, I found more code in the comments on PHP documentation than anywhere else (in documentation, on blogs, on Q&A sites). That the PHP community has always had this ability for its millions of users to aggregate code for common issues in one place makes its documentation much more extensive than it may appear at first glance.