News for hackers. Stuff that matters.
Re:A look at modern PHP by onli on Tuesday May 05, 2020 @04:46AM (#23077871)
> But with fewer people self-hosting these days, that has become less an advantage.

I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past.

> And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.

Did they? How?

With PHP, all the users has to do is to fetch the project files and upload them with FTP to the directory the hoster told them to. No other environment matches that - and no other environment is supported by those hosters. If you want to run something else - like Ruby, which I prefer to use, or something that creates a binary for you - you are looking at a completely different type of hosting. Digitalocean, Heroku - and that's not as easy, if the application is not provided as a one-click-install.

Re:A look at modern PHP by guggle on Tuesday May 05, 2020 @05:51AM (#23078238)
> With PHP, all the users has to do is to fetch the project files and upload them with FTP to the directory the hoster told them to

Let's not idealize things. For moderately complex apps, even back in the days, this falls pretty fast: missing PHP modules in default distro installation, PECL/Pear extensions, hosters messing with the php.ini in bad ways, etc. And now the dependency management and deployement systems pushing you to access a shell on your server...

Re:A look at modern PHP by onli on Tuesday May 05, 2020 @07:11AM (#23078726)
The only issue of that I still encounter is hosters misconfiguring the php.ini, rarely.

There is no shell accessible on these servers, it's on the project to include all dependencies. Composer in this world is strictly not for users, but only for developers. That's a good thing.

Re:A look at modern PHP by guggle on Tuesday May 05, 2020 @09:12AM (#23079634)
Oh how I hated the fact that php.ini could change so much of the PHP behaviour... can't say I miss those days.

Also, I don't know about now because I left this ecosystem long ago, but it was very common for apps to bundle their own custom installer scripts (access a webpage, fill a form and so on). Certainly useful for the users but it was never standard and required a lot of work for the developers (and came with their own requirements and bugs).

But I like some of the recent additions to the language. At least the PHP Team keeps up with the competition.

Re:A look at modern PHP by Ayesh on Wednesday May 06, 2020 @01:49AM (#23088228)
This is changing now. There are no new php.ini changes that would affect how the parser or VM works. The lessons from things like safe_mode and register_globals are learned so well.
Re:A look at modern PHP by guggle on Wednesday May 06, 2020 @06:54PM (#23097380)
and magic_quotes...
Re:A look at modern PHP by creshal on Tuesday May 05, 2020 @05:21AM (#23078070)
> I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past.

From my experience, the share of people who can only deploy PHP is steadily shrinking. PHP remains the default, and popular, but easily deploying other languages is becoming more feasible, and we're shipping docker containers with Python/Go/Node/whatever code a lot more often these days.

Re:A look at modern PHP by Okawari on Tuesday May 05, 2020 @05:10AM (#23078018)
I'll concede that PHP focused hosting solutions such as your traditional shared webpage hosting environment is better at hosting PHP than any other language, and sure there are less services out there that lets you deploy code "as easy as PHP".

I had to check and I'm paying about 4$ a month for a traditional PHP server host vs 5$ for a VPS which I can run whatever I want on. And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell. Then only thing that makes this harder is having to kill the server and restart on deployment. I dont find that to be that much harder.

Re:A look at modern PHP by onli on Tuesday May 05, 2020 @05:35AM (#23078141)
It's not really a question of money, the VPS where you can do what you want can even be cheaper.

> And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell.

I mean, it's not like I'm not doing that for myself. Even my PHP blog is not with a traditional hoster. But there are many things that can go wrong there - for the ruby example starting with the ruby versions, additional system dependencies. And then you need something to make the app restart after a reboot (supervisor is thankfully excellent), and probably a nginx in front of the webapp, and letsencrypt, and does your VPS take care of backups? Each task not impossible, but in total vastly more complex. Some users can handle that, many don't.

I just did some freelance work on a wordpress site (and I'm involved with a different PHP blog engine, serendipity), and it's so nice when the setup that those PHP projects present you with is clear and straightforward, and on top of that everything that might be complicated even a mediocre hoster had years to solve now.

Re:A look at modern PHP by innocenat on Tuesday May 05, 2020 @04:12PM (#23084427)
Unless you are running continuous load, the $4 PHP shared hoster is probably more powerful than $5 VPS.

I know some shared PHP host that cost $8/year and have larger memory_limit than the available RAM in $5 VPS.

Re:A look at modern PHP by Ayesh on Wednesday May 06, 2020 @01:55AM (#23088251)
memory_limit is the upper bound you "allow" PHP to allocate. You can allocate more than the available RAM, and have your OS swap or PHP crash.

Pretty much every shared host I had to work with (I've been freelancing for a few years), have been terrible, except for two platforms, both of them were expensive and aimed at particular PHP software.