This section explains how main configuration file app/conf/config.yml works.
It is way more more convenient than launching Install theme for each configuration update.

Your app/conf/config.yml file is built using YAML syntax. Each part matches a Roadiz service configuration.

Note

By default, every Roadiz environment read app/conf/config.yml configuration file. But you can specify different
files for dev and test environments. Just create a app/conf/config_dev.yml or app/conf/config_test.yml file
to override default parameters. You will be able to use a different database, mailer or Solr instance not to pollute your production environment.

Since Roadiz v0.23, themes are statically registered into Roadiz configuration for better performances
and delaying database usage. You have to register any front-end theme in your app/conf/config.yml file.
Theme priority is not handled here but in each of your themes by overriding static $priority value;

When set as null, cache drivers will be automatically chosen by Roadiz according to
your PHP setup and available extensions.

Sometimes, if a cache extension is available but you don’t want to use it, you’ll
have to specify a cache driver type (use array to disable caches). This is a known case
when using OVH shared hosting plans which provide memcached PHP extension but does not let you log in.

By default, Roadiz writes its logs to app/logs/ folder in a file named after your running environment (eg. roadiz_prod.log).
But you can also customize Monolog to use three different handlers. Pay attention that using custom log handlers will
disable default Roadiz logging (except for Doctrine one) so it could be better to always use default handler along
a custom one.

Available handler types:

default: Reproduce the Roadiz default handler which writes to app/logs/ folder in a file named after your running environment

stream: Defines a log file stream on your local system. Your path must be writable!

syslog: Writes to system syslog.

gelf: Send GELF formatted messages to an external entry point defined by url value. Roadiz uses a fault tolerant handler which won’t trigger any error if your path is not reachable, so make sure it’s correct. It’s a good idea to combine a gelf handler with a local logging system if your external entry point is down.

sentry: Send logs to your Sentry instance. Requires sentry/sentry PHP library: composerrequiresentry/sentry. It’s a good idea to combine a sentry handler with a local logging system if your external entry point is down.

type and level values are mandatory for each handlers.

Here is an example configuration:

monolog:handlers:default:type:defaultlevel:INFOfile:type:stream# Be careful path must be writable by PHPpath:/var/log/roadiz.loglevel:INFOsyslog:type:syslog# Use a custom identifierident:my_roadizlevel:WARNINGgraylog:type:gelf# Gelf HTTP entry point url (with optional user:passwd authentication)url:http://graylog.local:12202/gelflevel:WARNINGsentry:type:sentrylevel:WARNINGurl:https://xxxxxx:[email protected]/1

Roadiz can request cache invalidation to external and internal cache proxies such as internal
Symfony AppCache or a Varnish instance. If configured, Roadiz will create a BAN request
to each configured proxy when user clears back-office caches, and it will create a PURGE request
on each node-sourceupdate event using first reachable node-source URL.

Roadiz uses Swift Mailer to send emails. This awesome library is built to enable different
kinds of mail transports and protocols. By default, Roadiz uses your PHP sendmail configuration
but you can tell it to use another transport (such as an external SMTP server) in your app/conf/config.yml file.

Pay attention that many external SMTP services (Mandrill, Mailjet…) only accept email from validated domains.
So make sure that your application uses a known From: email sender not to be blacklisted or blocked
by these services.
If you need your emails to be replied to an anonymous address, use ReplyTo: header instead.

Roadiz use Image Intervention library to automatically create a lower quality
version of your image if they are too big. You can define this threshold value
in the assetsProcessing section. driver and defaultQuality will be also
use for the on-the-fly image processing with Intervention Request library.

Any Intervention Request subscriber can be added to configuration with its classname
and its constructor arguments. Here is an example with WatermarkListener which will
print some text on all your images.

Since you can add Intervention Request subscribers, we created a useful one that sends
every images to kraken.io services to shrink them. Once you’ve configured it,
do not forget to empty your caches and image caches to see changes.

Roadiz can be executed as a simple CLI tool using your SSH connection. This is useful to
handle basic administration tasks with no need of backoffice administration.

./bin/roadiz

If your system is not configured to have php located in /usr/bin/php use it this way:

php ./bin/roadiz

Default command with no arguments will show you the available commands list. Each command has its
own parameters. You can use the argument --help to get more informations about each tool:

./bin/roadiz install --help

We even made Doctrine CLI tools directly available from Roadiz Console. Be careful, these are powerful
commands which can alter your database and make you lose precious data. Especially when you will need to update
your database schema after a Theme or a Core update. Always make a database back-up before any Doctrine operation.

If you are developing your own theme, you might need to create some custom CLI commands. Roadiz can handle
additional commands if you add them in your app/conf/config.yml as you would do for any additional entities.
Make sure that every additional commands extend Symfony\Component\Console\Command\Command class.