PHP's greatest strength is that it doesn't require OO. Seriously, for most simple web application tasks (and even some complicated ones) OO adds more confusion than it removes, and I say this as someone who certainly sees the value in OO for complex apps.
Most web apps are ultimately more like shell scripts or console applications than desktop/mobile applications. It's no coincidence that most of the former are written in C or C-like scripting languages, and most of the latter are written in OO languages running on .NET or Java. Your basic operations are "print some stuff", "read from a file or database" and various sorting, slicing and text-processing tasks inbetween, all of which are done well by PHP, Perl, C and so forth. ActiveRecord, TableDataGateway etc. are great patterns for data access, but sometimes mysql_query("SELECT foo FROM bar WHERE x = y") is just so much simpler that it becomes the better option.
The lack of OO makes PHP's documentation much more browseable, and makes code more readable in certain situations. If I look at your code and I see a function I don't know, I just google it. If I see a method invocation on an object, I need to figure out the type of the object (not easy in a dynamic language) and google the combination of class and method name, which often fails to return a result (has anyone ever managed to find anything useful in the Zend Framework docs?). PHP isn't the only data point for this argument - I think it's probably why Drupal handily beats ZF, Symfony etc. in terms of popularity, despite the superior OO architecture of the latter. You can google pretty much any API function and get an accurate result, which you just can't do with ZF (which lacks documentation at the method level, and what documentation that exists is buried in some Doxygen-based site which is made impervious to search by the use of frames). I'm also reminded of Linus's argument against OO in the Linux kernel - when you're all about the patch files, you need clear function names to understand what's going on without massive amounts of context. Drupal's rate of contributions probably exceeds that of other frameworks for similar reasons.
Of course, this bias against OO is also what makes PHP a bad choice for certain things, and this is why plenty of devs hate it. I honestly don't know if, in the final analysis, this makes PHP a good or bad choice. It probably depends too much on the problem you're trying to solve for there to be a simple answer.
I don't think you really mean "object orientation" so much as "a byzantine object hierarchy" (stereotypically associated with Java, of course). To me, Ruby's object-oriented string functions are a lot easier to keep track of than PHP's:
x.length vs strlen($x)
x.gsub('foo', 'bar') vs str_replace('foo', 'bar', $x)
x.strip vs trim($x)
x.upcase vs strtoupper($x)
All four of the PHP functions use a different form: strX, str_X, X, and strtoX. Some of this could be solved with consistent function names, like always using str_X, but then that makes me wonder why one wouldn't just want to have all string functions available as object-oriented methods on strings. Python takes a different tactic, and has a non-object-oriented len() method, but this isn't just used to get the length of a string, it will also get you the length of a list, tuple, or dictionary.
Python takes a different tactic, and has a
non-object-oriented len() method
What do you mean?
In Python len() is just a standard protocol for getting the length of something, but len() itself is calling obj.__len__() if it is defined. You can even override or replace it in an object instance, returning whatever you want.
You can argue that these protocols are a bad idea, or maybe a useless one since Ruby does just fine without such hardcoded conventions, but since it relies on runtime adhoc polymorphism, it is as object oriented as it gets.
I meant it only in the superficial sense, that the call of len() is called as len(foo), not foo.len().
I guess this is another example of why using the term "object-oriented" at all can be unhelpful, as it may mean so many different things to different people depending on the particular situation.
What's so hard about OO? Instead of string_length($string), you write $string->length. The semantics are the same. If you pass something other than a string to string_length, the results are undefined. If you call length on an object that doesn't do the length method, then you get an error.
The attraction of PHP is that it never tells you that you're writing code that doesn't work. The result is a lot of code that doesn't work. This is bad, not good.
A tricycles greatest strength is that it doesn't require balancing on two wheels.
For those who can't ride a bicycle, tricycles are great.
Once you understand how to use a framework/language like RoR, I don't see how PHP is more useful (unless you have size constraints). ActiveRecord::Base.connection.execute("SELECT foo from bar where x = y") is just as simple as mysql_query("SELECT foo FROM bar WHERE x = y"), and you get the benefit of abstracting away the database in database.yml so you can run it in different environments.
Google isn't the best place to look for object/method references. I've worked with a lot of large PHP codebases and the answer is always in the local source files or, if they're too obtuse, then on the project's documentation (if it exists and is current), in the PHP manual, or in a Google search result.
Any editor worth its salt can manipulate a cross-reference of the project's symbols. Learning how to do this has saved me days of time figuring out OO-heavy projects. I prefer ctags(1) and Vim.
Most web apps are ultimately more like shell scripts or console applications than desktop/mobile applications. It's no coincidence that most of the former are written in C or C-like scripting languages, and most of the latter are written in OO languages running on .NET or Java. Your basic operations are "print some stuff", "read from a file or database" and various sorting, slicing and text-processing tasks inbetween, all of which are done well by PHP, Perl, C and so forth. ActiveRecord, TableDataGateway etc. are great patterns for data access, but sometimes mysql_query("SELECT foo FROM bar WHERE x = y") is just so much simpler that it becomes the better option.
The lack of OO makes PHP's documentation much more browseable, and makes code more readable in certain situations. If I look at your code and I see a function I don't know, I just google it. If I see a method invocation on an object, I need to figure out the type of the object (not easy in a dynamic language) and google the combination of class and method name, which often fails to return a result (has anyone ever managed to find anything useful in the Zend Framework docs?). PHP isn't the only data point for this argument - I think it's probably why Drupal handily beats ZF, Symfony etc. in terms of popularity, despite the superior OO architecture of the latter. You can google pretty much any API function and get an accurate result, which you just can't do with ZF (which lacks documentation at the method level, and what documentation that exists is buried in some Doxygen-based site which is made impervious to search by the use of frames). I'm also reminded of Linus's argument against OO in the Linux kernel - when you're all about the patch files, you need clear function names to understand what's going on without massive amounts of context. Drupal's rate of contributions probably exceeds that of other frameworks for similar reasons.
Of course, this bias against OO is also what makes PHP a bad choice for certain things, and this is why plenty of devs hate it. I honestly don't know if, in the final analysis, this makes PHP a good or bad choice. It probably depends too much on the problem you're trying to solve for there to be a simple answer.