Update Ibexa DXP from 3.3.1 to 3.3.3

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)


Before Read: If you run into more issues don’t hesitate to contact me or just ping me in the ezcommunity.slack.com :

Ibexa DXP 3.3.3 (Release date: Mai 18, 2021)

Please always refer to Ibexa 3.3 Upgrade Documentation

Without any long introduction let’s start with the update steps:

Now you have the latest Ibexa 3.3.3 installation

Be sure to remove the Kaliop bundle in the config/bundles.php file

and set the minimum stability to stable, in composer.json:

Update database to v3.3.3

There are no specific DB updates for 3.3.3 but be sure that below updates are available in your installation:


Be sure that update entity managers introduced in 3.3.2are available:

In my case I got below output:

For this entity I have to run below command to get the SQL statement:

which produce below queries to execute in your DB:

ℹ️ For the time being the comment table updates are needed only when using the Ibexa commerce component

At this Step the whole update installation is done. Enjoy!

Ibexa DXP Installation with Redis, Postgresql and Elasticsearch

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Ibexa DXP version 3.3.2 April 2021
Level: beginner

Next Posts:
* How to move a local installation to Ibexa Cloud
* Using Lando for local development

This post explains how to install Ibexa DXP Experience version 3.3.2 using Postgresql as database and Elastic as search engine and It is the same path to follow to install Ibexa content. The Ibexa documentation is enough to follow but this post is focusing on the Experience Edition and serves as a quick guide.

Note: Ibexa commerce requires Solr and this might not be possible to use Elasticsearch. Be careful if you want to use some free available commerce features in Experience Edition e.g autosuggestion

The installation of Ibexa 3.3.2 is slightly different compared to the previous 3.0 until 3.2 versions. It introduces a new skeleton concept and the installation is very faster and fixes older v3 tags installation with incorrect package versions.

All preparation steps like Node.js, yarn, composer and Token generation are good documented in: Install Ibexa 3.3

let’s get started

For the installation I setup below docker images from Dockerhub and put all recipies in the docker-compose file:

Note: The goal of this post is not the Environement setups as you can have other preferences for the infrastructure.

Create project

Git setups

Dev environement file

Postgresql configuration
At this step you can create a copy of the .env file for the dev environment .env.local and add a database block at the end for better readability.

Redis configuration
Below configuration take into account sessions and persistent cache.
ℹ️ Ideally keep both separated as Redis will then start to refuse new entries once full, including new sessions

.env / .env.local

Adapt the yaml configuration:



Once the installation is done (see “Install Ibexa DXP” section below) and to be sure that data are stored in Redis you can review the cache used in the symfony Profiler toolbar or just monitor the data in redis:

For sessions be sure that session are saved in redis

ℹ️ you can check the session cookie saved in the browser and compare it to the value in redis

Note: If you flush redis cache you are automatically logged out.

below you have different ways to create the APP_SECRET

Adapt the APP_SECRET value in the .env as well as in .env.local

Install Ibexa DXP and create a database


ℹ️ later we will use elastic instead of default legacy search engine

If you have installed pgadmin you can check the different table created


Generate graphql schema

Run post scripts

Run Symfony Server using php7.4

Open the browser and go to

Backend Login
Browse to and login with default credentials:
username: admin
password: publish

In the admin > System Information you will see something like below screen:

Ibexa DXP 3.3.2 Experience

Elasticsearch configuration
Switch from legacy to Elasticsearch
.env / .env.local

Note:At this step the content will not be correctly displayed in the backend

Push the templates

Reindex the database

you can get some information about the content using the CLI:

or using the Kibana console:

Kibana UI

At this step the content is available again in the backend.

Upgrade Ibexa DXP from 3.2.4 to 3.3.1

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)

Before Read: If you run into more issues don’t hesitate to contact me or just ping me in the ezcommunity.slack.com :

During the upgrade from Ibexa DXP 3.2.4 to 3.3.1 (Release date: January 18, 2021) you might meet some troubles regarding the Database upgrades. Basically, the Ibexa 3.3 Upgrade Documentation regarding the git part should almost work. Starting from “Upgrade the database” section you can encounter into below list of issues. This is caused by the migration script which is executed by running below console command:

ℹ️ By the way, this command is executed from the new Ibexa Installer bundle introduced in this release and located in ibexa/installer vendor folder.

ℹ️ This command is located in the Command folder like any Symfony Command

In Ibexa Experience DXP 3.3.1 there are some commerce features available despite of they are part of Ibexa Commerce. Basically, you can make use of some functions like search autosuggestion or Product Catalog and some of the new ContentTypes introduced in this release.

Ibexa DXP 3.2.4 to 3.3.1 Upgrade Issues

The ibexa:upgrade command triggers behind the scene below method:

So, if you take a look to the injected CommerceProvisioner service you will find out that the provision() method is executing below migration file:

and this is where you will end up with the most migration issues

💡: By the way, you will learn some DB debugging 😉

1. Outdated entries in ezcontentclass_attribute_ml Table

The console error will be something similar to:

It happens because some invalid contentclass_attribute_id are available although they don’t exist in the ezcontentclass_attribute table.

So, in my case the last entry in ezcontentclass_attribute is 199 and I don’t have the id 200 in this table although it exists in ezcontentclass_attribute_ml. I find out later that there are more than 5 invalid contentclass_attribute_id in this table.

Basically, a contenttype was deleted but some information still persist in ezcontentclass_attribute_ml, which might be caused by a bug somewhere in the API.

✅ To fix it, you have to delete those invalid rows from the ezcontentclass_attribute_ml table.
ℹ️ And yes as usual you have to backup your DB first.

2. Article ContentType update issue

This issue is caused if you are using the default article ContentType delivered with the default Ibexa installation otherwise the script will break because your installation doesn’t contain this ContentType on update.

In my use case, The migration script will fail because the image FieldType in place is using ezimage and the migration script is trying to convert this field to ezobjectrelation. So, the error you get will be similar to:

Basically, if the script fails at this step you won’t be able to fix it. BUT..

I will recommend to copy the 201804161300_content_types.yml script somewhere in your installation and remove the ezimage update field and execute the script again using:

Now everything should work as expected but if you run into more issues don’t hesitate to contact me or just ping me in ezcommunity.slack.com:

I’ll do my best to help you 🙂

Upgrade to eZ Platform / Ibexa 3.2.4 Error TranslationResourceFilesPass – Bazinga Js Translation Bundle

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)

During upgrading to the latest eZ Platform 3.2.4 you will get below error when the cache clear command is executed:

The error output doesn’t explain what really happened during this process. By running the cache clear command using the verbose option we can see the right error message:

The cause of this issue is related to Bazinga Js Translation Bundle which is being used in: ezplatform-admin-ui v2.2.3

The good news is that this issue is fixed in js-translation-bundle v4.x. You can find the PR here another good news ezplatform-admin-ui v2.3.x is using now the right Bazinga Js Translation Bundle version for eZ Platform 3.3.

The bad news of course you are not able to upgrade to eZ Platform 3.2.4 when using php7.4. Until a fix is delivered by Ibexa.

But there is one quick solution until the fix is available. I have just forked the ezplatform-admin-ui v2.2.3 bundle, upgrading to:

and creating a new tag of the ezplatform-admin-ui v2.2.4

Composer should now know about the above fork:

When you run  composer update, you should get the modified version of ezsystems/ezplatform-admin-ui instead of the one from packagist.