It’s because it makes no effort to prevent people doing insanely insecure things. Rails has a lot of safeguards for insecure things like using user input to update a record.
PHP won’t even fix bugs due to backwards compatibility. They worked out their sql string escape function didn’t escape properly but instead of fixing it and telling everyone to check their code, they duplicated the function and prefixed the name with “real_”.
PHP has supported SQL parameter binding for at least 17 years now. It's the standard way to execute SQL queries and it replaces any usage of mysql_escape() or related functions.
It seems your criticism towards PHP is the use of legacy code which is kept for backwards compatibility.
No sane person in the industry writes code like that. Those who do would have had concatenated user input to SQL queries in any language anyway be it Java, C# or whatever fancies your boat.
In my view, PHP most glaring problem is the often outdated negative image it carries outside its industry. But that's to be expected when a technology is 25 years old while striving for backwards compatibility.
I don't use PHP right now, it's not my favorite language, but I hate when people are trying to excuse their own laziness and incompetence by saying “it’s all because of tool X”.
Rails and ActiveSupport are a huge extension to Ruby and are bigger than the non Rails Ruby usage. If you read the average PHP tutorial, it starts you out connecting to a db, running raw sql and rendering templates in the same file. An absolutely horrible idea. If you start on the default rails tutorial, you gets set up with a decently safe configuration.
It's not a horrible idea, it's the simplest and easiest way to solve simple problems. Bringing in rails and all it's abstractions for something you can do in a single php (or ruby BTW) file is insane.
The easiest and simplest way is not the most secure way. Most of the beginner PHP tutorials show you something that technically works but should never ever be attempted on a real app. The problem is they do work so they get used with real users data.
> The easiest and simplest way is not the most secure way.
No, but the next simplest (using prepared statements) is. Why do you immediately jump to something so much more complicated and full of abstractions instead of the next simplest thing?
I wrote my website (where clients could hire me as a 3d artist back in 2008) I had zero experience with php. I liked the idea of using include("page.php") to insert part of a page into a "layout". I remember my friend (who was a better programmer than me at the time) telling me to not use $_GET["page"] with include, so people could not include unexpected pages via URL. I was like, yeah, that's kinda obvious. I feel the same way about sql queries.
PHP won’t even fix bugs due to backwards compatibility. They worked out their sql string escape function didn’t escape properly but instead of fixing it and telling everyone to check their code, they duplicated the function and prefixed the name with “real_”.