5 ms·

One word: deployment To me, the best thing about PHP is that it is so easy to deploy to pretty much any shared hosting on the planet, not to mention really eas

One word: deployment To me, the best thing about PHP is that it is so easy to deploy to pretty much any shared hosting on the planet, not to mention really easy to set up on your local machine (with WAMP/MAMP). I love Rails, but on many occasions have built projects in PHP (using a decent framework like Kohana) just because I was putting this on my client's shared hosting account and didn't want to deal with having them get a new server, or just plain setting up Rails. Yeah yeah, I know there's passenger now, etc. -- still not as stupid easy as dropping a php file into a web directory (and assuming that Apache is set up with mod_php, or FastCGI or whatever -- which it always is).

generalk 15y ago
One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to. For example: you can update the Rails code on the server, maybe run some data migrations or last-minute production tasks against the new codebase, and THEN tell Passenger to reload the application code. On an unrelated note, having the Heroku service around for low-traffic side projects or whatever is just plain awesome.
- joelhaasnoot 15y ago
  Lots of PHP folks call that a disadvantage... It's nice knowing I can mess with files and after pressing F5 I'll always have the latest version. Yes, ok, caches can get out of sync, but they're easy to clear. There are furthermore no good PHP deployment automations, things Rails and Python have because of the level of complexity.
  - bad_user 15y ago
    You do know that reloading is just a configuration option, right?
  - FooBarWidget 15y ago
    You claim that deployment automations for Rails and Python exist because of the complexity? Have you ever worked with PHP apps that are larger than 1 single file and use the database? Things like Capistrano do a lot of things that even PHP would benefit from. Deployments are rarely atomic actions. With Capistrano, apps are stored in versioned release directories. Apache points to a 'current' symlink which points to the latest release directory. Upon deployment, Capistrano creates a new app directory, runs database migrations or updates configurations or creates asset files or whatever is necessary to upgrade the app. Only after it's done will it update the 'current' symlink and instruct the app server to restart. Consider what happens if you upload your new PHP app with FTP. If someone visits /some_page.php while you're uploading then he could access an old version of it. Suppose some_page.php depends on common_library.php which may have been updated to the latest version in the mean time. Then things blow up because the new common_library.php is not compatible with the old some_page.php. With Capistrano, the deployment is as good as atomic. Capistrano also supports deploying to multiple servers at the same time, and even to servers that are behind a firewall and can only be accessed through a gateway server. It supports rolling back to a previous version. And much more.
    - chrismsnz 15y ago
      After having battled a PHP (mod_php) deployment system and having to hack the hell out of capistrano to get a usable one... Amen to your comment.
  - wmoxam 15y ago
    You can (and people do) use Capistrano to deploy php code.
    - joelhaasnoot 15y ago
      While you can, I've found Capistrano is full of rubyisms and makes inferences. Sure it can all be changed, but needs a power user to really use it. Couldn't get it to work myself due to various issues related to running DirectAdmin control panel, and protections against symlinks it has built in.
      - jscheel 15y ago
        I had never used capistrano before, and still managed to get it working for a node.js project, which also involved Mono, c#, several monit scripts, etc. My config file is pretty big, and the documentation wasn't awesome, but at least it's working. If you want automated deployment, it's definitely worth the effort.
- jordanlev 15y ago
  Don't get me wrong -- passenger is great. But it's not set up by default (or even possible to set up often) on most shared hosts. Heroku is cool, but as a freelance developer I've found that it's best for me to not take any responsibility whatsoever for the hosting side of things -- just leads to the most un-fun kind of responsibility down the road. Also, we're mostly programmers here, but there are a vast number of websites created by designers who have very limited understanding of programming and hosting setups, and all they know is shared hosting, copying files via ftp, and setting up wordpress (and maybe creating a database in phpMyAdmin). Speaking of wordpress, that reminds me of the #2 reason for PHP's continued popularity despite its arguable sucktitude: applications! See http://www.codinghorror.com/blog/2008/05/php-sucks-but-it-doesnt-matter.html http://www.codinghorror.com/blog/2008/05/php-sucks-but-it-do...
- deleted 15y ago
  [deleted]
- jawngee 15y ago
  You can do this if you have APC (and you should) installed and running. You can even nuke all the PHP files and APC will still serve the cache until you restart apache/nginx/php-fpm/whatevs.
- mscarborough 15y ago
  > One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to. You can get this with PHP's APC opcode caching with file_stat turned off. You deploy and when you're ready you clear the opcode cache. Or if you want to deploy and clear, then add that to your deploy script. Done.
voidfiles 15y ago
While I don't agree that it's good. It is definitely a huge reason why beginners love PHP. For learning how to code you can't beat how easy it is to put PHP on a server. Also things like, file_get_contents() is stupid simple. It's often abused but you can put anything in that and get something back. Even a URL. Who care's if every once in a while you get a 500, or 404. Most of the time it works just fine. PHP is going to be really hard to replace. I think your better off looking to graduate PHP developers to something else.
podperson 15y ago
I agree completely. It's why I started using PHP and why I continue to use it. I think the only thing around right now with a realistic shot of replacing PHP is JavaScript with node.js, but it will require widespread deployability. If and when node.js becomes easy to deploy on cheap hosts it has a huge number of wins over PHP (to begin with -- one less language to learn, and then even more importantly node.js understands the web page it's buildings and no other server-side language does this).
mlinksva 15y ago
Yeah, as http://blog.ianbicking.org/2008/01/12/what-php-deployment-gets-right/ http://blog.ianbicking.org/2008/01/12/what-php-deployment-ge... spells out in depth.

