Sylius v2 – Demander l’adresse de l’utilisateur à l’inscription

Par Thomas V-G le 26 novembre 2025
Lecture 3 minutes

Dans Sylius v1, l’assemblage et l’ordonnancement des templates passait par des évènements twig. Dans Sylius v2, cela passe désormais par des hooks. Bien que les syntaxes soient similaires, il est intéressant de se pencher sur la nouvelle méthode pour Sylius v2. Nous allons voir comment modifier le formulaire d’inscription pour demander à l’utilisateur de donner son adresse postale.

Bien que ce ne soit pas une pratique répandue, on peut souhaiter que les utilisateurs renseignent leur adresse lors de l’inscription sur le site. L’extension de formulaire sur Sylius v2 côté PHP est identique à celle de la v1. Mais pour les développeurs front-end, la façon de surcharger a évolué depuis la mise en place des hooks. Voici comment ajouter rapidement les champs du formulaire d’adresse dans son formulaire d’inscription.

Mise en place

Créer un fichier src/Form/Extension/CustomerRegistrationTypeExtension.php

Commençons par ajouter un champ “defaultAddress” dans le formulaire d’inscription.


//<?php 
declare(strict_types=1); 
namespace App\Form\Extension; 
use Sylius\Bundle\CoreBundle\Form\Type\Customer\CustomerRegistrationType; 
use Sylius\Bundle\ShopBundle\Form\Type\AddressType; 
use Symfony\Component\Form\AbstractTypeExtension; 
use Symfony\Component\Form\FormBuilderInterface; 
final class CustomerRegistrationTypeExtension extends AbstractTypeExtension 

{ 
 public function buildForm(FormBuilderInterface $builder, array $options): void 
{  $builder 
 ->add('defaultAddress', AddressType::class, [
               'label' => 'sylius.form.address',
           ])
       ;
   }
   public static function getExtendedTypes(): iterable
   {
       return [CustomerRegistrationType::class];
   }
}

Ajouter un hook dans le formulaire d’inscription dans sylius_shop.yaml

Les champs ne seront pas ajoutés automatiquement au formulaire.

Dans Sylius v1, on aurait surchargé le template register.html pour y ajouter tous les champs :

{{ form_row(form.defaultAddress.company) }} , {{ form_row(form.defaultAddress.street) }}

Mais dans Sylius v2, chaque champ se retrouve dans un template séparé. Sans doute pour personnaliser les détails qui nous intéressent.

Dans le hook sylius_shop.account.register.content.form, nous allons ajouter un nouveau template default_address.html.twig que nous allons créer.


sylius_twig_hooks:
    hooks:
        # Add address in register
        'sylius_shop.account.register.content.form':
            default_address:
                template: 'form/register/default_address.html.twig'
                priority: 50

Créer le template templates/form/register/default_address.html.twig

Dans ce template, nous allons :

  • Mettre une div et un titre pour la présentation.
  • Appeler le hook address en lui donnant 2 préfixes :
    • Le préfixe sylius_shop.shared.form, pour afficher des ensembles d’éléments fonctionnels destinés à être réutilisés. Ici, les champs d’un formulaire d’adresse.
    • Le préfixe du hook courant, pour pouvoir le personnaliser au besoin (ajouter de nouveaux éléments ou retirer des éléments standards, dans ce contexte précis).
  • Fournir l’objet form à utiliser. Ici, la partie defaultAddress que l’on a ajoutée au formulaire d’inscription.

{% set prefixes = hookable_metadata.prefixes|merge(['sylius_shop.shared.form']) %}
<div class="mb-5">
    <h2 class="h4 mb-4">{{ 'sylius.ui.address'|trans }}</h2>
</div>
{% hook 'address' with { _prefixes: prefixes, 'form': hookable_metadata.context.form.defaultAddress } %}

De cette manière, on a ajouté facilement les champs d’adresse lors du formulaire d’inscription.

 


 

Dans ce tutoriel, nous avons vu comment étendre un formulaire shared. Cela permet d’éviter de réécrire du code inutilement, et de le rendre plus facilement maintenable. Nous l’avons fait avec le formulaire d’adresse, mais il en existe aussi pour les méthodes de paiement (principalement utilisé dans le tunnel d’achat). Des hooks shared existent aussi pour les grilles de listing, les cartes produit, les pages de commandes ou les pages d’erreurs. Pour le front-office comme le back-office.

En suivant cette logique, il est donc possible de les utiliser pour tous types de templates à réutiliser et personnaliser.

 

Sur le même thème, découvrez nos autres articles
GIF