Ibexa DXP Discussions

Community discussion forum for developers working with Ibexa DXP

Kaliop/MigrationBundle: Error thrown while running command


I’ve installed Kaliop/MigrationBundle and I have errors thrown each time I run command:

root@myhost:/path/to/ezplatform# php app/console kaliop:migration:status
16:13:02 ERROR     [console] Error thrown while running command "kaliop:migration:status". Message: "The helper "table" is not defined." ["error" => Symfony\Component\Console\Exception\InvalidArgumentException { …},"command" => "kaliop:migration:status","message" => "The helper "table" is not defined."] []
  The helper "table" is not defined.

I have always the same errors if I run the following command:

root@myhost:/path/to/ezplatform# ./bin/phpunit -c vendor/kaliop/ezmigrationbundle/phpunit.xml
FFFFFFFFFS.migration aborted with status 2 during execution of step 'abort'. Message: Oh yeah
FF.                                                    79 / 79 (100%)migration step 'void' has been executed
There were 69 failures:

Here is a NON-exhaustive bundle list versions, which might be helpful as context hints:

php ../composer.phar show
ezsystems/ezpublish-kernel - v6.12.0.1
ezsystems/ezpublish-legacy - v2017.10.0
ezsystems/legacy-bridge - v1.4.0.1
ezsystems/platform-ui-bundle - v1.12.0.1
kaliop/ezmigrationbundle - v4.3.0
lolautruche/ez-core-extra-bundle - v2.1.0
netgen/admin-ui-bundle - v2.0.3
phpunit/phpunit - v6.4.4
symfony/symfony - v3.3.10

Any idea ?

(edited) more hints:
php app/console kaliop:migration:generate --> works fine, I can generate my YML files
php app/console kaliop:migration:migrate --> throws the same exception
The DB table ‘kaliop_migrations’ has been created and filled with phpunit command, but not with kaliop:migration commands (it’s normal as of recent versions as I understood ?)


The ‘table’ helper is part of Symfony console. A quick googling around reveals that it has probably removed in Sf 3.
Can you confirm which version of Symfoiny you are running?

On a side note: I am not sure if the unit tests would run fine ‘as is’ after installing the extension on a ‘normal’ ez setup, as they do need some scaffolding stuff (ie. extra symfony/ez config). It is something that I have to improve, it just never gets to the top of my backlog :slight_smile:

PS: it seems that you are in luck (for some definition of luck):

in the past I did not upgrade the Mig. Bundle to use the new-ish Sf Console Table class instead of the Table helper because the Mig bundle had a minimum dependency on Sf 2.3, which did not have the Table class and only had the Table helper. Otoh Sf 3.0 onwards does have the Table class but not the Table helper any more (talk about Sf maintaining BC promises…).
Now, since currently the Mig bundle requires at a minimum eZ 2014.11, which requires Sf 2.5, the Mig Bundle can happily assume that the Table class is there and get rid of the Table helper.

Could you open a ticket in the Github tracker of the Mig Bundle ?

Hi gggeek,

Thank you for your answer.
As I mentioned, I run:

OK I will open a ticket on Github tracker.

And I will also try to install Mig Bundle on a Sf 2.8 instance, just to validate it works fine for me, and doesn’t crash because of something else.

I confirm, MigBundle v4.3.0 + Sf2.8.26 works fine on a normal ezplatform setup v1.12.
Thus my errors / thrown exceptions were due to the Sf3.3.10.
Now I see how it works, I will be very happy to use it :wink:

FYI, if it can help you, here my phpunit results without any extra symfony/ez config:

./bin/phpunit -c vendor/kaliop/ezmigrationbundle/phpunit.xml
PHP Warning:  file_put_contents(Tests/dsl/good/references/test_refs_generated.yml): failed to open stream: No such file or directory in /srv/www/ezplatform02/ezplatform/vendor/kaliop/ezmigrationbundle/Core/Executor/ReferenceExecutor.php on line 156
F........... 65 / 79 ( 82%)
.........S.migration aborted with status 2 during execution of step 'abort'. Message: Oh yeah
...                                                    79 / 79 (100%)migration step 'void' has been executed
There were 3 failures:
1) MigrateTest::testExecuteGoodDSL with data set #3 - UnitTestOK004_content.yml
2) MigrateTest::testExecuteGoodDSL with data set #11 - UnitTestOK012_objectState.yml
3) MigrateTest::testExecuteGoodDSL with data set #15 - UnitTestOK016_references.yml
There were 3 risky tests:
1) CollectionsTest::testValidElements1
2) CollectionsTest::testValidElements2
3) CollectionsTest::testValidElements3
Tests: 79, Assertions: 442, Failures: 3, Skipped: 1, Risky: 3.

About the failing unit tests: I just fixed (hopefully) the problem with UnitTestOK016_references.yml.
The failure of UnitTestOK012_objectState.yml is a known regression appeared in the very latest eZ kernel.
On the other hand I have no idea about why UnitTestOK004_content.yml would fail.

How did you set up eZPlatform (and especially the DB) before running the tests?

Thank you very much for fix update 4.4.0.
Now my “status” and “migrate” commands work fine in the latest release, whatever Sf2.8.x or Sf3.3.10


Here is the detailed output for this failure:

1) MigrateTest::testExecuteGoodDSL with data set #3 ('/srv/www/ezplatform02/ezplatf...nt.yml')
CLI Command failed. Output:
    | # | Migration                 | Notes |
    | 1 | UnitTestOK004_content.yml |       |


    Processing UnitTestOK004_content.yml

    Migration aborted! Reason: Error in execution of step 1: FieldType 'ezxmltext' not found, needs to be implemented or configured to use FieldType\Null\Type (%ezpublish.fieldType.eznull.class%) in file /srv/www/ezplatform02/ezplatform/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Repository/Helper/FieldTypeRegistry.php line 64

    Failed asserting that 1 is identical to 0.


I’m not really surprised, because the ezxmltext fieldtype has disappeared in ezplatform, and replaced by richtext fieldtype. Am I wrong ?


I don’t exactly what kind of details you want to know ?

This is a Maria DB server.
Database has been created with root user:

 mysql -u root
    MariaDB [(none)]> create database ezplatform01 character set utf8;

“root” user has “unix_socket” plugin, and a user has been created with grant access for this DB.

Oups! Not totally true…
The interface support on eZ Platform UI has disappeared, but not the fieldtype, to be exact ?