Running eZ Publish Legacy on

June 27, 2017

by Serhey Dolgushev

We had eZ Publish 4.3 website with DFS cluster and wanted to move it to a Production Standard instance. The main steps in this process are:

  1. Setup services and routes.
  2. Describe the application.
  3. Inject service configurations into the eZ Publish settings.
  4. Deploy code base to

Setting up services and routes uses services.yaml for services and routes.yaml for routes configuration. Both of them are well documented, so we will focus only on our use case.

Our project does not using any custom rewrite rules, that’s why our routes definition file is the simplest possible:

We are not using SOLR on our project, so MySQL was the only other service needed. But we were using a separate database for DFS clusterization on our previous hosting platform, and we wanted to keep it. That’s why we need two databases on main and cluster. In this case the services definition file looks like:

It looks pretty simple and please feel free to ask a question in comments or check Database service documentation if you have some questions about it.

The last remaining configuration file is the application definition file, which is

Describe application

In our case the application definition file was the following:

Some comments about it:

  • We decided to use PHP 5.4 for this application because of the eZ Publish version.
  • Composer is not used in this case and that’s why "build.flavor” is set to “none”.
  • web.locations./.rules defines the eZ Publish clustering rewrite rules.
  • /mount is the DFS mount point, specified eZ Publish Legacy clustering configuration. And please note that only /var and /mount paths are writeable after the application is built on
  • In “” we are overriding eZ Publish kernel autoloads to be able to use a custom eZINI class to read database settings from environment variable and it will be covered below. Also we are regenerating regular autoloads file.
  • In hooks.deploy we clear the caches.

Inject service configurations to eZ Publish settings assumes that application will read service configurations from PLATFORM_RELATIONSHIPS environmental variable. But eZ Publish Legacy does not have any built-in functionality for doing this. That’s why we came up with our solution: override eZINI class and implement some custom code to read configurations from the environment variable. In order to implement it, you need to:

  1. Set EZP_AUTOLOAD_ALLOW_KERNEL_OVERRIDE to true in config.php file
  2. Copy eZINI class (lib/ezutils/classes/ezini.php) to a site specific extension. Let’s assume you are using “site” extension for your project settings and templates. Than you need to run: $ cp lib/ezutils/classes/ezini.php extension/site/classes/override/ezini.php
  3. Regenerate autoloads with -o flag:
  4. Add following code at the very end of parse method:

After these steps the database settings are extracted from PLATFORM_RELATIONSHIPS environment variable and injected into site.ini and file.ini configuration files. Please note, you will need to modify this code if you are using SOLR or trying to inject settings to eZ Publish legacy for any other services.

Deploy code base to

This is probably the simplest step - you just need to follow suggestions. In two words: provides you a git repository for the project. You should add that repository as an additional origin. Each time you push the master branch to that origin, the application is build and deployed on

If you are using git submodules (which is quite common phenomenon for eZ Publish Legacy projects), you need to add deploy key to list of your SSH keys on Github/Gitlab/Bitbucket/etc. You can find it on configure project page, DEPLOY KEY tab.

We hope this blog post was useful for you! If you have any questions, please contact us or leave a comment.

Widget is loading comments...