> PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks.

You can make these beginner mistakes in any language that outputs HTML to the browser, and accepts user input via the browser.

I'm not specifically defending PHP here, but I hope you're not implying that these problems don't exist in Ruby, Python, Java or even Node for that matter...

The issues you are describing are unsafe coding practices and have nothing specifically to do with how PHP works, and it's "trivially easy" to make those mistakes in almost all web programming languages.

It's also not true that PHP "can't escape the strings it injects into HTML". There are standard library functions to do this (and have been for probably 10+ years, since the late PHP 4 days), as well as many well-tested community packages to do this at the framework or application level.

Also your explanation of "plugins" and "themes" is a concept tied to applications such as Wordpress, Joomla, and other CMS products (and again are not concepts specific to PHP).

It's certainly true that PHP's low barrier to entry has led to many badly coded websites getting onto the Internet, but I think it's ignorant to claim that PHP can't be used correctly and safely to develop web applications, or that most of the problems you describe are not easily avoidable.

All languages and frameworks have their pros and cons, and their caveats, but it helps no one when people spread FUD and outdated (or straight-up false) facts about web development.

Whether you code in it or not, you should probably refresh your knowledge of the PHP language and ecosystem if you're going to make public statements about how it works and what it can and can't do.

For example PHP's PDO library makes it less convenient to supply parameters to a query the safe way than it is to do it the unsafe way. This is not necessary as can be seen from the excellent Ruby library called Sequel where it is just as easy to do things the safe way.

Another example is PHP itself being a template language, but which lack of automatic escaping makes it very dangerous to use. Since just one missing escape call in the wrong place can fuck up your day. To be fair PHP is not the only one who has fucked up here. This is also an issue with Ruby's ERB templates in the standard library, but fortunately Rails has added automatic escaping to its ERB templates.

One important thing about designing safe software is to make it easy for the end users to do things the right way, and here I think PHP has done a pretty poor job.

Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache. But you don't have to use it that way, and probably shouldn't. While PHP started as a template language, it has clearly moved past that.

Sequel's right way:

    user = db['SELECT name FROM users WHERE id = ?', id].first

    user = db["SELECT name FROM users WHERE id = #{id}"].first

    $stmt = $db->prepare('SELECT name FROM users WHERE id = ?');
    $stmt->execute([$id]);
    $user = $stmt->fecth();

    $user = $db->query("SELECT name FROM users WHERE id = $id")->fetch();

> Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache.

That is simply not true. Look at Twig which by default escapes everything automatically, or Rails's patched ERB which keeps track of escaped an unescaped strings based on data types and makes sure everything is automatically escaped in the end. In those template languages you need the explicitly do something unsafe to get an unescaped value. While in PHP you need to audit all places where echo can be called directly or indirectly.

    $user = $db->find('user', 'first_name = ?', ['Name']);

PDO isn't "optimized" to do them the wrong way or the right way. Yes, it's less code to do it the wrong way, but that isn't a true definition of easier.

As for the escaping, I would expect Twig to escape things, it's want it's meant for (and the reason you use it instead of just vanilla PHP). And Rails is a subset of Ruby correct? So not a true comparison again.

I think anyone can show anecdotes to support "coding in [language you don't like] is bad".

Replace "unsafe" with "non-performant" and go back to early Rails days and you'll have plenty of examples where naive framework implementation led to programmers shooting themselves in the foot with the "easy way" in a different context..

Like I said, all languages and frameworks have their caveats and learning to code properly is the developer's job, and the "right way" or "best way" is often a work in progress that evolves as the community develops best practices..

Completely true, but for years PHP made it extraordinarily easy to shoot yourself in the foot right out of the box. register_globals for example...

http://php.net/manual/en/security.globals.php

Just try pulling data from a database and inserting it into a page on a way that is vulnerable to XSS in Django, Jinja, or Rails. You obviously can do it, but I bet you'll need to spend half an hour reading the documentation before you succeed.

The same happens for SQL injection, and session management issues, and a huge amount of other problems.

Your argument is valid too for any PHP framework, it's hard to do XSS in laravel, symfony or zend framework.

I think tpetry was pointing out the difference between a language and a framework built on that language.

(Replace language with whatever you think it is, it's still a subset just like Ruby on Rails is a subset of Ruby)

[1]: http://php.net/manual/en/intro-whatis.php

> PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.

I would focus on the core statement of the sentence which is "is a widely-used open source general-purpose scripting language". Comparing PHP to other HTML generators (re re re? parent: Django, Jinja, Rails) leaves out the entire concept of "general-purpose scripting language" and only focuses on "embedded into HTML" which while a main feature isn't the whole of it.

Correct me if I am wrong, but so does Node, Ruby, Python, etc...

Sure it was built for the web, in simpler times, but everything has to start somewhere. Now days, PHP is a completely different beast.

> Just not a very good one.

An opinion if fine, but it seems like you are deriving this opinion from old experiences (or maybe the old PHP hate bandwagon)

I think Node is also a framework, although there seems to be some controversy about this[1]. Ruby and Python give you standard libraries from which you can build a web server or templating engine or whatever, but it would be weird to say that made them Web Frameworks. Maybe things have changed, but last I knew PHP had a command line switch that tells it to not act like a web framework, because that is its default mode of operation. But you're right that it's been a few years.

I don't think I'm jumping on a hate bandwagon, but I am succumbing to someone-is-wrong-on-the-internet syndrome, which I know to be a mistake.

Although I can't resist asking - are you saying PHP is a good web framework? How does that fit with the idea that PHP is not a web framework?

[1] https://softwareengineering.stackexchange.com/questions/2991...

I think we have different definitions of frameworks. So no point in arguing over that.

> Maybe things have changed, but last I knew PHP had a command line switch that tells it to not act like a web framework

I honestly don't even know about a command line switch. I just write my script and execute it with the CLI (php test.php)

> I am succumbing to someone-is-wrong-on-the-internet syndrome

Please tell me this has a name

> Although I can't resist asking - are you saying PHP is a good web framework? How does that fit with the idea that PHP is not a web framework?

Not sure you exact intent, but as far as PHP being a good language to write a web application in, sure, it can be. IMO, it depends on the application and use of the application.

Besides, there's more to security than SQL injections and XSS. The PHP tooling is overflowing with bad practices.

I know there are libraries for HTML escaping, but I stand behind my statement that PHP's lack of HTML escaping is a fatal and unforgivable (almost criminal) design flaw when PHP's original use case, and distinguished feature vs. other general-purpose languages is dynamic HTML templating. In my opinion, PHP has gone the "get something quick out there and fix it later to become the dominant web runtime" route (which kind of worked), but without doing the actual hard work, and as such deserves to be called out.

Trailblazers often bear the brunt of learning through trial and error, and later adopters benefit from all those lessons learned. This includes the PHP language and ecosystem of today, that looks nothing like what you describe.

Also: show me a popular web programming language that prevents the problems you called out (at the language level, not the framework level). You can output unescaped input, or create SQL injections, in any language if you don't know what you're doing, or if you're using the wrong tools.

Again if you want to keep speaking on the topic, I encourage you to refresh your knowledge on the PHP programming language (and probably also on web development in general if you think other languages don't also have the same pitfalls).

Your concerns and opinions are literally 10+ years out of date.

Golang? https://golang.org/pkg/text/template/

Where languages like Ruby had Rails and Python had Django, PHP was able to do things quickly without having a framework on top of it. That, coupled with clear design flaws and a standard library that lacked, well, standardization, made it an easy and deserving target for criticism. PHP was also slow to adopt objects, namespaces, package management and other things developers came to expect.