This page lists potential problems that you may encounter while installing, configuring, and running eZ Platform.
Initial installation options¶
If you accepted default options during
composer install, but need to change some of them later,
you can do it in the
Enable swap on systems with limited RAM¶
If you have problems installing eZ Platform on a system with limited RAM (for example 1GB or 2GB), enable swap. It allows your operating system to use the hard disk to supplement RAM when it runs out.
With swap enables you will be able to successfully run
php -d memory_limit=-1 bin/console ezplatform:install --env prod ezplatform-clean.
When a system runs out of RAM, you may see
Killed when trying to clear the cache (e.g.
php bin/console --env=prod cache:clear from your project's root directory).
Upload size limit¶
To make use of the Back Office, the defined maximum upload size must be consistent with the maximum file size defined in the Content Type using a File, Media or Image Field.
This is done by setting
LimitRequestBody for Apache or
client_max_body_size for nginx.
For instance, if one of those Fields is configured to accept files up to 10MB, then
client_max_body_size (in case of nginx) should be set above 10MB, with a safe margin, for example to 15MB.
You also need to define settings for uploading files in
Cloning failed using an ssh key¶
When dealing with Composer packages from updates.ez.no, you may get a "Cloning failed using an ssh key" error if you tell Composer to download dev packages or to download from source. updates.ez.no currently supports only distribution packages in alpha stability or higher.
To avoid the error, check the stability of packages and avoid using
Redis: Cache / Session data inconsistent across web servers¶
See Redis Cluster info in persistence cache doc, and make sure you only read/write to one active master instance at a time.
Redis: Sessions are removed or new sessions are refused¶
See info on Redis in session doc. Ideally, use a separated instance of Redis for sessions, that either never runs out of memory or uses an eviction policy that suits your needs.
Conflict with roave/security-advisories¶
When you use
composer update or
composer require, a package may conflict with
1 2 3 4
This means there is a known security bug in the specific version of the package,
In most cases this means that a fix is available in a newer version.
If you increase your requirement to that version, the conflict is resolved.
In the rare case when there is no fixed version, you can revert your requirement to an older version which does not have the bug.
If you have to use the version with the bug (not recommended) you can use
composer remove roave/security-advisories.
In such case, require it again when the bug is fixed and the package is updated:
composer require roave/security-advisories:dev-master
Platform.sh HTTP access credentials with Varnish¶
If you are using Platform.sh with Varnish for HTTP cache and you have HTTP access control by login/password enabled, configure the following variables in your Platform.sh environment: