L'actualité de Contao

Chaque année, l'équipe de développement du Core de Contao se réunit deux fois pour un sprint de trois jours. Comme il y a actuellement quatre développeurs suisses, la réunion a lieu uà proximité de Zurich. Les réunions sont soutenues par l’Association Contao et sont très importantes pour nous. Devenez membre et soutenez-nous aussi!

J'ai décidé de rassembler les informations les plus importantes après chaque réunion et de les partager avec l'ensemble de la communauté. Cette fois, les sujets suivants nous ont été abordés :

Ecosystème

Comme toujours, lorsque nous nous rencontrons, nous ne parlons pas seulement de Contao en tant que logiciel, mais également de son écosystème.

Anglais

Une décision importante que nous avons prise est de vouloir nous consacrer davantage à la langue anglaise. Des séries de blogs populaires telles que ce résumé des réunions de développeurs ainsi que la revue bimensuelle de Contao seront donc également publiées en anglais.

Un nouveau dépôt «contao/conflicts»

Un nouveau dépôt nommé «contao/conflicts» fait son entrée dans l'univers de Contao. Pour les utilisateurs de Contao Manager, celui-ci sera automatiquement chargé en arrière-plan à partir de la prochaine version. Tous les utilisateurs qui souhaitent travailler sans le gestionnaire en ligne de commande peuvent installer le paquet tel que documenté sur GitHub.

Contexte : Contrairement aux versions précédentes de Contao, l’administrateur de pages ne gère plus simplement Contao mais une application Symfony. Contao lui-même est une dépendance de cette application comme une autre. Cela présente l’immense avantage de pouvoir réutiliser des bibliothèques, mais nous souffrons en même temps du fait que nous ne contrôlons pas toutes les versions de nos dépendances publiées. Récemment, nous avons eu quelques problèmes avec par exemple doctrine/dbal car leurs versions posaient problème et pouvaient détruire une mise à jour régulière d’un correctif de bug de Contao. Ainsi, lorsque vous exécutiez une mise à jour, Contao lui-même était correct, mais comme vous mettiez également à jour doctrine/dbal (peut-être même sans le savoir car il s’agit d’une dépendance), cela causait des problèmes. Nous devions ensuite demander aux utilisateurs de saisir les "conflits" correspondants dans leur composer.json, afin que ces paquetages ne soient pas installés. Avec l'introduction d'un paquet central de «contao/conflicts», nous avons maintenant la possibilité d'intervenir dans le processus de résolution de dépendance en gérant ces conflits nous-mêmes. Idéalement, la grande majorité des utilisateurs ne remarquent même plus de tels problèmes.

Documentation

D’aussi loin que je m’en souvienne, la documentation était un sujet permanent dans l'environnement de Contao. Tout le monde veut la lire mais personne ne veut l'écrire. C’est différent cette année cependant, puisque lors de la dernière assemblée générale de l’Association Contao, les membres ont voté en faveur du soutien financier au développement d’une documentation. C'est pourquoi nous avons invité Fritz et Bjarke à se joindre à nous pour notre réunion. Avec Jim et votre humble serviteur, nous travaillons intensément à la création d'un cadre de documentation basé sur Hugo et commençons à écrire du contenu. Nous voulons remercier Fritz et Bjarke d’avoir pris le temps de nous rendre visite à Zurich ! Le plan actuel comprend un manuel d'utilisation en anglais et en allemand. Outre le manuel d'utilisation, une documentation destinée aux développeurs, rédigée exclusivement en anglais, est en cours. Les premiers résultats sont prometteurs ! La documentation pour les développeurs est déjà à un niveau que nous n’imaginions pas avant notre réunion. L’objectif est d’ouvrir la documentation au Contao Camp à Munich en mai afin que nous puissions commencer à accepter les contributions de la communauté. Pour le moment, nous ne sommes pas encore prêts, car il manque encore des chapitres importants sur la rédaction de la documentation et la contribution.

À ce stade, je voudrais ajouter deux commentaires personnels :

1. Les fonds en question sont relativement bas et supposer que la documentation s’écrira soudainement sans aucune aide serait utopique, pour le moins qu'on puisse dire. Les fonds existent mais la majorité du contenu doit encore être fournie par la communauté. Nous sommes un projet mené par la communauté et nous le resterons.
2. Depuis 12 ans, la documentation est un sujet omniprésent lors de conférences, de camps, etc. Je pense que c'est enfin une excellente occasion de mettre fin à ces discussions. Nous avons enfin une équipe de personnes motivées qui sont assurées d'être à l'affût des autres militants. Donc, si quelqu'un vous demande de l'aide, vous savez quoi faire, n'est-ce pas ? L’équipe centrale est également consciente de l’importance de la documentation pour le projet et jouera son rôle dans le futur.