generalk 15y ago

One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to. For example: you can update the Rails code on the server, maybe run some data migrations or last-minute production tasks against the new codebase, and THEN tell Passenger to reload the application code. On an unrelated note, having the Heroku service around for low-traffic side projects or whatever is just plain awesome.

joelhaasnoot 15y ago
Lots of PHP folks call that a disadvantage... It's nice knowing I can mess with files and after pressing F5 I'll always have the latest version. Yes, ok, caches can get out of sync, but they're easy to clear. There are furthermore no good PHP deployment automations, things Rails and Python have because of the level of complexity.
- bad_user 15y ago
  You do know that reloading is just a configuration option, right?
- FooBarWidget 15y ago
  You claim that deployment automations for Rails and Python exist because of the complexity? Have you ever worked with PHP apps that are larger than 1 single file and use the database? Things like Capistrano do a lot of things that even PHP would benefit from. Deployments are rarely atomic actions. With Capistrano, apps are stored in versioned release directories. Apache points to a 'current' symlink which points to the latest release directory. Upon deployment, Capistrano creates a new app directory, runs database migrations or updates configurations or creates asset files or whatever is necessary to upgrade the app. Only after it's done will it update the 'current' symlink and instruct the app server to restart. Consider what happens if you upload your new PHP app with FTP. If someone visits /some_page.php while you're uploading then he could access an old version of it. Suppose some_page.php depends on common_library.php which may have been updated to the latest version in the mean time. Then things blow up because the new common_library.php is not compatible with the old some_page.php. With Capistrano, the deployment is as good as atomic. Capistrano also supports deploying to multiple servers at the same time, and even to servers that are behind a firewall and can only be accessed through a gateway server. It supports rolling back to a previous version. And much more.
  - chrismsnz 15y ago
    After having battled a PHP (mod_php) deployment system and having to hack the hell out of capistrano to get a usable one... Amen to your comment.
- wmoxam 15y ago
  You can (and people do) use Capistrano to deploy php code.
  - joelhaasnoot 15y ago
    While you can, I've found Capistrano is full of rubyisms and makes inferences. Sure it can all be changed, but needs a power user to really use it. Couldn't get it to work myself due to various issues related to running DirectAdmin control panel, and protections against symlinks it has built in.
    - jscheel 15y ago
      I had never used capistrano before, and still managed to get it working for a node.js project, which also involved Mono, c#, several monit scripts, etc. My config file is pretty big, and the documentation wasn't awesome, but at least it's working. If you want automated deployment, it's definitely worth the effort.
jordanlev 15y ago
Don't get me wrong -- passenger is great. But it's not set up by default (or even possible to set up often) on most shared hosts. Heroku is cool, but as a freelance developer I've found that it's best for me to not take any responsibility whatsoever for the hosting side of things -- just leads to the most un-fun kind of responsibility down the road. Also, we're mostly programmers here, but there are a vast number of websites created by designers who have very limited understanding of programming and hosting setups, and all they know is shared hosting, copying files via ftp, and setting up wordpress (and maybe creating a database in phpMyAdmin). Speaking of wordpress, that reminds me of the #2 reason for PHP's continued popularity despite its arguable sucktitude: applications! See http://www.codinghorror.com/blog/2008/05/php-sucks-but-it-doesnt-matter.html http://www.codinghorror.com/blog/2008/05/php-sucks-but-it-do...
deleted 15y ago
[deleted]
jawngee 15y ago
You can do this if you have APC (and you should) installed and running. You can even nuke all the PHP files and APC will still serve the cache until you restart apache/nginx/php-fpm/whatevs.
mscarborough 15y ago
> One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to. You can get this with PHP's APC opcode caching with file_stat turned off. You deploy and when you're ready you clear the opcode cache. Or if you want to deploy and clear, then add that to your deploy script. Done.

voidfiles 15y ago

While I don't agree that it's good. It is definitely a huge reason why beginners love PHP. For learning how to code you can't beat how easy it is to put PHP on a server. Also things like, file_get_contents() is stupid simple. It's often abused but you can put anything in that and get something back. Even a URL. Who care's if every once in a while you get a 500, or 404. Most of the time it works just fine. PHP is going to be really hard to replace. I think your better off looking to graduate PHP developers to something else.

podperson 15y ago

I agree completely. It's why I started using PHP and why I continue to use it. I think the only thing around right now with a realistic shot of replacing PHP is JavaScript with node.js, but it will require widespread deployability. If and when node.js becomes easy to deploy on cheap hosts it has a huge number of wins over PHP (to begin with -- one less language to learn, and then even more importantly node.js understands the web page it's buildings and no other server-side language does this).

mlinksva 15y ago

Yeah, as http://blog.ianbicking.org/2008/01/12/what-php-deployment-gets-right/ http://blog.ianbicking.org/2008/01/12/what-php-deployment-ge... spells out in depth.