Generally, no. Almost any framework has build steps these days, at least `composer install` to get all the dependencies, and usually also special web server configuration, so you don't expose all your PHP files to the web, only the index.php entry point.

Yup :) You very much just `git clone` a Laravel project, point Apache/NGINX (with PHP-FPM configured) to the `public` folder and all you need to do is run database migrations (for the majority of basic deployments).

I inherited a Symfony2 app and it was a bitch to deploy. It definitely had an asset pipeline.

  php app/console cache:clear --env=prod --no-debug
  php app/console assetic:dump
  php app/console cache:warmup --env=prod --no-debug
  chown -R apache:apache . # fix owner
  chmod -R u=rwx,g=rwx,o=rx app/cache  # fix cache perms
  apachectl restart # bounce Apache, otherwise it can throw segfaults

That chown looks super suspect. Usually you wouldn't want the webserver to have write access to the web application it is executing; that's how you get backdoored.

This is my concern with things like the Wordpress auto updater, but it seems the trade off is not having to worry about manual patch management. Security vs convenience as always.

How I've been running multiple wordpress installs for years:

user: $sitename - the 'owner' of the whole hosted dir. rwX

user: $sitename-PHP - the user that php-fastcgi or whatever runs as, r-X permission on the dir, and write permission on the content uploads directory, but CANNOT write to any plugin install dirs, or upgrade php files.

user: nginx - can read all files except the wp-config.php file, which is limited to only the $sitename group reading it.

then use wp-cli to do automatic upgrades every few hours, and a localhost-only ftp server for wordpress to do plugin installs with. When you try to install a plugin, it asks for a ftp username, host as password. You put in the $sitename user, '127.0.0.1' and $sitename password, and you're set. Those login details are never saved anywhere, so the admin has to put them in each time (or their browser stores them).

Works pretty well for me.

The chmod is pretty suspect as well.

its really not... cache is the equivalent to /tmp

check permissions there sometimes.

Unless it is mounted noexec why would you risk setting the exec bits on files that are writable by the webserver?

The exec bit is also important for accessing sub/directories. Although for that you should use X instead of x…

Of course. I actually regard this as a fairly major issue with the Linux permissions model. Far too many people do as the GP and accidentally set all the files to executable. Cleaning up after someone has done this on a nested set of subdirectories is quite tedious.

NB if anyone has ever run: chmod -R u+x . or equivalent and you run chmod -R u=rwX the files will stay executable...

You can always use find to set all files to +x and directories to -x but then what if some of files needed to be executable?

This is sort of a how to not do things:

1. chown -R apache:apache . # Now the webserver will have write access over the whole application!

2. chmod -R u=rwx,g=rwx,o=rx app/cache # Now all files in cache are executable and writable by the webserver!

3. apachectl restart # graceful might be better here.

Securitywise 1 and 2 are not good things to do.

Hmmm Symfony uses routes declared in a file...