Autoupdates

Sur la base des contributions de la communauté, nous avons de nouveau discuté de la faisabilité des mises à jour automatiques. Cependant, le sujet a été traité assez rapidement car aucun membre de l'équipe ne considère que les mises à jour automatiques s'avèrent avantageuses. Les pièges potentiels et nos problèmes de sécurité sont tout simplement trop importants. Grâce à Composer (et éventuellement à Contao Manager), les efforts de mise à jour ont déjà été considérablement réduits.

Authentification à deux facteurs pour le front

Dave a traité l'authentification à deux facteurs pour le front tout au long de la réunion. La difficulté ici semble être la grande flexibilité de Contao qui nous permet de placer des modules de connexion sur des pages arbitraires. Un bon mélange entre les modules et éventuellement les types de page doit être évalué et constitue donc un beau défi. De plus, des mesures préparatoires, telles que des demandes de transfert vers des offres groupées vers des tiers, devaient d'abord être définies, de sorte qu'une intégration à Contao puisse même être envisagée. Il a présenté une première version juste avant la fin de la réunion, qui présentait quelques aspérités mais qui semblait globalement très prometteuse et qui fonctionnait parfaitement !

En d’autres termes, tôt ou tard 2FA deviendra un fait pour le Front Office Contao!

Génération différée de vignettes

Les vignettes dans Contao ont toujours été générées lors du premier appel de page. Cela a pour inconvénient majeur du fait que si le cache d’image n’est pas encore construit, le temps de chargement de la page risque d’être très ralenti. Ceci est très déplaisant pour visiteur ou un moteur de recherche. Dans le pire des cas, la requête se termine même par un délai d'attente, de sorte que l'utilisateur reçoive la fameuse «page blanche» en réponse. Cela est devenu particulièrement habituel dans le gestionnaire de fichiers dans le back office lorsque l'utilisateur ouvre un répertoire contenant trop d'images.

L'introduction de la prise en charge des images sensibles a également entraîné une dégradation des performances, en particulier dans le front.

Au cours des derniers 18 mois, nous avons travaillé sur un concept permettant de résoudre ce problème. Martin a maintenant pris cette tâche en main et cela semble effectivement fonctionner ! Pendant la demande, l'image n'est pas générée, mais seule son hachage est calculé. Elle est ensuite stockée dans un cache avec les paramètres de redimensionnement de l'image. Si l'image n'existe pas encore dans assets/images, le serveur redirigera automatiquement la demande à Contao où nous pourrons extraire le hachage, récupérer les paramètres de redimensionnement respectifs dans le cache et générer l'image maintenant seulement. Le redimensionnement des images ne se produit alors plus dans la demande de page initiale, mais plutôt lors de la demande de l'image. Cela semble être une tâche plutôt simple, mais il y a beaucoup plus à considérer, comme les mécanismes de verrouillage, car il est possible que deux clients demandent la même image en même temps et bien plus encore.

Mais dans l’ensemble, la mise en œuvre a déjà progressé à un point où je suis assez confiant pour dire que vous pouvez presque certainement vous attendre à une augmentation maximale des performances dans Contao 4.8!

Concept entièrement nouveau pour les points d'entrée et l'aperçu front office

Notre version actuelle de Contao Managed Edition fournit deux points d’entrée: app.php et app_dev.php. L’environnement de production s’exécute ensuite, par exemple. https://www.domain.de/page.html et pour entrer en mode débogage, vous appelez https://www.domain.de/app_dev.php/page.html. Cette situation n’est pas satisfaisante pour les raisons suivantes :

• Pour entrer en mode débogage, pour des raisons de sécurité, vous devez d'abord créer un mot de passe via la ligne de commande ou via Contao Manager puis taper manuellement app_dev.php dans la barre d'adresse. C'est un peu trop complexe.

• Le problème est que en raison du cache reverse proxy, https://www.domain.com/page.html est peut-être déjà mis en cache. Mais lors de la prévisualisation frontale et du mode débogage, nous ne devrions pas obtenir la réponse du cache, sans quoi nous ne pourrions jamais obtenir le contenu souhaité. Imaginez maintenant que vous n’utilisez pas le proxy inverse PHP fourni, mais un serveur externe, comme par exemple. Varnish : Ce proxy n'a aucun moyen de savoir si un utilisateur est actuellement connecté car il ne s'exécute pas dans la même application. La solution actuelle pour contourner ce problème est techniquement extrêmement compliquée, car avant chaque demande réelle, une demande supplémentaire est envoyée. On demande à l'application si un utilisateur est actuellement connecté et si le cache est contourné (pour les développeurs : nous le faisons à l'aide de l'en-tête header-replay-bundle). En théorie, tout proxy inverse pourrait envoyer une telle demande supplémentaire, nous proposons donc une solution générale. Mais c'est trop compliqué, ce qui signifie que nous devons nous débarrasser de l'en-tête header-replay-bundle, ce qui signifie que nous avons besoin d'une autre solution pour nos points d'entrée et que nous ne pouvons plus supporter la mise en page mobile dans sa forme actuelle.

