Si vous développez sur Ibexa depuis quelques années, vous avez pris pour habitude de passer des paramètres personnalisés à une vue, vous utilisiez le contrôleur Symfony ibexa_content::viewAction.
Cette époque est révolue. Avec l'arrivée du support des paramètres dans les fonctions Twig natives, le vent tourne. Voici pourquoi vous devrez changer dans vos habitudes dès aujourd'hui.
Le duel : Ancien vs Nouveau
L'ancienne méthode (Symfony Standard)
On passait par une sous-requête Symfony pour injecter nos données :
{# ❌ À éviter désormais pour les rendus simples #}
{{ render(controller('ibexa_content::viewAction', {
'contentId': content.id,
'viewType': 'line',
'params': { 'my_param': 'custom_data' }
})) }}
La nouvelle méthode (Ibexa Native)
On utilise le helper dédié qui gère tout en interne :
{# ✅ La recommandation actuelle #}
{{ ibexa_render(content, {
'viewType': 'line',
'params': { 'my_param': 'custom_data' }
}) }}
Pourquoi privilégier ibexa_render ?
1. Performance : Adieu les sous-requêtes inutiles
La fonction render(controller(...)) de Symfony crée ce qu'on appelle une sous-requête. Le noyau de Symfony doit recréer un cycle de vie complet (Request, Kernel Events, etc.). À l'inverse, ibexa_render avec la méthode par défaut (direct) appelle directement le moteur de rendu. C'est plus léger, plus rapide, et moins gourmand en mémoire.
2. Lisibilité et Intention
En utilisant ibexa_render, vous indiquez clairement que vous rendez un objet du CMS. Le code est plus court et beaucoup plus facile à maintenir pour un nouveau développeur sur le projet.
3. Flexibilité native
Le bloc params de la fonction Twig fait exactement la même chose que celui du contrôleur. Vous ne perdez aucune fonctionnalité, mais vous gagnez en clarté.
Comment mettre à jour vos templates ?
Le passage est indolore. Dans votre template de destination (votre "View Template"), rien ne change. Les variables que vous passez dans le tableau params restent accessibles sous le même nom.
Exemple de transition :
- Identifiez vos appels render(controller(...)).
- Remplacez-les par ibexa_render(content, { ... }) ou ibexa_render_location(location, { ... }).
- Profitez d'un code plus propre.
Nos derniers articles
Nouveautés de Dataflow : stockage des logs en fichier, et nettoyage automatisé de l'historique
Vous en avez marre d'avoir les logs de vos jobs dans la base de données ...
Comment utiliser les paramètres avec ibexa_render et ibexa_render_location
Si vous développez sur Ibexa depuis quelques années, vous avez pris pour habitude de passer ...
Reprise de la maintenance du provider Apple pour PHP League OAuth2 Client
Code Rhapsodie reprend la maintenance du package oauth2-apple de Patrick Bussmann. Ce fork garantit la ...
Nouvelle fonctionnalité de suggestion de mots-clés au connecteur Gemini pour Ibexa
La suggestion de mots-clés de Taxonomy est disponible dans Ibexa DXP avec le pack de ...
Diviser un fichier SQL volumineux en petits fichiers pour un import facilité
L'importation d'un fichier SQL de très grande taille peut s'avérer problématique, entraînant parfois la saturation ...
Sylius vs Shopware : Quelle architecture choisir pour votre futur e-commerce ?
Sylius et Shopware sont deux outils (framework) permettant la réalisation d'un site e-commerce. Comment choisir ...
Ibexa annonce la sortie d'une nouvelle version LTS avec les contributions de Code Rhapsodie
Ibexa a publié un avis de sécurité le 10 décembre 2025 et sortie dans la ...
Connecteur Mistral pour les actions IA d'Ibexa
Connaissez-vous les Actions IA (AI Actions) d'Ibexa ? Les AI Actions, sont une solution extensible ...
Le nom des zones du Page Builder d'Ibexa DXP est-il adapté aux contributeurs ?
L'adéquation des noms attribués aux différentes zones dans le Page Builder d'Ibexa DXP est-elle optimale ...
