Multilanguage website setup is standard in ezplatform/Ibexa CMS/DXP. Basically, you need to setup a language per siteaccess. Using fallback content language(s) is optional. If you only have one domain then you don’t have really to configure it explicitly in the main configuration file: ezplatform.yaml

If you have a multisite installation with different domains then you have to consider the siteaccesses Map\Host matcher.
ℹ️ More information in: https://doc.ibexa.co/en/latest/guide/multisite/siteaccess_matching/#maphost

On the frontend side, you will have most of the time to add a language switcher so that users are able to switch between the different content languages:

Everything will work fine until you will have a login page!

Expected from our above configuration and usability: If a user is logged in to the German website then you are expecting that he will be automatically logged in to the french website just by switching the language.

but it won’t work!

This is because session is not shared between siteaccesses. Below is described in the documentation https://doc.ibexa.co/en/latest/guide/sessions/#session-options-per-siteaccess

It means that per default each siteaccess has a different session name because of the suffix siteaccess _hash.

At this Step, you have to log in to all website languages which is inconvenient.

However, in previous documentation it was mentioned that you can skip the session_hash and by doing it that way the automatic login in different siteaccesses will work.

So you have either to configure it on each siteaccess or much comfortable on siteaccess group level:

It is also possible to share the same session name between the back and the front office. In some situations, you have a protected area in the front office using private sections and you would like to preview the page without login again. This setting can be very useful in the Ibexa experience pagebuilder preview mode as well.

Did you encounter difficulties when updating to Ibexa 3.3.7 and you get below issue:

Attempted to load class BatchIterator from namespace "eZ\Publish\API\Repository\Iterator". Did you forget a "use" statement for another namespace?


This post can help you to fix it

---

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.7 (Release date: September 3, 2021)

Please always refer to Ibexa 3.3 Upgrade Documentation

let’s start with the update steps:

Create a new branch from your dev project branch

Execute below command

You will notice below changes:

At this Step, Ibexa mention reviewing the changes and add them to our project.

In my case, I had to restore bundles.php because it adds the KaliopMigration bundle and it is not supported in v3.x. The ezplatform.yaml contains some custom configuration and nothing special was added to this file.

Execute

This will add below line in composer.json

Make some changes as recommended in the Ibexa upgrade documentation

ℹ️ Please pay attention to - and + lines

run

UPS! You will get the below error:

At this Step, you have to consider this documentation page and some additional steps: https://doc.ibexa.co/en/latest/updating/updating_to_3.3/#update-to-v33x

Make composer.json changes according to the Documentation

AT THIS STEP, JUST READ DO NOT DO ANY CHANGES YET! Goto: Next Step

According to the documentation, we should now run:

BUT you will get below error:

I noticed in my Installation that composer.json contains a lot of required symfony 5.2 bundles e.g:

Do not set these bundles to 5.3 otherwise you will end up with a lot of compatibility issues like (lock file version)

I was not able at this step to get the right composer.json for Ibexa Experience either from https://github.com/ezsystems/ezplatform-ee or https://github.com/ibexa/experience.

---

Next Step: I decided to install Ibexa Experience 3.3.7 from the scratch in another folder and check the difference between the composer.json files.

To install Ibexa Experience 3.3.7 you have to run the below command:

Now my composer.json looks like this: https://gist.github.com/arfaram/b793bb7944d8802e3f2b52ce052db0a9

ℹ️ Consider to add your custom bundles or configuration to this file. You can use phpstorm history function for that purpose 😉 )

At this Step, I decided to make the update in a different way because the composer require ibexa/experience:3.3.7 always fails.

Now everything should looks good regarding the symfony 5.3 and Ibexa 3.3.7 bundle versions

At the end just run

---

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:

vendor/ibexa/installer/upgrade/db/mysql/ibexa-3.3.0-to-3.3.1.sql
vendor/ibexa/installer/upgrade/db/mysql/ibexa-3.3.1-to-3.3.2.sql

+
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 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

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

• postgres
• dpage/pgadmin4
• Running the Elastic Stack with Kibana on Docker
• Redis

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:

config/packages/ezplatform.yaml

config/packages/framework.yaml

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.

Create APP SECRET
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

Output:

ℹ️ 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 127.0.0.1:8000

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

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

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:

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

---

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 🙂

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.