I'd argue PHP is, for any project of reasonable size, harder to get up and running than say Rails. For any serious development a PHP developer (some experience, did several years of PHP dev) will have to setup a local instance of Apache/ MySQL/ PHP and deal with making sure libraries installed on this dev server match libraries on the production server.
When it comes to deployment for both Rails (in this case) and PHP you can choose between pretty automated providers like Heroku/ PHPFog which make git deployment trivial or you have to deal with server set up and configuration.
So I'm not really sure these days that for anything except the smallest projects PHP just works any more than any other reasonably popular web language?
And what % of PHP devs alive today will ever be able to develop in modern PHP without dealing with abhorrent hacks and 4.3 code because the entire ecosystem is a giant cesspit of attempts to work on shit old shared hosting that have never been upgraded.
To clarify, I know that PHP 5.4 is getting to the point of a modern language (despite lacking the deliciousness and usefulness of modern interpreted languages like Ruby and Python), and despite that it's still a complete mess of inconsistent standard library and weird not-quite-deprecated extensions, but the attitude it has fostered, that DON'T GIVE A SHIT JUST MAKE SOME STUFF DUUURRRRR has meant that PHP is essentially the bane of everyone's existence.
Agree it's not that hard, I also don't think it's in any way a bad thing to have to learn how to do it (in fact probably a good thing). Just that learning how to do that is no easier than learning to deploy a rails/ django/ etc app so I'm not sure PHP really 'just works' any more than any other popular language.
You're comparing it to frameworks. You don't need a framework to handle URL routing, input parsing, output headers, etc. You save a PHP file and it's a URL; no routing. The query string, POST body, request headers, uploaded files, etc. are already parsed and sitting in variables in your global namespace. Output will automatically go to the web server, with the appropriate headers already set. No downloading or configuring of frameworks, no deploying. It "just works", to the point that an empty .php file with no source code at all is a working URL.
You can have a framework, you can do your own routing, input parsing, output sanitizing, and all the other things Rails/Django do. But unlike Ruby/Python, you don't need to just to get started on the web.
PHP is really a framework. It includes builtin routing, builtin request parsing, builtin templates, etc. All very tightly integrated. And it is definitely not just an interpreter or library.
And a lot of what you are listing as "just works" are misfeatures which break things and make life unnecessarily hard down the road. They are time bombs, because everything will seem OK up front and the problems won't occur to you until they are already serious and chronic.
There IS routing, it is just implicit, magical routing performed by the server by inspecting a filesystem (e.g. the same filesystem where you have code, databases, password files, configs, etc.) Exposing my internal project organization publicly as a grody looking URL scheme that will become enshrined in all my links? Oh boy!
I don't WANT everything magically parsed by default, regardless of whether I need it for this request. This must happen when and how I specify or the tool is useless to me. Also: it is not a POST body, it is a request body. What do you call the body of a PUT? (And this kind of mis-education is another PHP misfeature)
I don't WANT random mistakes like leaving empty files to pass silently. I want bad code to fail early so I can easily detect the presence of a problem, and locate it. There is nothing worse than silent failure. If you think that silencing errors "just works" then you have your head in the sand. Don't think that users don't notice when a site is broken.
You can use a builtin framework which behaves inappropriately by default and then rewrite later, but why would you actively choose to do this? I think that most people do not choose to do it, because they just don't know. That is why this topic keeps coming up.
It is nice to nurse people along, but it is not nice to require them to nurse your tool along continuously because of all its broken behavior. Their time is better spent working on their own code rather than nursing yours. So perhaps other frameworks could somehow do an even better job of nursing users along, and those specifics are worth discussing. But that doesn't mean the right answer is to hook people on PHP's builtin framework.
And by the time you dress up PHP with a third party framework and other tools to make it fit for use, which you can certainly do, it is absolutely not easier than frameworks in other languages.
Rails and Symfony were pretty much the same framework 3 years ago. Now Symfony 2 is doing things that Rails doesn't. The sheer number of programmers who use PHP versus the amount that use Ruby means that good software in PHP will evolve faster than good software in Ruby.
When it comes to deployment for both Rails (in this case) and PHP you can choose between pretty automated providers like Heroku/ PHPFog which make git deployment trivial or you have to deal with server set up and configuration.
So I'm not really sure these days that for anything except the smallest projects PHP just works any more than any other reasonably popular web language?