[Problème] surcharge article dans joomla4

[herve]

Bonjour
Bon je commence a avoir un site qui fonctionne à peu près sous joomla 4 après plusieurs bugs liés à Helix Ultimate
Il tournait parfaitement sous joomla 3 et je n'ai pas fait d'autres modifications.
Sur joomla 4, je vois un certain nombre de messages d'erreurs. Certains sont lié à un plugin (je verrai avec le dev), d'autres sur joomla

Notice: Undefined offset: 2 in /home/.../templates/shaper_helixultimate/html/com_content/article/clibre.php on line 110 Notice: Trying to get property 'value' of non-object in /home/../templates/shaper_helixultimate/html/com_content/article/clibre.php on line 110 

Helix Ultimate a introduit une nouvelle façons spécifique de faire une override/
https://www.joomshaper.com/documenta...views-override

Suite à une correction d'erreur, un dev d'helix ma laissé le fichier clibre.php dans l'emplacement conventionnel de surcharge de joomla 4.
/templates/shaper_helixultimate/html/com_content/article/
Cela tombe bien car je n'ai pas besoin d'apprendre cette nouvelle méthode spécifique mentionnée (peut-être abandonnée; je ne vois pas l'intérêt car je renomme le fichier)

Pour Joomla4, il faut que je récupère le fichier default.php comme pour joomla3 et que je mette mon code ?
Ensuite quel est l'appel pour afficher un champ ?
Je mettais sous joomla 3:

<?php echo $this->item->jcfields[2]->value; // type d'information ?>

[herve]

Bonjour
tjs pas résolu ce problème. Si quelqu'un a une idée ou des ressources sur la surcharge d'article avec joomla 4 ?
@+

[herve]

Salut
Tjs à la recherche d'une méthode fiable (surcharge article) avec la nouvelle version joomla 4 (surtout avec Helix) car je vois passé des infos contradictoires
Je ne sais pas si j'ai bine compris ce que disais un dev de joomshapper si c'était une bonne pratique de renommer le fichier de surcharge selon la méthode joomla !

[dolmenhir]

Salut,
La méthode d'overrides présentée par Joomshaper pour le framework Helix Ultimate me semble pourtant assez claire.

Le fichier default.php que tu copies depuis Helix

plugins/system/helixultimate/overrides/com_content/article

ou la version originale depuis

components/com_content/views/article/tmpl

doit être collé dans le dossier

templates/shaper_helixultimate/overrides/com_content/article

et garder son nom "default.php"

Si tu le renommes, l'override ne fonctionnera pas.

[herve]

Bonjour
merci pour ton retour :-) j'avais compris cela et c'était clair avant, si ce n'est que j'ai eu plusieurs problèmes de migration j3->j4 avec helix ultimate et notamment les surcharges.
Nos échanges en mauvais anglais ont rendu plus confus ma compréhension.

A priori cela fonctionne aussi correctement sur un site j4 + helix ultimage avec le nom spécifique du fichier surchargé php que je sélectionne dans "mise en page" de l'onglet paramètre de mon élément de menu. S'il n'y a pas un avantage déterminant je resterai homogène avec la méthode standard et son nom de fichier spécifique de surcharge !

Pour changer d'avis, est-il possible de m'expliquer l'avantage "important" de leur méthode non standard vs méthode standard joomla . ??

Par rapport à j3, contrairement à mes erreurs, j'ai l'impression que les appels des custom fields ont toujours la même syntaxe !?

[dolmenhir]

A priori cela fonctionne aussi correctement sur un site j4 + helix ultimage avec le nom spécifique du fichier surchargé php que je sélectionne dans "mise en page" de l'onglet paramètre de mon élément de menu.

Effectivement, si tu renommes le fichier, tu peux alors l'utiliser de cette manière.
Cela permet de ne pas toucher à tous les articles mais uniquement ceux ciblés de cette manière.

Pour changer d'avis, est-il possible de m'expliquer l'avantage "important" de leur méthode non standard vs méthode standard joomla . ??

La version non standard est déjà un override de la version originale (à voir en détail les différences apportées).
Donc soit tu modifies la version Helix (non standard), normalement bâtie dans l'esprit du framework Helix Ultimate et de ses apports, soit tu modifies la version native, celle utilisée par défaut avec Casiopae, et sans ces apports propres au framework.
bref, l'avantage est, je pense, principalement de ce côté là, à savoir conserver certains réglages inhérent au framework qui ne se trouvent pas dans le fichier de la version native (standard).

Par rapport à j3, contrairement à mes erreurs, j'ai l'impression que les appels des custom fields ont toujours la même syntaxe !?

Je n'ai pas encore fait ce genre de manip avec J!4
Il est probable que oui mais je préfère laisser quelqu'un qui a déjà fait ça te le confirmer.
Peut-être Marc, woluweb qui semble avoir une certaine appétence pour les custom fields...