eZplatform – Ibexa automatically log in user in different siteaccesses

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:

language_switcher_ibexa_ezplatform

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

ezplatform-ibexa_sessions

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.

Update Ibexa DXP from 3.3.3 to 3.3.7

ibexa_3.3.7

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
  • ibexa_3.3.7_UI

    Update Ibexa DXP from 3.3.1 to 3.3.3

    ibexa_3.3.3


    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 Installation with Redis, Postgresql and Elasticsearch

    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:

    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

    pgadmin

    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:

    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


    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

    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.