Contexte du projet

Le projet est installé sur une VM Linux Debian (Virtual Box), nous devons déboguer un problème à partir d'un fichier SQL avec des données de production anonymisées. Le fichier SQL fait plusieurs giga octets.

Malgré de multiples tentatives d'importation – que ce soit via PHPStorm depuis votre machine hôte, en ligne de commande depuis l'hôte, ou directement au sein de la VM via son terminal – le résultat est systématiquement le même : la VM se fige, l'importation échoue en cours de processus, obligeant à tout reprendre depuis le début.

Solution de contournement

La meilleur solution envisagée c'est de découper le fichier en plusieurs petits fichiers SQL. Nous pourrons alors importer les fichiers pour compléter le modèle des données à partir de la table qui à plantée. Ainsi chaque fichier pourra être reprise jusqu'à l'import complet.

Merci à Kedar Vaijanapurkar qui a développé un script permettant de manipuler un fichier mysqldump : https://github.com/kedarvj/mysqldumpsplitter/

MySQLDumpSplitter

Pour installer le script https://github.com/kedarvj/mysqldumpsplitter/blob/master/mysqldumpsplitter.sh et ajouter les droits d'éxécution :

$ chmod +x mysqldumpsplitter.sh 

Lister les tables présentes dans le fichier SQL :

$ ./mysqldumpsplitter.sh --source my_huge_sql_file.sql --desc

Exporter la table la plus grosse qui plante à chaque tentative :

$ ./mysqldumpsplitter.sh --source my_huge_sql_file.sql --extract REGEXP --match_str 'TABLE_NAME'

On obtient dans le dossier out/ un fichierTABLE_NAME.sql.gz .

Import d'un fichier gzip dans MySQL

Pour l'importer, on va utiliser gunzip avec la commande suivante :

$ gunzip ./out/TABLE_NAME.sql.gz | mysql -h localhost -u <db_user> --password=<db_password> <DBNAME>

Malheureusement, nous n'avons pas beaucoup d'information sur l'avancé de cet import.

Barre de progression

Il nous faudrait une barre de progression pour plus de visibilité sur l'avancée de l'import :

Installer progresse bar

sudo apt install pv

Utiliser pv

$ pv ./out/TABLE_NAME.sql.gz | gunzip | mysql -h localhost -u <db_user> --password=<db_password> <DBNAME>

Export de plusieurs tables

L'export et l'import fonctionnent parfaitement pour une table, voici comment en exporter plusieurs :

$ ./mysqldumpsplitter.sh --source my_huge_sql_file.sql --extract REGEXP --match_str '(TABLE_NAME_1|TABLE_NAME_2|TABLE_NAME_3|TABLE_NAME_4|TABLE_NAME_5|TABLE_NAME_6|TABLE_NAME_7|TABLE_NAME_8)' 

Script d'import en masse

Nous n'allons pas executer une commande par table, on va donc se développer un petit script d'import de tous les fichiers présents dans le dossier out/

   

