Phase 3: First deployment
Now that the first app has been created, it can be installed on the production server. There are two basic tasks in this: installing the Symfony software, and installing the particular application.
- application: the Symfony documentation recommends installing this outside the public web directory structure (public_html or whatever). This is a good idea, but of course if you're using a hosting company you may be limited in what you can do. Either way, the only thing that absolutely has to be in the public structure is 'index.php', the default 'front controller'. This sets $SF_ROOT_DIR which needs to point to your project directory, 'symf' in our case. In the default setup, where index.php is in web/, this is ../symf, but of course it can be anything. See Symfony documentation for more details. Any 'assets' used by the public pages, images/css/js/videos/etc, should also go in the public structure. You do not have to copy everything over, as things like the data model are only needed when you set up or change the database. What we need on our system is apps/, config/ (though several of these files are only used for data modeling), our database in data/, and the classes in lib/. Empty cache/ and log/ dirs can be created ready for use.
- Symfony: of course, if Symfony is already installed on the production system, you don't need to install it again. If not, it needs to be installed somewhere, preferably outside the public web directory structure. Symfony provides a facility for setting up a default structure in the application, 'symfony freeze' (its opposite is 'unfreeze'); this copies the Symfony software into data/symfony/ and lib/symfony/. So, once your application is set up, you can run this to install the software in your app, or of course install the software anywhere else you please. Wherever you install it, config/config.php needs to be changed to point to it. 'symfony freeze' does this for you
So, in our case, we install Symfony and application (no, I shan't tell you where they are). As a sort of pseudo-staging server, we can install index.php in its own directory to start off with to check everything works. There are however a number of other issues to be thought about before going live.
- file permissions: Symfony assumes that webserver and developer are different users, so gives world-read permissions to all files, and world-write to other important ones, such as the SQLite db. On a shared hosting system, this is horribly insecure. If you're fortunate enough to have a host that uses suphp or similar, remove these world permissions from your files/dirs (e.g. on the top-level directory)
- crud: because we generated the CRUD for the blog and categories, the CUD options are available for anyone to use. The Symfony tutorial gets around this by creating a separate backend for these maintenance functions, but on a lightweight system such as our blog this seems like overkill to me. Alternatives are to get rid of these options completely, rename them to something obscure no-one can guess, and/or use the routing file to access them from a different url
- cookie identifier: change default in apps/main/config/factories.yml as described in Symfony documentation
- robots.txt and favicon.ico already exist, but don't forget to copy over web/.htaccess checking that it will work in the live environment. Beware that mod_rewrite, used in symfony's default .htaccess file, applies to any subdirectories, so if, like me, you are converting a site in phases and still have some genuine subdirectories where you do not want symfony's rewrites to apply, you will have to have an .htaccess file in those subdirectories to reset the engine:
RewriteEngine off