Deploy Ibexa DXP on Platform.sh
Ibexa DXP is a Composer-based PHP CMS, and as such fits well with the Platform.sh model. As a Symfony-based application its setup is very similar to Symfony.
Ibexa DXP has come pre-configured for use with Platform.sh since its predecessor, eZ Platform 1.13. Version 2.5 and later is recommended. Those are the only versions that are supported. Appropriate Platform.sh configuration files are included in the Ibexa DXP application itself, but may be modified to suit your particular site, if needed.
By default, Ibexa DXP is configured to use a single Redis instance for both the application cache and session storage. You may optionally choose to use a separate Redis instance for session storage in case you have a lot of authenticated traffic (and thus there would be many session records).
To do so, uncomment the
redissession entry in the
and the corresponding relationship in the
The bridge code that is provided with eZ Platform 1.13 and later automatically detects the additional Redis service and use it for session storage.
On a Dedicated Gen 2 instance, we strongly recommend using two separate Redis instances for Cache and Sessions.
The service and relationship names that ship with the default Platform.sh configuration in Ibexa DXP should be used as-is.
To ensure the development environment works like Production, uncomment the
redissession entry in the
.platform/services.yaml file and the corresponding relationship in the
The bridge code that’s provided with eZ Platform 1.13 and later
automatically detects the additional Redis service and uses it for session storage.
By default, on Dedicated Gen 2 instances, both Cache and Session storage are in “persistent” mode, so that data isn’t lost in case of a system or process restart. That reduces the potential for cache stampede issues or inadvertently logging people out.
If you have an existing Ibexa DXP project that was upgraded from a previous version, or want to resynchronize with the latest recommended configuration, see the Ibexa DXP official repository.
In particular, see:
.platform.app.yamlfile, which automatically builds Ibexa DXP in development mode or production mode depending on your defined project-level variables.
- The .platform directory.
For local development on top of a Docker stack, the eZ community provides a tool called eZ Launchpad It improves developer experience and reduces complexity for common actions by simplifying your interactions with Docker containers. eZ Launchpad is ready to work with Platform.sh.
It serves as a wrapper that allows you to run console commands from within the container without logging into it explicitly.
For example to run
cache:clear inside the PHP container do:
~/ez sfrun cache:clear
Note that eZ Launchpad is supported by the community. It might also require adjustments to make it work for Ibexa DXP V4.
eZ Launchpad’s approach is to stay as decoupled as possible from your development machine and your remote hosting whether you are Linux or macOS. To install run:
curl -fLSs https://ezsystems.github.io/launchpad/install_curl.bash | bash
Then you can start to use it to initialize your Ibexa DXP project on top Docker.
or create the Docker stack based on an existing project
git clone <PROJECT_NAME>.git application cd application ~/ez create
Find more details on the eZ Launchpad documentation.
Now, you have a working Ibexa DXP application with many services including Varnish, Solr, Redis, and more.
To generate the key files for Platform.sh (
eZ Launchpad generates the files for you and you are then totally free to fine tune them.
Solr is fully functional with eZ Launchpad but it isn’t enabled by default on Platform.sh. You have to set it up manually following the current documentation.
Actions needed are:
- Generate the Solr configuration thanks to the script provided by Ibexa.
- Put the result in the
.platformat the root of your project.
- Add the service in the
- Add the relationship in the
eZ Launchpad allows you to define environment variables in the
You may use that to set variables to match Platform.sh environments so that you can keep your environment behavior in sync.
Such variables have to be set in the
# provisioning/dev/docker-compose.yml engine: environment: - ASIMPLEVARIABLE=avalue - PLATFORM_RELATIONSHIPS=A_BASE64_ENCODED_VALUE
Thanks to eZ Launchpad, you can work 100% locally: untethered. You have the whole project working offline on machine.
Platform.sh also provides smooth tethered SSH tunnels.
Local services are provided by the Docker stack but there are minimum day-to-day tasks that you might need with Platform.sh.
The main ones are:
- Downstream database synchronization: Getting it from the remote to the local.
- Downstream file storage synchronization: Getting it from the remote to the local.
To help you with that, Platform.sh provides a CLI that you can install.
platform db:dump --gzip -f ezplatform.sql.gz -d data/ -y platform mount:download -m ezplatform/web/var --target=ezplatform/web/var/ -y ~/ez/importdata
The two first lines get the remote database and storage from the remote environment and stores it locally in
The third tells to eZ Launchpad to import those data in the Docker stack.
The storage (images and files) synchronization is optional. Ibexa DXP provides a placeholder generator mechanism that allows you to forget about the real images for your local.