SOS : Doctrine migration ne répond plus

Bon sous ce titre un peu rigolo, il y a un vrai problème que je trouve assez frustrant et surtout bloquant. En effet une fois que vous avez mis à jour vos package, plus rien ne marche et la console vous envoie un message d’insulte pas piqué des hannetons (et en rouge en plus, le salopiaud):

Unrecognized options "dir_name, namespace" under 
"doctrine_migrations". Available options are "all_or_nothing", 
"check_database_platform", "connection", "custom_template", "em", 
"factories", "migrations", "migrations_paths", "organize_migrations", 
"services", "storage".

Normalement, grâce à composer, on ne dois pas avoir de problème pour l’ajout et surtout la maintenance des packages, d’autant plus avec Symfony. Sauf que dernièrement avec la dernière mise à jour, Symfony passe de la version 5.0 à la 5.1 et surtout DoctrineMigrations passe de la 2.2 à la 3.0 et là, c’est le drame…

J’imagine que c’est un problème de changement de version qui ne doit intervenir que pour les projets existants, mais c’est fort facheux de perdre du temps bêtement comme ça. J’ai trouvé le coupable, (et qu’on lui traaannchee la têeeeeete, euh hem, je m’égare). Bon, c’est le fichier qui va contenir la configuration de doctrine migration, à savoir ./config/packages/doctrine_migration.yaml
En gros dans votre version, vous devez avoir un truc du genre:

doctrine_migrations:
    dir_name: '%kernel.project_dir%/src/Migrations'
    namespace: DoctrineMigrations

Et c’est bien ce que nous dis le message d’erreur, en gros il se prend direct dir_name comme clé, et il a rien compris, ce qu’il attend maintenant, c’est ça:

doctrine_migrations:
    migrations_paths:
        'DoctrineMigrations': '%kernel.project_dir%/src/Migrations'

En théorie, si vous relancer un composer update ou n’importe quelles autres commandes, ça doit passer, par contre si vous voulez faire une migration, et Bim un nouveau message d’erreur:

The metadata storage is not up to date, please run sync-metadata-storage command to fix the issue

Il semblerait que ça viennent toujours de la version 3.0 de DoctrineMigration, qui as aussi changé le format des migrations ainsi que le nom de la table dans la BDD. Ok pas de problème, je lance la commande indiqué et là c’est super rigolo:

php bin/console doctrine:migrations:sync-metadata-storage

Et bah il me raffiche la même erreur, donc en faite, c’est un souci au niveau du serveur, il faut lui indiquer la bonne version du serveur de BDD à utiliser. J’avais laissé le truc de base dans le .env, mais en fait j’utilise Mariadb. Je suis passé à ça : mariadb-10.3.22, et maintenant la commande fonctionne.

En espérant que cela vous dépanne. Allez bon dev et Banzaï

sources:
  • https://github.com/symfony/symfony/issues/37360
  • https://jmsche.fr/fr/blog/mise-a-jour-de-doctrine-migrations-de-2-x-a-3-0


Choisir la version de PHP pour un projet Symfony

Bonjour, alors mon problème du jour est que quand je veux déployer sur un hébergeur mutualisé, je n’ai parfois pas trop le choix de la version de PHP qui va tourner. Par exemple sur mon hébergement de base chez OVH, bah c’est la V. 7.3.18 MAX, or mon site symfony développé sur ma machine avec la dernière version d’Ubuntu qui est sur la version 7.4 de PHP, va se baser sur celle-ci. Je vais donc avoir un joli message comme quoi mon composer.lock ne correspond à la version du serveur.

Pour corriger ça, il suffit d’indiquer dans notre fichier composer.json la version de PHP que nous voulons utiliser.

Au niveau de la clé  » config  » nous allons ajouter la version à utiliser:

« config »: { « platform »: { « php »: « 7.3.18 » },

Une fois fait, il ne reste qu’a supprimer le dossier vendor et de reancer la commande:

 composer install