3 ms·

>> 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 overwri

>> 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
The fact that doing a filesystem-level end run around is simpler and more reliable boggles my mind. When I started experimenting with it I thought "this will never work, there's all sorts of things that can go wrong" but I eventually wound up migrating all of my PHP-based applications (WordPress, Piwik, and PMWiki) to it because it was so much easier to work with (even with maintaining the control software) than doing it the standard way.

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

The fact that doing a filesystem-level end run around is simpler and more reliable boggles my mind. When I started experimenting with it I thought "this will never work, there's all sorts of things that can go wrong" but I eventually wound up migrating all of my PHP-based applications (WordPress, Piwik, and PMWiki) to it because it was so much easier to work with (even with maintaining the control software) than doing it the standard way.