Andy et moi avons un concept en tête depuis un moment et commençons maintenant à le mettre en oeuvre. L'idée est qu'une fois implémenté, nous aurons quelque chose comme ceci:

• Nous aurons maintenant un index.php et un preview.php. Chaque requête sur preview.php ne sera jamais mise en cache. Dans notre exemple, nous accèderions ainsi à l’aperçu du front-end via https://www.domain.de/preview.php/page.html. Bien entendu, tout cela se produit automatiquement lorsque vous cliquez sur le bouton d'aperçu.

• L’index.php verifie si la requête contient un Cookie ou un header Authorization et, dans ce cas, contourne complètement le cache du reverse proxy. Pour les mandataires externes tels que Varnish, cela signifie une simplification importante de la configuration. Aucune demande supplémentaire. Pour Contao, cela signifie que nous nous débarrassons de la header-replay-bundle et nous passons ainsi de grande complexité et divers obstacles lors du débogage.

• Le mode débogage peut être activé par un simple clic dans le back office. Si Contao ne fonctionne pas correctement, il doit toujours pouvoir être activé dans Contao Manager. L'implémentation implique l'utilisation d'un jeton Web JSON.

• La présentation de page mobile a déjà été déplacée vers un ensemble distinct (probablement appelé contao/mobile-page-layout-bundle) qui supprime la fonctionnalité du noyau de Contao 4.8. Il peut être réactivé en installant le kit pour ceux qui dépendent encore de cette fonctionnalité. Cependant, une fois que cet ensemble est installé et qu'une page de mobile est affectée à une page, tous les paramètres de cache de page sont ignorés et le cache est désactivé de manière implicite.

Paramètres de routage dans la page racine

Dans Contao 4.7, Andy a porté notre propre logique de routage sur le routeur Symfony CMF. C’était une demande très forte, mais nous n’avons pas encore obtenu d’avantages réels, à l’exception peut-être de gains de performances (nous n’avons pas de critères de référence concrets) et d’une redirection automatique vers https:// si la case correspondante est cochée dans les paramètres de page. Il est temps de changer ça ! À l'avenir, il n'y aura probablement plus de configuration de paramètre prepend_locale car les paramètres suivants se retrouveront probablement dans les paramètres de la page racine et pourront donc être gérés par domaine au lieu de la configuration complète uniquement :

• Utiliser des URL de dossier
• Ajouter le code de langue à l'URL
• suffixe d'URL
• Ne pas rediriger les URL vides

Ici aussi, nous avons pu avoir un aperçu des premiers résultats d’Andy et cela a semblé bien fonctionner !

L'échec fait partie du process

L'échec fait partie du processus Il est également important de mentionner que nous ne nous contentons pas de nous rencontrer, de nous asseoir et de construire quelque chose de grand. Parfois, nous échouons et je voulais introduire une nouvelle section dans cette série de posts pour relater également les échecs:

• Leo, qui est normalement très occupé à examiner et à merger les pull requests des autres développeurs, a réussi à travailler sur une fonctionnalité : il a de nouveau essayé de nous permettre d'écrire nos DCA en YAML. Malheureusement, cela semble être une histoire sans fin, surtout à cause des références aux superglobales. Donc, malheureusement, il n'y a pas de solution en vue pour le moment.

• Martin a essayé d’apporter la fonctionnalité glisser-déposer à notre arborescence. Malheureusement, cela semble également être très difficile à réaliser, notamment à cause des autorisations. Les pages ne peuvent pas simplement être déplacées dans une autre page. Les autorisations ne seront vérifiées qu'après la soumission et comme si cela n'était pas assez difficile, il y a tous les button_callbacks dans lesquels les développeurs peuvent faire des choses arbitraires, etc.

Fin du roman :-)

Cette fois je suis extrêmement euphorique ! La liste des fonctionnalités est très longue et vraiment géniale ! À ce jour, nous ne savons pas quelles fonctionnalités figureront dans Contao 4.8 et s'ils le seront comme décrit dans ce billet de blog, mais j'aimerais vraiment avoir Contao 4.8 aujourd'hui! Eh bien, il est dit qu'il est sain d'avoir quelque chose à espérer, n'est-ce pas? :-)

La prochaine réunion des développeurs devrait avoir lieu en août 2019.

Mais avant cela, nous nous reverrons au Contao Camp les 18 et 19 mai à Munich!

– Yanick