Encodera

Thanks for reading!

Donate to the site — we work hard for you.

Contents

Deployment

Deployment is moving the application from your computer to a server where visitors will see it. Slim has no special commands for it: you deliver the code, install the packages, set the server's settings and turn on caching.

What the server needs

  • PHP of the same version as in development, with the pdo_mysql and mbstring extensions;
  • Composer;
  • an Nginx or Apache web server with public as the site root (see the web server lesson);
  • a MySQL database.

Code and packages

The code is delivered to the server with Git, then the packages are installed:

git clone https://example.com/anna/blog.git /var/www/blog
cd /var/www/blog
composer install --no-dev --optimize-autoloader

The --no-dev option skips development packages such as PHPUnit, and --optimize-autoloader speeds up class lookup.

Server settings

The repository has no .env file — on the server it is created by hand from the .env.example sample:

APP_DEBUG=false
SITE_NAME="My blog"
DB_DSN="mysql:host=localhost;dbname=blog;charset=utf8mb4"
DB_USER=blog
DB_PASSWORD=long-random-password

The key line is APP_DEBUG=false. Then create the database and the tables:

mysql -u blog -p blog < database/schema.sql

Folder permissions

The application writes to two folders: var (the log and cache) and public/uploads (uploaded files). The web server must be allowed to write to them:

mkdir -p var/log var/cache public/uploads
chown -R www-data:www-data var public/uploads

www-data is the user PHP runs as on many servers; your hosting may use another name.

Template cache

Without a cache Twig parses templates on every request. Turn the cache on outside debug mode:

// config/container.php
Twig::class => function (ContainerInterface $c) {
    $settings = $c->get('settings');
 
    $twig = Twig::create(__DIR__ . '/../templates', [
        'cache' => $settings['debug'] ? false : __DIR__ . '/../var/cache/twig',
    ]);
 
    $twig->getEnvironment()->addGlobal('site_name', $settings['site_name']);
 
    return $twig;
},

Route cache

Slim also parses the list of routes anew on every request. The result can be saved to a file:

// config/bootstrap.php
$app = AppFactory::createFromContainer($container);
 
if (!$container->get('settings')['debug']) {
    $app->getRouteCollector()->setCacheFile(__DIR__ . '/../var/cache/routes.php');
}

The line is added before the routes are loaded. The cache works only when every handler is given as a class name: a function cannot be written to a file. The OPTIONS route handler from the CORS lesson has to be moved into an action class.

Updating

When a new version of the code is released, a short list of commands is repeated on the server:

git pull
composer install --no-dev --optimize-autoloader
rm -rf var/cache/*

The last command removes the template and route cache — it is rebuilt on the first request. If the database structure changed, run the necessary SQL queries.

Checking after deployment

What to openWhat should happen
The home pageOpens over HTTPS
/nothingYour 404 page without details
/composer.json, /.envA 404 error
var/log/app.logNo new ERROR records

A site with user login must run over HTTPS. Then add the line 'cookie_secure' => true to the session_start() options in SessionMiddleware — the session cookie will not travel over an unprotected connection.

Common mistake

After an update the site shows old pages or answers 404 for new addresses — an old cache is left over. The var/cache/routes.php file and the Twig cache do not refresh by themselves: clear var/cache on every code update.

Thanks for reading!

Donate to the site — we work hard for you.