4 ms·

> in your terminal You just lost a nontrivial percentage of PHP developers. Far and away the most compelling feature of PHP for a lot of their target audience

by vec 9y ago

> in your terminal You just lost a nontrivial percentage of PHP developers. Far and away the most compelling feature of PHP for a lot of their target audience is that the deploy model is "unzip this file in that folder". If I want to host my own web site but I don't want to "learn to program" there is no alternative.

merb 9y ago
> unzip this file in that folder it's more like "copy these files via ftp to this host" (p.s. that also includes your config.php with plain text passwords of course)
- anshumanravi 9y ago
  A lot of things happened in php world,since you last checked, which is apparently ~ 5 years back. for starters go read about Magento 2 codebase and its code organization and deployment strategy. Whether you do FTP based file deployment or sophisticated CI/CD build, it all depends on developer not programming language you are using.
- vec 9y ago
  Well, yeah. Point being that if I'm used to working with .doc and .xls files there's next to zero new skills I have to learn and nothing that really pulls me out of my comfort zone. I just have to install a text editor ("like Word, but for .php files") and an FTP client ("type this magic string to set it up, then it's just a funny looking file browser") and I'm off to the races.
- wolfgang42 9y ago
  The problem with the "copy these files" approach, even more than dealing with FTP, is that the upgrade process winds up being "copy these files, but be careful not to overwrite any changes you made". Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself. I got fed up with this a few years ago and started building http://bitmash.io http://bitmash.io (yes, shameless plug) which does some fancy filesystem manipulation to swap out the application's files during upgrades while otherwise looking like a perfectly ordinary PHP hosting provider. While I'm proud of this solution it still seems rather silly to have to jump through these sorts of hoops to handle deploys.
  - developer2 9y ago
    >> Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself Tell me about it! It took me an entire day to figure out how to configure a WordPress install in order to allow it to self-update (without ftp). To do it by only granting owner and/or group write permissions, you have to figure out that you need to modify wp-config.php to define the "FS_METHOD" constant with the value "direct". Without this, WordPress code tries to be super clever with its umask settings, which only makes things worse. It quite literally took an entire day to set up WordPress to self update. It's easy if you chmod 0777 nuke the entire install, but extremely complicated to set up with acceptable filesystem permissions. WordPress is designed to be sloppily dropped in a webroot, not to be installed by intermediate users who care about security. Well, as "secure" as WordPress can be. And to be honest, the most secure WordPress installation would be incapable of self-updating, as you're granting the web user write access to the entire installation - not just for updates, but for any vulnerability.
    - deckiedan 9y ago
      Use two users, and wp-cli. I've been doing this for years now. Php runs as a less privileged user, without write permission. If they want to install plugins, they need to enter the FTP name and password of the site dir owner user. Since the FTP connection is localhost, no passwords go over the wire in plaintext. Next, you install wp-cli, and add a real system cron job to 'wp core update', and 'wp plugins update' every hour. You can also do things like transient cleaning once a month, or whatever else, and running the WordPress fake cron. You can then disable wp cron, which saves network resources.
      - developer2 9y ago
        Personally I find ftp as an unacceptable protocol for this purpose. Doesn't matter that it's localhost. It just goes to show WordPress is truly aimed at the lowest common denominator.
    - wolfgang42 9y ago

by vec 9y ago

merb 9y ago

> unzip this file in that folder it's more like "copy these files via ftp to this host" (p.s. that also includes your config.php with plain text passwords of course)

anshumanravi 9y ago
A lot of things happened in php world,since you last checked, which is apparently ~ 5 years back. for starters go read about Magento 2 codebase and its code organization and deployment strategy. Whether you do FTP based file deployment or sophisticated CI/CD build, it all depends on developer not programming language you are using.
vec 9y ago
Well, yeah. Point being that if I'm used to working with .doc and .xls files there's next to zero new skills I have to learn and nothing that really pulls me out of my comfort zone. I just have to install a text editor ("like Word, but for .php files") and an FTP client ("type this magic string to set it up, then it's just a funny looking file browser") and I'm off to the races.
wolfgang42 9y ago
The problem with the "copy these files" approach, even more than dealing with FTP, is that the upgrade process winds up being "copy these files, but be careful not to overwrite any changes you made". Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself. I got fed up with this a few years ago and started building http://bitmash.io http://bitmash.io (yes, shameless plug) which does some fancy filesystem manipulation to swap out the application's files during upgrades while otherwise looking like a perfectly ordinary PHP hosting provider. While I'm proud of this solution it still seems rather silly to have to jump through these sorts of hoops to handle deploys.
- developer2 9y ago
  >> Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself Tell me about it! It took me an entire day to figure out how to configure a WordPress install in order to allow it to self-update (without ftp). To do it by only granting owner and/or group write permissions, you have to figure out that you need to modify wp-config.php to define the "FS_METHOD" constant with the value "direct". Without this, WordPress code tries to be super clever with its umask settings, which only makes things worse. It quite literally took an entire day to set up WordPress to self update. It's easy if you chmod 0777 nuke the entire install, but extremely complicated to set up with acceptable filesystem permissions. WordPress is designed to be sloppily dropped in a webroot, not to be installed by intermediate users who care about security. Well, as "secure" as WordPress can be. And to be honest, the most secure WordPress installation would be incapable of self-updating, as you're granting the web user write access to the entire installation - not just for updates, but for any vulnerability.
  - deckiedan 9y ago
    Use two users, and wp-cli. I've been doing this for years now. Php runs as a less privileged user, without write permission. If they want to install plugins, they need to enter the FTP name and password of the site dir owner user. Since the FTP connection is localhost, no passwords go over the wire in plaintext. Next, you install wp-cli, and add a real system cron job to 'wp core update', and 'wp plugins update' every hour. You can also do things like transient cleaning once a month, or whatever else, and running the WordPress fake cron. You can then disable wp cron, which saves network resources.
    - developer2 9y ago
      Personally I find ftp as an unacceptable protocol for this purpose. Doesn't matter that it's localhost. It just goes to show WordPress is truly aimed at the lowest common denominator.
  - wolfgang42 9y ago