Craft CMS tuning

# ENV var configuration

Craft CMS uses modern .env style configuration, see topic ENV vars. This means you can run your Craft locally and remotely without code or configuration file changes. Locally, your .env file will be modified and read. That file is not part of Git, you don't need it on fortrabbit.

# Manually setting ENV vars

The software templates will populate required ENV vars. If you didn't choose the Craft preset when creating the app or the ENV vars have been deleted, this is likely what needs to be set.

# Craft ENV vars for fortrabbit

CRAFT_DB_DRIVER=mysql
CRAFT_DB_PASSWORD=${FORTRABBIT_MYSQL_PASSWORD}
CRAFT_DB_DSN=mysql:host=${FORTRABBIT_MYSQL_HOST};port=3306;dbname=${FORTRABBIT_MYSQL_DATABASE}
CRAFT_ENVIRONMENT=production
CRAFT_SECURITY_KEY=LongRandomString
.env
apache

The syntax of the keys may differ by Craft CMS version. See ENV var usage for more details on aliases.

# Software template

If Craft CMS is detected or you have chosen it in the software list, the Craft CMS software template will be applied. This will pre-configure common ENV vars, build and post-deploy commands and set the root path to web.

# Database setup

On fortrabbit the environment variables are seeded from the ones set in the fortrabbit dashboard (not from the .env file). If you chose Craft in the software preset when creating the app, all ENV vars at fortrabbit will already be pre-populated.

# Multi-environment configuration

Craft embraces the idea of storing environment specific configurations in ENV vars. You can create groups in every config file. The top level array key maps with the CRAFT_ENVIRONMENT constant, which defaults to the CRAFT_ENVIRONMENT ENV var. With this flexible approach you decide which configurations are under version control to share with your team and which are not. We assume fortrabbit to be your production environment, so the CRAFT_ENVIRONMENT ENV var is set to production on remote and locally to dev.

# Local environment ENV
CRAFT_ENVIRONMENT=dev
shell

# Using .htaccess for redirects and to force https

Craft CMS comes with a predefined .htaccess file that lives inside the web folder. You can extend that with your own rules, like forwarding all requests to https or disabling access on the App URL. Please see our .htaccess articles for examples.

# X-Powered-By headers

You probably think it's a good idea to disable headers that expose which PHP version and CMS you use. And we think so too!

However, internally we analyze this header to determine if it is a static or dynamic PHP response. With this information we generate two different metrics for the dashboard: PHP requests and Static requests. In config/general.php you can disable the header with 'sendPoweredByHeader' => false, (default: true). This is not required, since we strip all X-Powered-By headers eventually.

# Enabling dev mode

Sometime while developing you might want to see some error output directly on your browser screen. That's what the devMode flag is for. See the Craft docs for more details.

# Don't allow updates in production

Craft CMS has the option to run updates directly from the Craft Control Panel. A client or editor might be tempted to use that update button in production. This is not a good idea. On fortrabbit Git is a one-way street, so any changes on the App itself can not easily be ported back to the local development environment. Also composer update might be triggered on the App and that can lead to performance problems.

So it's better to prevent the shiny "update" button from showing up at all. You can do that in your Craft configuration in the general settings with the allowUpdates flag.

# Don't allow admin changes in production

We highly recommend not making any admin changes to your production environment (fortrabbit) at all. Only do editorial changes. Have one single source of truth and only one direction (up). Please also see the official Craft CMS docs on that.

Otherwise you can run into trouble: Imagine you make changes to the database structure, by adding tables for example, changing the field layout in production. Now you don't have the changes locally. But you deploy other new changes from local to production. This might overwrite the project.yml in production and therefore will roll back your changes. Your local development should be your master in applying design and functional changes.

# Change the control panel URL

"Security through obscurity" is a widely discussed concept. We suggest to obscure the control panel URL of your Craft installation, just because you can. Do so with the cpTrigger setting. If you don't set this value it defaults to admin.

return [
  'cpTrigger' => 'godmode'
];
php

# MySQL table prefixes

If your local Craft installation contains a table prefix, the one on the fortrabbit app should be the same. You can set the table prefix, locally in your .env file, and on fortrabbit with the App's ENV vars like so:

# Example Table prefix
CRAFT_DB_TABLE_PREFIX=craft_
.env
apache

# Craft CLI

Craft CMS comes with a built in command line interface which can be called from the console. You can also run it one the environment itself like so:

# Call Craft CLI via php
php craft
shell

Not all Craft CLI commands are safe to run in production. Our recommendations:

• setup/* — Don't, intended to run locally only
• update/* — Don't, if you deploy using git or using project config
• clear-caches/* — Don't, unless you have a good reason
• resave/* — Sometimes needed
• project-config/sync — Only needed if it's not part of your deployment
• migrate/all — Only needed if it's not part of your deployment
• backup/db — Useful to make a database backup. Can harm performance
• restore/db — Useful if you need to revert the DB to a previous state

# Logging

Without configuration, Craft CMS will pipe PHP errors to storage/logs/web.log.

The Craft CMS stream log location can be set to stderr and stdout by setting the environment variable CRAFT_STREAM_LOG=true. This is pre-populated when choosing Craft CMS in the software chooser while creating the app. When the ENV var is present and true, Craft CMS error logs can be accessed through the fortrabbit dashboard.

# Sending mail

Use an external third party transactional mail provider to send emails. Pixel & Tonic (Craft CMS creators) maintain a plugin for Postmark. With that plugin installed you can easily set it up.

See our quirks article on limits sending emails. Also see transactional mail provider integration.

# Licensing Craft CMS

Craft CMS is not all free. To enable the good parts you need to obtain a license from Pixel & Tonic (the folks building Craft CMS). A Craft CMS license is limited to a single domain, which means you can only access the Craft CP with one domain - otherwise you'll see a warning. You might have used the fortrabbit App URL for development and you might have used that to connect your Craft CMS licence with. You can change the domain of a Craft licence as well, if for instance you started with our App URL but now want to use your own domain with your Craft ID — over at https://console.craftcms.com/.

# Craft storage folder

We found a couple of Craft CMS installations blowing up the storage folder. This is often related to plugins and configuration. Some search engine bot might try to crawl all pages, causing a faceted search plugin to create gigabytes of template fragments. Some other plugin may just write very verbose logs. Best, make sure to configure your website to not cause such issues, beside the storage, such issues have impact on performance.