<customContent /> ou <field type = "editor">
J'ai été intéressé de voir la réponse à cette question qui mentionne le <customContent /> tag.
Je n'avais jamais rencontré cela auparavant, et j'ai du mal à trouver beaucoup d'informations à ce sujet.
- Il ne semble pas être mentionné dans les tutoriels du module de Joomla
- Une recherche dans les fichiers core montre que seulement sera utilisé par mod_custom
Cela semble fonctionner si vous le placez à l'intérieur du <extension> balise d’un module, mais pas dans une autre section telle que <config>. Il crée ensuite un éditeur WYSIWYG au-dessus de tous les autres paramètres du module. Il n'a pas d'étiquette.
Cependant, contrairement à <field type="editor">, cela enregistre les données dans son propre champ content de la table _modules, par opposition à la chaîne JSON de params.
Le fait qu'il ait son propre domaine me laisse penser que c'est peut-être le meilleur moyen d'ajouter un éditeur à un module, mais il semble étrange que ce soit si rarement mentionné.
Joomla a-t-il l'intention d'utiliser cette balise? Est-ce la meilleure pratique?
Eh bien, je viens d'avoir mon premier cas lorsque l'utilisation de l'un ou l'autre semble pertinente.
Dans la base de données, les champs de Joomla pour les champs "params" et "content" des modules sont du type TEXT, ce qui signifie un maximum de 65535 caractères. Si vous essayez de sauver quoi que ce soit au-dessus de cela, la fin sera coupée. <customContent /> enregistre le contenu dans son propre champ ("contenu") et le type de champ de l’éditeur l’enregistre dans le champ "params" du module en tant que partie d’une chaîne json (qui contient également tous les autres champs du module).
Un client vient de réussir à planter son site en collant une image base64 dans le champ de l'éditeur, dont la taille était supérieure à cette limite de caractères.
En utilisant le champ "contenu", cela aurait simplement coupé les derniers caractères et vous auriez une image brisée, que vous auriez besoin d'aller dans l'éditeur et de corriger. Dans le champ "params" de json, cependant, cela signifie que le json enregistré est alors cassé et vous obtenez un message "erreur de décodage JSON" et vous devez vous rendre dans la base de données pour le résoudre. Il ne peut pas être corrigé dans l'admin car le module est maintenant corrompu.
Je ne pense pas qu'il y ait une option maxlength sur le type de champ de l'éditeur, donc ces deux éléments la séparent du point de vue du client, mais le fait de planter le site semble être le pire résultat.
Bien qu’il s’agisse avant tout d’un problème client-inattendu, il semble également être un bogue fondamental de Joomla, car il devrait sûrement vérifier que le json téléchargera en toute sécurité ou ne le téléchargera pas, plutôt que de sauvegarder des données corrompues.
J'ai essayé de faire quelques recherches à ce sujet, car j'étais intéressé de voir à quoi cela servait.
En examinant certaines questions relatives à Github, il a été noté que customContent est valide, mais non documentée.
J'ai alors cependant trouvé ceci:
https://github.com/joomla/schemas/blob/master/xsd/v3/module.xsd#L
Ce sont les attributs et éléments valides autorisés dans un fichier XML de module. Je me demande donc si <customContent /> devrait être utilisé ailleurs que dans le centre.
Ma suggestion serait de rester avec <field type="editor">, car cela garantit que vous utilisez la pratique Joomla standard/par défaut et vous permet également d’utiliser des attributs supplémentaires tels que label, description, etc.