[arp242]

> How do you go into production? You put the file in a folder on the Web server. It works everywhere the same.

Well, not really because you have this massive php.ini file with tons of settings and whatnot, and scripts not working due to that was always a common point of failure back when I was using PHP. Also: not having some extension, which are almost always in C and require server installation (which is quite different from many other languages, where the user can usually specify most or all of their dependencies).

Maybe all of this changed? I don't know. But PHP in general has been the most fickle and unreliable environments I've dealt with. Give me any random servers, and I find it very hard to tell if my PHP script will run.

[mrtksn]

Right but all that was handled with stuff like XAMPP or some server control panel because it was all straightforward and if you don't use control panel all you had to do was to edit some .ini file.

That's of course for singe server applications. However, because everything is straightforward and built for purpose and not trying to pretend being something else, more complex systems were still easy to setup and manage.

The joy of coding PHP usually died off with frameworks like Symfony where they built complex abstractions for the pleasure of the "Enterprise" projects with many moving parts.

[arp242]

That's all fine if you're the one in control of the servers, but in reality that's not always the case. And actually even if you're in control, it's just a huge bunch of moving parts that can (and do) fail.

I also have to say that php.ini is probably one reason PHP became so successful in the first place, by having things like safe_mode and such so it could be easily used on shared hosts with ease. All the $2/month shared hosts were offering PHP, not Perl or Python, because of this (and mod_php).

But other settings like that automatic $_GET/$_POST importing ... yeah, that was a lot more misguided. Even error_reporting really should never have been a system setting: always let the code handle these sort of things. And even safe_mode is mostly outdated and useless now, because no one is doing shared hosting any more.

[mrtksn]

I think shared hosting is now called “cloud” :)

Unfortunately all cloud providers I know bank on JS. I like JS but when it is in the browser, on the server it’s a disaster.

[arp242]

Current cloud providers have very different execution environments; the typical shared webhost had one Apache process with mod_php and every account was just a different system account. What you needed as a hosting provider was a way of preventing file_get_contents("/home/someone-else/secret.txt"), which is what open_basedir gave you. And system(nefarious-stuff), which is what safe_mode gave you.

Today that sort of thing is very rare; you will run in a virtual machine or container, and have an execution environment all to yourself.

[CoolCold]

quite a lot of Wordpress setups run on sort of shared hostings to the date. Plesk and Cpanel are still a thing in this area. And Wordpress is still massive share of websites.

PHP-FPM which has options to specify system user per pool is basically how restrictions on file_get_contents are enforced.