#!/bin/bash
for i in ./out/*.sql.gz
do
  echo "Importing: $i"
  pv $i | gunzip | mysql -h localhost -u <db_user> --password=<db_password> <DBNAME>
  wait
done  
   

Exécution d'un import progressif qui se déroule sans accros :

$ chmod +x import-sql-gz.sh
$ ./import-sql-gz.sh

Le débogage du projet peut commencer !

Nous vous invitons à nous contacter pour toute demande de débogage de vos solutions ou pour la mise en oeuvre de votre projet, n'hésitez pas à nous solliciter.
 

Ibexa a publié le 10 décembre 2025 un avis de sécurité et sortie dans la foulée une nouvelle version Ibexa DXP v4.6.26 et v5.0.4.

Dans le cadre d'un projet Ibexa 5, nous avons identifié une faille de sécurité lors du changement de mot de passe d'un utilisateur. 

Nous avons déclaré cette faille à l'éditeur Ibexa au travers du portail de support de notre client. Ibexa l'a corrigé et inclut à la nouvelle version 5.0.4. Merci à Ibexa pour la mention 👏

N'attendez pas pour démarrer un projet Ibexa 5 et bénéficiez de Symfony 7 et PHP 8.3 et +. Malgré quelques anomalies que nous identifions au fils de l'eau, la version 5 est très stable et tout à fait adaptée pour démarrer votre projet DXP.

Les zones du Page Builder d'Ibexa

Dans le Page Builder d'Ibexa DXP, vous pouvez définir le layout de vos pages en déclarant des zones de contribution. Les blocs seront glissés dans ces zones afin de construire progressivement la page bloc par bloc.

Voici un exemple de configuration des zones dans un fichier YAML d'Ibexa :

        dlayout_three_rows_two_columns:
            identifier: 'layout_three_rows_two_columns'
            name: 'Three rows, two columns'
            description: 'Three rows, two columns'
            thumbnail: '/bundles/ibexadashboard/img/layouts/three_rows_two_columns.svg'
            template: '@ibexadesign/dashboard/builder/layouts/three_rows_two_columns.html.twig'
            zones:
                top:
                    name: 'top'
                middle_left:
                    name: 'middle-left'
                middle_right:
                    name: 'middle-right'
                bottom:
                    name: 'bottom'

La zone 'top' porte le nom 'top' mais ce nom n'apparait nulle part dans l'interface d'édition d'une page du Page Builder, elle sera identifiée par Drop zone 1 :

Même principe dans la structure view (très utile pour déplacer vos blocs d'une zone à une autre) les zones sont identifiées par Drop zone 1, 2, 3 ... :

A quoi bon donner un nom spécifique dans la configuration si ce nom n'est utilisé nulle part.

Comment est affiché le nom de la zone ?

Le nom des zones est affiché en javascript par les scripts :

• ibexa/page-builder/src/bundle/ui-dev/src/modules/page-builder/page.builder.js
• ibexa/page-builder/src/bundle/ui-dev/src/modules/page-builder/components/structure/structure.tree.js

const hasFieldset = zone.querySelector('fieldset') !== null;

if (!hasFieldset) {
  const dropZoneLabel = Translator.trans(
    /*@Desc("Drop zone %number%")*/ 'structure.drop.zone',
    {
        number: index + 1,
    },
    'ibexa_page_builder',
  );
  const fieldset = document.createElement('fieldset');
  const legend = document.createElement('legend');

Difficile de traduire une chaine de texte alors que son libellé change à chaque zone. Dans le script page.builder.js, on voit que si un élément <fieldset> est déjà présent dans le DOM de la zone, alors il n'est pas recréé.

Sans faire de développement trop complexe ni de hack kernel, on doit pouvoir ajouter ce bloc HTML dans notre template de layout pour nommer convenablement nos zones.

Avoir des noms de zones intuitifs

Dans notre template three_rows_two_columns.html.twig , on a donc ajouté le <fieldset> et la <legend> avec le nom de zone que l'on a configuré dans notre fichier YAML.

<div class="ibexa-db-zones">
    <div class="ibexa-db-zones__row">
        <div class="ibexa-db-zones__zone" data-ibexa-zone-id="{{ zones[0].id }}">
             <fieldset class="m-page-builder__fieldset">
                <legend class="m-page-builder__legend"
                        style="background-color: white; padding: 3px; border-radius: 5px; border: 1px dashed #4191ff;"
                >
                  {{ zones[0].name }}
                </legend>
             </fieldset>
    
            {% if zones[0].blocks %}
    ...
             
            {% endif %}
        </div>
    </div>
    <div class="ibexa-db-zones__row ibexa-db-zones__row--double">
        <div class="ibexa-db-zones__zone" data-ibexa-zone-id="{{ zones[1].id }}">
            <fieldset class="m-page-builder__fieldset">
                <legend class="m-page-builder__legend"
                        style="background-color: white; padding: 3px; border-radius: 5px; border: 1px dashed #4191ff;"
                >
                  {{ zones[0].name }}
                </legend>
            </fieldset>            
            {% if zones[1].blocks %}

   ...

            {% endif %}
        </div>
    </div>
</div

Les zones de pré-visualisation sont maintenant parlantes et bien plus simples à comprendre, surtout lors de cas complexe de gestion éditoriale dont voici un exemple :

Sans des noms de zones explicites, l'équipe éditoriale ne peut pas distinguer une zone de Cover, une zone avec des blocs empilables (stackable blocks dont nous parlerons dans un prochain article) ou une zone libre avec des blocs qui s'afficheront les uns sous les autres.

Des idées pour propager cette fonctionnalité qui devrait être native dans la Structure view ? J'en appelle à l'équipe d'Ibexa pour nous apporter une petite amélioration avec Ibexa 5.

Mise à jour du 16 octobre

Nous avons poursuivis les développements et réalisé un hack pour avoir l'ensemble des zones avec le nom souhaité. Voilà !

Si vous souhaitez en savoir plus n'hésitez pas à nous contacter.