Project context

The project is installed on a Debian Linux VM (Virtual Box), and we need to debug a problem from an SQL file containing anonymised production data. The SQL file is several gigabytes in size.

Despite multiple attempts to import – whether via PHPStorm from your host machine, via command line from the host, or directly within the VM via its terminal – the result is always the same: the VM freezes, the import fails during the process, forcing you to start all over again.

Workaround

The best solution is to split the file into several smaller SQL files. We can then import the files to complete the data model from the table that crashed. This way, each file can be re-imported until the import is complete.

Thanks to Kedar Vaijanapurkar who developed a script for manipulating mysqldump files: https://github.com/kedarvj/mysqldumpsplitter/

MySQLDumpSplitter

Setup the script on your computerhttps://github.com/kedarvj/mysqldumpsplitter/blob/master/mysqldumpsplitter.sh et and add execution rights :

$ chmod +x mysqldumpsplitter.sh 

List all tables in SQL file:

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

Export the biggest table that crash your import:

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

We get a out/ folder with a file TABLE_NAME.sql.gz .

Import a gzip file in MySQL

To import a .gz file, use gunzip with the following commande:

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

Unfortunately, we do not have much information on the progress of this import.

Progress bar

We need a progress bar to see how the import is going:

Install the progress bar

sudo apt install pv

Use pv

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

Export multiple tables

Exporting and importing work perfectly for a single table. Here's how to export multiple tables:

$ ./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)' 

Bulk import script

We are not going to execute one command per table, so we will develop a small script to import all the files in theout/ folder

   

#!/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  
   

Execution of a progressive import that runs smoothly:

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

Debugging of the project can begin!

Please contact us for any debugging requests for your solutions or for the implementation of your project. Do not hesitate to get in touch.
 

On 10 December 2025, Ibexa published a security advisory and subsequently released new versions of Ibexa DXP v4.6.26 and v5.0.4.

As part of an Ibexa 5 project, we identified a security flaw when changing a user's password.

We reported this flaw to the publisher Ibexa through our client's support portal. Ibexa fixed it and included it in the new version 5.0.4. Thank you to Ibexa for the mention 👏

Don't wait to start an Ibexa 5 project to benefit from Symfony 7 and PHP 8.3 and above. Despite a few anomalies that we are identifying as we go along, version 5 is very stable and perfectly suited to starting your DXP project.

Zones in Ibexa Page Builder

Within the Ibexa DXP Page Builder, you define the layout of your pages by declaring content zones. Blocks are then dragged and dropped into these zones to construct the page progressively, block by block.

Here's an example of a zone configuration within an Ibexa YAML file:

        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'

The 'top' zone name is 'top' but this name won't appear anywhere in the Page Builder's edit interface; it will be identified as Drop zone 1:

The same principle applies in the Structure view (which is very useful to move blocks from one zone to another). Zones are identified as Drop zone 1, Drop zone 2, Drop zone 3, and so on...:

What's the point of assigning a specific name in the configuration if that name isn't used anywhere?

How is the zone name displayed?

The zone names are displayed in JavaScript by the following 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');

It's tricky translating text strings when the labels change depending on the area. Within the page.builder.js script, it appears that if a <fieldset> element already exists in the DOM for a given area, it isn't recreated.

Without getting into overly complex development or kernel hacks, we should be able to add this HTML block to our layout template to properly name our areas,

Ensuring intuitive zone names

Consequently, we've added the <fieldset> and <legend> elements, with the zone name configured in our YAML file, to our three_rows_two_columns.html.twig template.

<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

The preview areas now offer clearer, more informative feedback, which is particularly helpful when dealing with complex editorial management scenarios, such as the following example:

Without explicit zone names, the editorial team can't distinguish between a Cover zone, a zone with stackable blocks (which we'll discuss in a future article), or a adaptable zone where blocks display one after the other.

Any ideas on how to promote this functionality, which really should be native in Ibexa DXP within the Structure view? I'm calling on the Ibexa team to bring us this small improvement with Ibexa 5.

Update of 16th of october

We continued development and created a hack to get all the areas with the desired name. Voilà!

If you would like to know more, please do not hesitate to contact us.