I think link should be changed to https://w3techs.com/technologies/details/pl-php/all/all, because it points to more actual results. On that page, we can see a diagram that shows many websites has not been updated to work with latest PHP 7+, which I'd say is quite shameful and/or method used by authors of this report to check PHP version is not adequate (I guess it is now a common standard to hide version of the used interpreter in a HTTP header, while it wasn't obvious todo task when only 5.x was available). Additionally, I found it is quite wrong to putting equal mark between PHP and Hack (HHVM) in section of "Popular sites using PHP".
Yes, that's true you can find many web sites using Wordpress, or other popular CMSes like Joomla, forum boards i.e. phpBB or even e-commerce stores based on OpenCart / ZenCart / Prestashop haven't seen an update for a quite long time. Personally, I'd be glad to offer my free time to help i.e. update Wordpress (recent versions has auto-update feature) or even migrate to static-site, especially whether I am returning user of such website.
The hard part isn’t updating. It’s checking what got broken by the update, and fixing that. Then finding out one of the plugins is no longer supported, researching alternatives, and rebuilding half the site to use a new thing.
Same here. Sadly, I don't know of any static analysis tools that can detect inter-compatibility of different versions of WordPress plugins/themes/core. That's one aspect of WordPress maintenance that can get real hairy.
For example by default the Website runs in PHP 5.6 and it is up to the site owner to change the local site version to a newer version via cPanel or similar.
So non technical users that just know a bit of PHP or use some CMS, end up being stuck with the default version.
> that shows many websites has not been updated to work with latest PHP 7+, which I'd say is quite shameful
Speaking as an ex-hoster here who had to look after a fleet of shared servers running PHP (000's of sites) for 15 years, sadly life is not that simple in the trenches. The major problem with PHP is breaking changes. Even within the 5.x releases there were enough breaking changes such that upgrading from say 5.3 to 5.6 could break a site. The jump from 5.6 to 7.x has enough breaking changes to make you cry. I think there should have been a commitment to maintain 5.6 for the next ten years, if only for security fixes.
Now I'm not suggesting that developers shouldn't go back and fix stuff that breaks because the PHP folks removed/altered that functionality (with the good intentions of encouraging more secure programming, for example), but there's a labour cost and someone needs to pay for that time.
There's also functionality in PHP that shouldn't have been removed (register_globals) but should have been defaulted to disabled. Sure register_globals is insecure but what we saw were folks adding the same functionality back, just google for "php emulate register_globals".
And don't get me started about the annoyance that was removing mysql_* support. Those exact same insecure string concatenated queries are still being executed via mysqli_* and the PDO libraries. In my experience, binning mysql_* didn't make a damn bit of difference when it came to sql injection attacks.
Don't get me wrong, I admire the efforts of the PHP core team, but they made a rod for our already sore support backs whenever a new release of PHP shipped because of some fairly unnecessary BC's.
Why couldn't the mysql_ library just have added prepared queries? I've never understood this (not a PHP programmer, just someone who has had to patch a dozen sites that were suddenly broken once).
The mysqli library was likely a full rewrite in another extension. Extensions, at least that kind, at that time, didn't use/have namespaces.
Keep in mind this is a legacy code base with a function called mysql_real_escape string, like if you're at that point you're so far past gone you've lost all hope.
You missed my point. All developers did was replace their mysql_* calls with mysqli_* calls but skipped out on the parameterising step. Sure they're using a parameterised capable API, but they're not actually parameterising their queries.
In the real world dropping the mysql_* API achieved next to bugger all, we still ended up with a bunch sites with exactly the same SQL injection vulns.
mysqli_ has prepared queries, so it offers an immediate improvement.
Only if they're used. If mysqli_ required prepared statements, then it would be different. But the sins that were committed with mysql_* could still be committed with mysqli_*.
it does for old code. and many people prefer a website with bugs than a website that doesn't work at all. And any website that was vulnerable to mysql_* attacks should have already been hacked out of existence by now.
Unless something has changed since the early 2000s, `mysqli_` doesn't have a gazillion PHP/MySQL tutorials that are riddled with insecure code. That alone was a good reason to deprecate `mysql_`.
This mysql extension was deprecated six years ago. It lacked support for many important features such as transactions, stored procedures, parameterization that were either often insecurely shoehorned or simply not capable.
Read my comment above where I explain why it was a pointless move:
>Those exact same insecure string concatenated queries are still being executed via mysqli_ and the PDO libraries. In my experience, binning mysql_ didn't make a damn bit of difference when it came to sql injection attacks.
I don't care how safe you think your input validation is, concatenating strings and variables together should NEVER be done for SQL. Writing your own input validation for SQL is similar to "homebrew crypto." Even if it's mostly safe, it'll eventually bite you in the ass. You won't think of every possible attack vector. Same goes for shell, XSS, etc... In CTFs, you'd be surprised at some of the shit that you end up doing to exploit these types of vulnerabilities.
Unlike ext/mysql, ext/mysqli and PDO both support server side prepared statements. If you don't utilize this properly, your argument is moot.
The way I see it is new features, better practices, and greater security versus convenience. If the latter won, the former would need to be implemented on an ancient codebase, possibly opening up many new issues. If the former won and there's enough demand for ext/mysql, development may be continued by the community or at least shimmed on top of a proper extension or library. These decisions were being made while PHP was trying to gain traction in the "modern" web development community, making massive overall improvements leading to PHP 7+ due to pressure of Hack & HHVM, and doing a pretty damn good job with it.
Sure it sucked to convert existing code, but looking back, I'm glad I did, even if ext/mysql were still available. Luckily some of the larger, more abstracted codebases I've had to convert meant simply writing and swapping out an adapter. Most of the codebases I see nowadays still utilizing ext/mysql were clearly destined to bitrot regardless and now have far more important problems to worry about because they weren't designed to be maintained this long or they've been poorly maintained from inception. Good riddance.
You seem to have totally missed the point: mysql_* were removed in order to prevent string-concat SQL from being used, but people just end up doing the same thing with the new methods, so there was no benefit to removing them.
ext/mysql was not removed "to prevent string-concat SQL from being used." ext/mysqli and PDO allow raw SQL to be executed as well. It's just a necessary feature in some cases, but it should be reserved for static SQL.
Forming SQL by concatenating strings and variables is just bad practice and hopefully we can agree on that. ext/mysql provided no other option and this was just one of many issues with the extension.
Using ext/mysqli and PDO in a such a way (and I don't care if you're talking about retrofitting old code) is not even bad practice, it's just improper usage of the API when prepared statements should be used instead.
EDIT: Individually `print` `echo` `shell_exec` may be just as dangerous... It's up to the developer if they want to use them correctly.
I think the point is that those functions could have just been aliased to other methods from other libraries, in order to maintain compatibility for older applications while removing the deprecated underlying library.
I had this problem just yesterday. A dev decided to update their XAMPP to a version that uses PHP7.3. Took us a while to understand why he was getting notices that no one else was getting. The compact function started printing notices of undefined variables since that version, it's a small thing, but I can see breaking a lot of stuff that is not expecting it.
THIS... elebenty billion %. The breaking changes of PHP upgrades make the hosting life a nightmare. It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people.
> It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people
"Non-technical" people who don't plan for maintenance costs to their software (including maintenance to keep up with dependencies like PHP) don't get a ton of sympathy from me ¯\_(ツ)_/¯
> The jump from 5.6 to 7.x has enough breaking changes to make you cry.
It's not just PHP. But Python 2x / 3x as well.
Just to point something out: this is one reason why Java is so well liked for large enterprise code bases. They have been religious about backward compatibility in new versions.
A 2nd principle I would advocate is that if there must be a breaking change, it should be caught at compile time, not at run time. The project should fail to build, and the errors point you to exactly where the source code problems are.
Other language systems would do well to embrace backward compatibility and build time errors over run time errors. IMO.
But at least the python folks provided some tooling to bridge the gap between v2 and v3 such as backporting features from python 3. Also minor version updates generally don't break whole codebases.
Apropos Java backwards compatibility, Microsoft has been pretty good at ensuring strong backwards compatibility with .NET code. I've seen .NET 1.0 source compile and run just fine on .NET 4. Hell I've even witnessed .NET 1.0 binaries run just fine without recompilation in newer .NET environments.
Sure there's breaking differences between .NET Standard and .NET Core but they're two different products and that was made pretty apparent from the get-go.
It's not like we didn't have 10+ years of forewarning and many available ways to prepare 2.x codebases for a smooth transition. My 2.7 code passes through 2to3 with only the occasional manual fixup required because I heeded the warnings.
Java was designed upfront to be a language for large-team, long-lived, enterprise development. Whereas Python and PHP were originally toy languages that ended up filling a popular niche.
I mean, I agree with you. But Java benefits from well thought-out design constraints, ground-up IDE support, and an amazingly flexible bytecode interpreter. Normal people in the early 90s didn't have the resources to produce a language like Java.
> There's also functionality in PHP that shouldn't have been removed (register_globals) but should have been defaulted to disabled.
It was for years! They deprecated the feature. It was default disabled in php.ini. And now, as you said, if you really still need it you can code it yourself (I had to).
> And don't get me started about the annoyance that was removing mysql_* support.
I'm pretty sure that library isn't supported by MySQL server anymore (it's their library) so that's why it was removed. You can even use it to connect to newer versions of MySQL as the protocol changed.
Since the article is from 2017 php 7 was kind of newish then. I think its seen pretty rapid adoption (mainly because additional speed means fewer servers.).
PHP has adopted a strategy of rolling version upgrades with defined end points. They probably should have some "LTS (Long Term Support) type releases.
Many sites run an LTS release of a Linux distribution until support ends, and then update to either the next or the latest LTS release of that distribution, which they then stay on as long as it is support, and so on.
Debian 8 (Jessie) still has a little over a year left, for example, and is on PHP 5. Ubuntu 14 is just nearing the end of support, and is on PHP 5. Same with OpenSUSE and CentOS.
I'm not sure what the Red Hat situation is, because the pages at Redhat that Google found that would probably tell me are in the knowledge base, and will only show me the question, telling me I have to be a Red Hat subscriber to see the answer.
This is one of the annoyances with some major frameworks. According to both the Symfony and Laravel requirements pages, they need PHP 7.1.3. As far as I can tell that's not included in any LTS release of any major Linux distribution, which top out at 7.0.33 currently, I believe.
PS: interesting oddity somewhere in HN. When on the "reply" screen for your comment, HN says your comment is 1 day old. However, back in the thread, or on a direct link to your comment, it says that it is 6 hours old. It does the same thing for all 6 hour old comments in this thread, but not 5 hour old comments.
What they're measuring isn't the number of websites that use a particular technology, but the number of websites that report they're using a technology. In the case of PHP that means expose_php is set to true in the ini file, and Apache is configured so use "ServerSignature On". Those are the defaults, and they're arguably bad defaults because gathering information about a target is Hacking 101. You definitely shouldn't be giving away version numbers unless you're really good at patching stuff on day 1.
What this survey means is that PHP gives away data about your web apps internal structure. Most other web technologies don't do this. The defaults are more sane. They're not adding x-headers to every request about what versions of which technologies the server is running.
Assuming most are running WordPress, Drupal, etc, hiding the fact that you're running PHP is a bit fruitless. Those platforms are dead simple to identify by the URL paths of components, like /wp-content/whatever and other similar clues.
I do agree that exposing the version isn't a great idea.
Well, the question is why so many admins stick with PHP 5. My guess is that due to the breaking changes that came with PHP 7: https://en.wikipedia.org/wiki/PHP#PHP_7
Ubuntu 14.04 shipped with PHP 5.5 by default, and it's supported until next month. I don't know how well the maintainers backport security fixes from newer versions, but at least technically it's still supported. The last security update to php5-common on trusty came out only a few days ago.
End of upstream support is meaningless in a world where most servers run LTS distros of one flavor or another. I've been telling my clients that they should be able to rely on PHP 7.2 for a long, long time because it's the default version in Ubuntu 18.04 and RHEL/CentOS 8, both of which come with 10 years of support.
1. Bunch of up-and-forget sites on shared hosts
2. A metric ton of legacy codebases that plain don't work on PHP > 5.5
3. PHP 7 had quite a few breaking changes, like you mentioned
4. Laziness
But that's the value proposition of a distro like that. Write your app against whatever is in the repos in the .0 release and get a stable ABI until the next major release in a little over a decade.
It's really hard to classify WP as one or the other. Depending on what setup & plugins you are running it could either be essentially a static site or one that a web app for all intents and purposes.
I would describe a web-app as “any website that can’t be replaced by a Static Site Generator outputting to a public_html directory of a stock-standard Apache 1.3 installation on a locked-down server that has no CGI-bin.” (So, the SSG could output .htaccess files, and even files that contain Server Side Includes, but can’t do CGI, FCGI/WSGI, PHP, or in-server Lua like OpenResty.)
Or, a simpler definition: a webapp is any website that you can’t effectively host on your ca. 1995 ISP’s web hosting.
Many webapps where the “app” is purely in a CMS backend (e.g. most Wordpress sites) are websites. Unless they include comments, in which case they’re not. Unless those comments are JavaScript-embedded third-party (e.g. Disqus) comments, in which case they are. :)
That's an incredibly narrow definition. Why does the backend's capabilities matter? If a site has comments set up through its own backend vs through Disqus, the UX will/could be pretty much the same.
Because we're talking about the backend-deployment+ops-jargon terms "website" and "webapp", not their general usage. Words can have precise jargon meanings which are different in different disciplines. This is where ops people tend to draw the line: a website is something you can deploy to e.g. an S3 bucket and it'll be fully functional, with no other dependencies that you have to maintain for it. A webapp is something that does have such dependencies that you need to set up and maintain—e.g. a database layer.
But even ignoring that, I also define the terms this way because of the prefix "web." A webapp isn't "an app on the web", but rather "an app powered by the web." An entirely-offline JavaScript SPA that is just served over the web, isn't a web-app. It's just a program that runs in a browser, just like a Flash or ActiveX or Java applet is a program that runs in a browser. (Is a Flash game a "web game"? It's usually considered a browser game, but that's not the same thing.)
We already have a term for the thing that {Flash, ActiveX, Java} applets are: apps. Offline JavaScript SPAs are just apps too. We don't need to add the prefix "web"; it's meaningless here. In any of those cases, if you took the exact same program, and slammed it into an Electron wrapper instead of into a domain-fronted S3 bucket, it would clearly not be a "web app" in any sense. Your SPA would just be "a JavaScript app that uses a browser DOM as its graphics toolkit." Well, that's just as true before you put it in the Electron wrapper.
So "web app", then, has a specific meaning, above and beyond "app." You need something extra. That something extra is a backend, which your browser—driven by the app's logic—interacts with over the web. That's what makes an app "a web app." (This definition intentionally encompasses both server-rendered dynamic HTML, and client-rendered JavaScript SPA apps. You don't need a frontend app; you just need a web backend that something is interacting with. That something can be the browser directly, by clicking links and submitting forms; or it can be a JavaScript frontend, using AJAX.)
A "web site", then, is a "web app" without the "app" part. If it's clear in the above definition what an "app" is, and what a "web app" is, then you can subtract one from the other to derive a definition of a "web not-app." That's a website: something powered by a web backend, which does not do any app things. If we decide that "app things" are basically "storing state", then a "site" is an "app" with no persistent state.
And since the definition of "web" here is about a backend, then the difference between a "web app" and a "web site" (a web not-app) is probably defined by the properties of the backend. So the difference about the ability of the web backend to store state. So a "web site" is a "web app" where the backend does no app things—i.e., stores no state.
Why would that be a prop? It's an endorsement. Wordpress is an application built in PHP. It qualifies and is as valid as if Wordpress switched to Ruby on Rails and then Rails claimed that market share instead. Given the various improvements in PHP 7.x, including the dramatic speed improvements, it's a top-notch option for the types of applications it should be used for (Wordpress and CMS is a great use case).
No. We have a platform (https://qbix.com/blog) that needs to run on as many commodity hosts as possible, so as to form a cloud that isn’t centralized in Google and Amazon.
We are building a Wordpress-like decentralized open source alternative to Facebook and Google.
If "commodity hosts" doesn't include "ancient PHP shared hosting in Russia and India" then you are free from PHP itself and can build your platform on anything else.
> you are free from PHP itself and can build your platform on anything else
Sure, but why? Why one should discard proven,highly performant and well working solution with tons of already written and ready to use high quality frameworks and libraries? Why one should try to replace internet's "workhorse" with FOTM language/solution? Just because of hype on reddit and HN?
I know that PHP (and Java) is out of fashion right now but it's worth to be calm, ignore buzzword hype and use best solutions for problems.
If not using PHP means that people are "using a FOTM language" then I don't think we can have a productive discussion since you're expressing disrespect right from the get go.
The world isn't black and white and will never be. Don't oversimplify.
We want it to be as widely geographically distributed as possible, with as much variety as possible. We won’t even care about security of the PHP 5.2 in the traditional sense.
Truth be told, we will soon just need a bunch of open HTTP servers listening on the internet, and we will tunnel end-to-end encrypted traffic through them for signaling/matching clients by key and perhaps TURN relays. We already have 40,000 installed users and growing, our apps that run on people’s home computers will be able to make sure that stuff is secure and validated and enforce consensus with MINIMAL CPU power. We made the mistake of doing proof of work mining in the past and quickly removed it:
PHP has it's flaws but it has it's strengths too. For low traffic sites or more content heavy sites that are going to be heavily statically cached anyway...it's REALLY hard to find cheaper hosting.
PHP scales down better than just about any other language out there since most of the rest of them have to boot up.
It seems like for that kind of site what you're really looking for is completely static content behind a CDN. Your average blog or corporate homepage doesn't need to be dynamic at page-load time. You can generate the pages with a template engine when you update them, and then serve up the static content.
If you want to power some little dynamic things like blog comments you can run a custom microservice in a less awful programming language, or go with some hosted cloud option like AWS AppSync or Aurora Serverless.
So one should increase their reliance on third party services, potentially having their small site requiring two or three external services (potentially at different providers) instead of just having it all in one package (in PHP or anything else)?
So one should dynamically generate the page's markup for every single page view? With the attack surface that comes with exposing your PHP site to the public internet? Are you going to conscientiously check for security updates on your server? Are you going to trust whatever CMS you're using to win the whack-a-mole game of patching vulns (and god help you if it's Wordpress)? Are you going to stand up and maintain your own database server? Can you scale up capacity if you need it? Have you thought about backups?
The "all in one package" solution is a lot more complex than you make it sound. I would argue that much of the 80% of the web powered by PHP would be well-advised to utilize cloud services.
The point of me copying the structure of your comment with my own is to point out that your line of argument ("look at how complex this seems on its face") applies just as well to your own position as it does mine. When you say "yes" you're just repeating the same argument that I used to refute yours. I don't get it.
PHP 7: didn't use it too much yet but things definitely have been improving on the syntax side! But doing PHP is 80% awful jobs and 20% cool companies so it's not something I would put too high up on my resumé.
This is slightly off topic. But PHP has a great devloper experience, in general, now with vscode, and autocomplate, find all references, etc. But the best framework out there is Laravel. It's great, but the maintainer doesn't seem reliable. Every single release has some type of backwards incompaitible change to it of which they don't document all the changes. So it's basically a blackbox if you are to upgrade your laravel/framework version.
Ok. I agree vert.x and quarkus.io really look promising! I was using the play framework which looked similar at first glance and then was horrible as java was just at the surface and one needed to use scala in the end. Learning scala with a java team under time preasure was not a good experience...
I did Play v2 with Scala... I can agree, it was not pleasant. (I had just gotten off a year-long Ruby on Rails/ JRuby on JVM stint though - so "pleasant" is a relative term)
How come it has a best developer experience? Even setting up xdebug and starting debugging is a pain. Most of the developers codes in php use `echo` for a long time.
PS: I haven't used php for 2 years, let me know if there is an update on debugging.
Yes I totally agree that setting up or rather understanding how the debugging cylcle works with php is not straight forward. It doesn't work out of the box and one has to dig into php internas. However, it pays off, as one can do remote debugging on e.g. a docker development machine or similar...
I am not sure how well such a feature is supported in javascript, ruby, java or what not out of the box...
I've heard this criticism of Laravel a couple times and never understood it. I've been using the framework for years and have never had an issue with upgrades. There is a clear and comprehensive upgrade guide with each release, as well as a third-party package called Laravel Shift that can inspect your code and perform automatic upgrades in many cases. I've found there are only one or two breaking changes per minor version release (which seems reasonable to me), and they are always well-documented.
Aside from that, I'm glad you've highlighted Laravel, which—despite being the most popular server-side Web framework on GitHub—gets virtually no attention from HN. It's typical to use Laravel in the old server-side rendered Rails paradigm (which is still probably best for some applications), but I've had success using it to develop APIs as well. Core features like the ORM, job queues, dependency injection, email templating, etc, are very solid, and the ecosystem of packages around it is phenomenal. I would recommend it to any Web developer.
Laravel also as a lightweight version called Lumen for simpler APIs and things. It includes a lot of the features of core Laravel but has a more stripped-down application structure.
PHP is not that bad. I used Laravel to build out a PHP based web-app , it was a breeze to build - great developer experience - Eg: Netbeans/Eclipse Syntax editors are easy to use, composer was as easy as rails was. Most of my work was on the JS part though (React/WebVR). Tests, Code Coverage, Deployment to AWS, everything was smooth . This coming from a polyglot dev who built apps with Scala,Python, Java and Ruby
I've used PHP (pre 7) at $JOB. It's not bad for hacking a project together. In fact, it's kind of ideal. (Though I would personally pick Python.)
It is bad when working on a business-grade product with more than a dozen engineers. Bizarre language choices and an intrinsic tendency towards non-encapsulation seems to make even more spaghetti code than you'd find in Ruby, Python, Java, etc.
> even more spaghetti code than you'd find in Ruby, Python, Java, etc.
From working on numerous large Java projects, I can say with real-world experience that the logical equivalent to spaghetti code is very common with Java. The difference is where the spaghetti is -- in Java, it tends to be spaghetti inheritance and encapsulation.
Nice to see more of those "real world" words that confirms that everybody can do clusterfucks (aka spaghetti code) in any language, given the proper time and lazyness ;P
PHP is a great because it lets you get stuff done. Easy to understand, deploy and extend. Also, with the new reactive frameworks such as swoole, it can even support situations where you need to service a very high number of connections. We use it extensively at my firm and are proud to do so. A lot of PHP criticism comes from developer snootiness and a fairly hefty survivorship bias. PHP is good for a bunch of things - let's just be okay with that!
Other programming languages "let you get stuff done" without all of the ugly warts and rough edges of PHP. And the only survivorship bias involved is that only developers with a high tolerance for terrible programming languages stick with PHP so the community disappears into its own navel in an endless cycle of awfulness. Calling this developer snootiness is like building houses with stone hand tools and scoffing at the workers who won't join your construction company until you buy some hammers.
Not really. PHP is not awful. It powers much of the web because it's actually good at its job. What's your programming language of choice? I bet you will find ample, justified criticism of it too.
i've taken to writing some console-oriented tools in PHP for projects (and sometimes just my own stuff). It hit me years ago that it was pretty easy to do stuff like db connections, decent filehandling, etc as one-off scripting vs bash. Sure, perl/ruby/python are there, but if you're already using PHP for a main project, extending cli stuff out in to PHP as well is handy (handier than bash, by comparison).
PHP can scale up or down, but some tools are harder to 'scale down' - by that I mean be able to be used for short one-off things (cli tools, etc). I'm not saying it can't be done, but people don't often write smaller supporting tools (quick text preprocessing before an import, for example) in Java, even when their main projects are in Java. Of course, IME, and YMMV.
I use PHP everyday and it rocks for what it does when you use it with best practices. The real problem is with small companies who won’t or don’t upgrade their infrastructure on a regular basis.
Heck, even with Wordpress these days you could use it as an API source and build a modern SPA website. It’s just getting over the inertia of intransigent stakeholders.
I guess it's like how people trashed COBOL and Fortran when I was getting into development. Then later in life, I come to find out that Fortran is ubiquitous in engineering and is actually amazing for what it does.
I prefer PHP but as glue. Like my first-grade teacher taught us, a drop of glue goes a long way. Too much glue makes a mess.
Unlike many programmers, I don't pick one of the Turing-complete programming languages (PHP, Python, Ruby, Go, whatever) and try to write as much of my app as possible in it. Because they are Turing complete, you really can write everything in it. Because you can learn only so much, you are tempted to write more than you should in that language.
But like I said, PHP is just a part of my stack, and I try my best to make it one of the thinnest layers. The other parts are Postgres, Apache, and the user's browser. I try to use each of those as much as possible. The server operating system also plays a part, and I suppose my stack includes Bash.
Basically I try to do as much business logic as possible in Postgres. This leaves PHP to do little more than glue the output of Postgres to HTML templates.
132 comments
[ 4.0 ms ] story [ 202 ms ] threadEdit: Fixed some language errors and typos.
Of those PHP websites, most of them are probably wordpress. How many of those haven't been updated in ages?
That's way more dangerous than running PHP 5, taking into account all distros will backport security fixes for years to come.
Do you expect all node small and medium completed projects run on latest node?
For example by default the Website runs in PHP 5.6 and it is up to the site owner to change the local site version to a newer version via cPanel or similar.
So non technical users that just know a bit of PHP or use some CMS, end up being stuck with the default version.
Speaking as an ex-hoster here who had to look after a fleet of shared servers running PHP (000's of sites) for 15 years, sadly life is not that simple in the trenches. The major problem with PHP is breaking changes. Even within the 5.x releases there were enough breaking changes such that upgrading from say 5.3 to 5.6 could break a site. The jump from 5.6 to 7.x has enough breaking changes to make you cry. I think there should have been a commitment to maintain 5.6 for the next ten years, if only for security fixes.
Now I'm not suggesting that developers shouldn't go back and fix stuff that breaks because the PHP folks removed/altered that functionality (with the good intentions of encouraging more secure programming, for example), but there's a labour cost and someone needs to pay for that time.
There's also functionality in PHP that shouldn't have been removed (register_globals) but should have been defaulted to disabled. Sure register_globals is insecure but what we saw were folks adding the same functionality back, just google for "php emulate register_globals".
And don't get me started about the annoyance that was removing mysql_* support. Those exact same insecure string concatenated queries are still being executed via mysqli_* and the PDO libraries. In my experience, binning mysql_* didn't make a damn bit of difference when it came to sql injection attacks.
Don't get me wrong, I admire the efforts of the PHP core team, but they made a rod for our already sore support backs whenever a new release of PHP shipped because of some fairly unnecessary BC's.
mysqli_ has prepared queries, so it offers an immediate improvement.
The mysqli library was likely a full rewrite in another extension. Extensions, at least that kind, at that time, didn't use/have namespaces.
Keep in mind this is a legacy code base with a function called mysql_real_escape string, like if you're at that point you're so far past gone you've lost all hope.
for a 25 year library, thats not at all too bad. And even PHP developers admit that the lib was "not broken"
In the real world dropping the mysql_* API achieved next to bugger all, we still ended up with a bunch sites with exactly the same SQL injection vulns.
They did? All of them? Nobody moved to paramaterized queries?
1) this is not an argument for leaving an inferior library in the language
2) plenty of people do update their software, for old code and large projects. Why not push people toward the better library?
Only if they're used. If mysqli_ required prepared statements, then it would be different. But the sins that were committed with mysql_* could still be committed with mysqli_*.
The point wasn't "this fixed the injection problem" it was that it provided a solution not available for mysql_
it does for old code. and many people prefer a website with bugs than a website that doesn't work at all. And any website that was vulnerable to mysql_* attacks should have already been hacked out of existence by now.
http://php.net/manual/en/mysqlinfo.api.choosing.php
>Those exact same insecure string concatenated queries are still being executed via mysqli_ and the PDO libraries. In my experience, binning mysql_ didn't make a damn bit of difference when it came to sql injection attacks.
Unlike ext/mysql, ext/mysqli and PDO both support server side prepared statements. If you don't utilize this properly, your argument is moot.
Official discussion points here: https://wiki.php.net/rfc/mysql_deprecation#why
The way I see it is new features, better practices, and greater security versus convenience. If the latter won, the former would need to be implemented on an ancient codebase, possibly opening up many new issues. If the former won and there's enough demand for ext/mysql, development may be continued by the community or at least shimmed on top of a proper extension or library. These decisions were being made while PHP was trying to gain traction in the "modern" web development community, making massive overall improvements leading to PHP 7+ due to pressure of Hack & HHVM, and doing a pretty damn good job with it.
Sure it sucked to convert existing code, but looking back, I'm glad I did, even if ext/mysql were still available. Luckily some of the larger, more abstracted codebases I've had to convert meant simply writing and swapping out an adapter. Most of the codebases I see nowadays still utilizing ext/mysql were clearly destined to bitrot regardless and now have far more important problems to worry about because they weren't designed to be maintained this long or they've been poorly maintained from inception. Good riddance.
Forming SQL by concatenating strings and variables is just bad practice and hopefully we can agree on that. ext/mysql provided no other option and this was just one of many issues with the extension.
Using ext/mysqli and PDO in a such a way (and I don't care if you're talking about retrofitting old code) is not even bad practice, it's just improper usage of the API when prepared statements should be used instead.
EDIT: Individually `print` `echo` `shell_exec` may be just as dangerous... It's up to the developer if they want to use them correctly.
and you don't have to install ext/mysql, they could just remove it from default configuration
"Non-technical" people who don't plan for maintenance costs to their software (including maintenance to keep up with dependencies like PHP) don't get a ton of sympathy from me ¯\_(ツ)_/¯
It's not just PHP. But Python 2x / 3x as well.
Just to point something out: this is one reason why Java is so well liked for large enterprise code bases. They have been religious about backward compatibility in new versions.
A 2nd principle I would advocate is that if there must be a breaking change, it should be caught at compile time, not at run time. The project should fail to build, and the errors point you to exactly where the source code problems are.
Other language systems would do well to embrace backward compatibility and build time errors over run time errors. IMO.
That was one of the lowest effort upgrades I ever did for my company (backend services, no front end websites).
One of the other reasons Java is popular in big companies is the low effort it requires to find people who can work with it.
If your application does a lot of ASCII/unicode/raw string and byte manipulation, the transition from Python 2 to 3 can be very cumbersome.
But at least the python folks provided some tooling to bridge the gap between v2 and v3 such as backporting features from python 3. Also minor version updates generally don't break whole codebases.
Apropos Java backwards compatibility, Microsoft has been pretty good at ensuring strong backwards compatibility with .NET code. I've seen .NET 1.0 source compile and run just fine on .NET 4. Hell I've even witnessed .NET 1.0 binaries run just fine without recompilation in newer .NET environments.
Sure there's breaking differences between .NET Standard and .NET Core but they're two different products and that was made pretty apparent from the get-go.
I mean, I agree with you. But Java benefits from well thought-out design constraints, ground-up IDE support, and an amazingly flexible bytecode interpreter. Normal people in the early 90s didn't have the resources to produce a language like Java.
It was for years! They deprecated the feature. It was default disabled in php.ini. And now, as you said, if you really still need it you can code it yourself (I had to).
> And don't get me started about the annoyance that was removing mysql_* support.
I'm pretty sure that library isn't supported by MySQL server anymore (it's their library) so that's why it was removed. You can even use it to connect to newer versions of MySQL as the protocol changed.
PHP has adopted a strategy of rolling version upgrades with defined end points. They probably should have some "LTS (Long Term Support) type releases.
http://php.net/supported-versions.php
5.6 just reached eol. I think they've put out a securtiy patch since then so its (not quite) completely abandoned.
If people aren't forced to upgrade their sites, they won't. So there is huge incentive to just keep running the older versions.
Debian 8 (Jessie) still has a little over a year left, for example, and is on PHP 5. Ubuntu 14 is just nearing the end of support, and is on PHP 5. Same with OpenSUSE and CentOS.
I'm not sure what the Red Hat situation is, because the pages at Redhat that Google found that would probably tell me are in the knowledge base, and will only show me the question, telling me I have to be a Red Hat subscriber to see the answer.
This is one of the annoyances with some major frameworks. According to both the Symfony and Laravel requirements pages, they need PHP 7.1.3. As far as I can tell that's not included in any LTS release of any major Linux distribution, which top out at 7.0.33 currently, I believe.
PS: interesting oddity somewhere in HN. When on the "reply" screen for your comment, HN says your comment is 1 day old. However, back in the thread, or on a direct link to your comment, it says that it is 6 hours old. It does the same thing for all 6 hour old comments in this thread, but not 5 hour old comments.
Oh you cant run lib/framework/tool due to host deps? No problem, I will just replace you with a script.
What they're measuring isn't the number of websites that use a particular technology, but the number of websites that report they're using a technology. In the case of PHP that means expose_php is set to true in the ini file, and Apache is configured so use "ServerSignature On". Those are the defaults, and they're arguably bad defaults because gathering information about a target is Hacking 101. You definitely shouldn't be giving away version numbers unless you're really good at patching stuff on day 1.
What this survey means is that PHP gives away data about your web apps internal structure. Most other web technologies don't do this. The defaults are more sane. They're not adding x-headers to every request about what versions of which technologies the server is running.
If you dig a bit you'll see this line in the source data: "PHP is used by 79% of all the websites whose server-side programming language we know." (https://w3techs.com/technologies/overview/programming_langua... under "How to read this diagram")
tl;dr PHP server admin need to get better at security.
I do agree that exposing the version isn't a great idea.
Handy reference from the Wappalyzer browser extension for you.
Well PHP 5.6 is unsupported aswell, but it was supported till december 2018..
[1]http://php.net/archive/2019.php#id2019-01-10-4
End of upstream support is meaningless in a world where most servers run LTS distros of one flavor or another. I've been telling my clients that they should be able to rely on PHP 7.2 for a long, long time because it's the default version in Ubuntu 18.04 and RHEL/CentOS 8, both of which come with 10 years of support.
Also php7 breaks most old projects
they have tons of other metrics. To summarize PHP and Wordpress absolutely dominate the web.
Website: main focus is information serving, documents, designs, texts, assets, etc.
Webapp: users can create some kind of output from the service that's based on creative input.
The line is still blurry, but more narrow and contrasted.
Or, a simpler definition: a webapp is any website that you can’t effectively host on your ca. 1995 ISP’s web hosting.
Many webapps where the “app” is purely in a CMS backend (e.g. most Wordpress sites) are websites. Unless they include comments, in which case they’re not. Unless those comments are JavaScript-embedded third-party (e.g. Disqus) comments, in which case they are. :)
But even ignoring that, I also define the terms this way because of the prefix "web." A webapp isn't "an app on the web", but rather "an app powered by the web." An entirely-offline JavaScript SPA that is just served over the web, isn't a web-app. It's just a program that runs in a browser, just like a Flash or ActiveX or Java applet is a program that runs in a browser. (Is a Flash game a "web game"? It's usually considered a browser game, but that's not the same thing.)
We already have a term for the thing that {Flash, ActiveX, Java} applets are: apps. Offline JavaScript SPAs are just apps too. We don't need to add the prefix "web"; it's meaningless here. In any of those cases, if you took the exact same program, and slammed it into an Electron wrapper instead of into a domain-fronted S3 bucket, it would clearly not be a "web app" in any sense. Your SPA would just be "a JavaScript app that uses a browser DOM as its graphics toolkit." Well, that's just as true before you put it in the Electron wrapper.
So "web app", then, has a specific meaning, above and beyond "app." You need something extra. That something extra is a backend, which your browser—driven by the app's logic—interacts with over the web. That's what makes an app "a web app." (This definition intentionally encompasses both server-rendered dynamic HTML, and client-rendered JavaScript SPA apps. You don't need a frontend app; you just need a web backend that something is interacting with. That something can be the browser directly, by clicking links and submitting forms; or it can be a JavaScript frontend, using AJAX.)
A "web site", then, is a "web app" without the "app" part. If it's clear in the above definition what an "app" is, and what a "web app" is, then you can subtract one from the other to derive a definition of a "web not-app." That's a website: something powered by a web backend, which does not do any app things. If we decide that "app things" are basically "storing state", then a "site" is an "app" with no persistent state.
And since the definition of "web" here is about a backend, then the difference between a "web app" and a "web site" (a web not-app) is probably defined by the properties of the backend. So the difference about the ability of the web backend to store state. So a "web site" is a "web app" where the backend does no app things—i.e., stores no state.
[1] https://venturebeat.com/2015/11/08/wordpress-now-powers-25-o...
https://wordpress.org/news/2019/03/one-third-of-the-web/
That's the entire web. It is staggering.
This is why.
We are building a Wordpress-like decentralized open source alternative to Facebook and Google.
Sure, but why? Why one should discard proven,highly performant and well working solution with tons of already written and ready to use high quality frameworks and libraries? Why one should try to replace internet's "workhorse" with FOTM language/solution? Just because of hype on reddit and HN?
I know that PHP (and Java) is out of fashion right now but it's worth to be calm, ignore buzzword hype and use best solutions for problems.
The world isn't black and white and will never be. Don't oversimplify.
Truth be told, we will soon just need a bunch of open HTTP servers listening on the internet, and we will tunnel end-to-end encrypted traffic through them for signaling/matching clients by key and perhaps TURN relays. We already have 40,000 installed users and growing, our apps that run on people’s home computers will be able to make sure that stuff is secure and validated and enforce consensus with MINIMAL CPU power. We made the mistake of doing proof of work mining in the past and quickly removed it:
https://www.google.com/search?q=qbix+mining&ie=UTF-8&oe=UTF-...
I think DNS is eventually going to go the way of the dodo, and we will have this:
https://qbix.com/blog/2018/08/28/vision-for-a-new-truly-dece...
PHP scales down better than just about any other language out there since most of the rest of them have to boot up.
If you want to power some little dynamic things like blog comments you can run a custom microservice in a less awful programming language, or go with some hosted cloud option like AWS AppSync or Aurora Serverless.
The "all in one package" solution is a lot more complex than you make it sound. I would argue that much of the 80% of the web powered by PHP would be well-advised to utilize cloud services.
yes.
Which are the "right extensions" because what I saw was not "fun" at all.
PS: I haven't used php for 2 years, let me know if there is an update on debugging.
I am not sure how well such a feature is supported in javascript, ruby, java or what not out of the box...
Aside from that, I'm glad you've highlighted Laravel, which—despite being the most popular server-side Web framework on GitHub—gets virtually no attention from HN. It's typical to use Laravel in the old server-side rendered Rails paradigm (which is still probably best for some applications), but I've had success using it to develop APIs as well. Core features like the ORM, job queues, dependency injection, email templating, etc, are very solid, and the ecosystem of packages around it is phenomenal. I would recommend it to any Web developer.
Everyone may commence the throwing of tomatoes now.
It is bad when working on a business-grade product with more than a dozen engineers. Bizarre language choices and an intrinsic tendency towards non-encapsulation seems to make even more spaghetti code than you'd find in Ruby, Python, Java, etc.
From working on numerous large Java projects, I can say with real-world experience that the logical equivalent to spaghetti code is very common with Java. The difference is where the spaghetti is -- in Java, it tends to be spaghetti inheritance and encapsulation.
PHP can scale up or down, but some tools are harder to 'scale down' - by that I mean be able to be used for short one-off things (cli tools, etc). I'm not saying it can't be done, but people don't often write smaller supporting tools (quick text preprocessing before an import, for example) in Java, even when their main projects are in Java. Of course, IME, and YMMV.
Heck, even with Wordpress these days you could use it as an API source and build a modern SPA website. It’s just getting over the inertia of intransigent stakeholders.
It's currently taking #4 place in the famous framework benchmark:
https://www.techempower.com/benchmarks/
I guess it's like how people trashed COBOL and Fortran when I was getting into development. Then later in life, I come to find out that Fortran is ubiquitous in engineering and is actually amazing for what it does.
Unlike many programmers, I don't pick one of the Turing-complete programming languages (PHP, Python, Ruby, Go, whatever) and try to write as much of my app as possible in it. Because they are Turing complete, you really can write everything in it. Because you can learn only so much, you are tempted to write more than you should in that language.
But like I said, PHP is just a part of my stack, and I try my best to make it one of the thinnest layers. The other parts are Postgres, Apache, and the user's browser. I try to use each of those as much as possible. The server operating system also plays a part, and I suppose my stack includes Bash.
Basically I try to do as much business logic as possible in Postgres. This leaves PHP to do little more than glue the output of Postgres to HTML templates.
Because we all abuse it, and is damn easy to make it work.
But at the end, we all feel dirty for using php.