L'intérêt est de garder tous les réglages faits au cours du temps : hook des modules (sans avoir à reconfigurer ceux par défaut dans left ou right column...), et de se concentrer sur les modifs du thème pour retrouver un thème enfant "propre" (rappel: j'ai repris le site avec le thème bootstrap copié-collé et modifié dans tous les sens depuis...2015).

Bonjour Pierre,
J'ai une question, à nouveau, sur le thème enfant. J'ai testé de copier le contenu du thème enfant dans le répertoire d'un thème utilisé, modifié le nom_du_thème_utilsé.xml de root/theme pour y inclure la balise <parent> avec default-bootstrap, il est donc vu dans BO préférences thème comme étant enfant de boostrap, mais tout ce qui est inclus, au lieu de se trouver dans le head, se retrouve dans le body. Y-a-t'il une manip' en BDD à faire ?

C'est bien ce que je dis, si elles existent dans le thème enfant (donc celles qui ont été modifiées), alors elles seront lues. Pour celles n'existant pas dans le thème enfant, c'est dans le thème parent qu'elles seraient lues (comme pour les templates du thème). Mais je suppose que ça ne fonctionne pas comme ça

Oui mais si celes qui existent sont présentes, alors il y aura bien une mise à jour sur le thème par défaut, et les traductions existantes resteront, non ?

Certains dossiers comprennent encore des templates (exple blockcart-blockbestsellers-blockcategories...). Mais ce que je voulais souligner ici c'est qu'il faudra savoir où on a fait des modifs, vu que les dossiers s'y trouvent quand même (par exemple, si on ne touche pas aux traductions par défaut des modules, et que ceux-ci ne s'y trouvaient pas, ce serait moins compliqué pour trouver les tpl/css/js des modules modifiés)

Ok, je viens de recréer un thème enfant à partir du thème par défaut. En parcourant les dossiers/sous-dossiers je n'ai plus les templates associés. Par contre, il y a toujours ces dossiers/sous-dossiers que je dois parcourir si je veux savoir si il y a eu modification.

Oui, ça j'ai bien imprimé, ce que je soulève comme point ici c'est le fait qu'il s'y trouve aussi des fichiers concernants les modules, les mails (ça encore, je peux le concevoir)... Donc, pour trouver un tpl modifié d'un module (...) ce n'est plus aussi évident, à moins d'avoir une liste quelque part. Pour les templates principaux (à la racine du thème), c'est évident. Pour les autres non. Du coup, est-ce un comportement normal de Phenix de copier tous les autres fichiers de tous les répertoires du thème ? J'aurais pensé que seuls les répertoires/sous-répertoires contenant des fichiers modifiés s'y trouveraient.

Bonsoir Pierre,
j'ai créé un thème enfant sans cocher quoi que ce soit. J'ai donc bien cette arborescence, mais si je souhaite modifier le template d'un module, il me faut donc le faire dans le thème enfant où se trouve déjà un template. Du coup, je comprends bien que sur les tpl généraux il suffit d'ajouter le template à modifier (et lorsqu'il y a une mise à jour, on vérifie les différences avec le thème par défaut). Seulement, si tous les modules et leurs templates sont déjà présents dans le thème enfant, il faudra aussi vérifier un par un tous les templates de tous les modules... Et je suppose que c'est pareil pour les mails...

oki, cool. Merci !

Bonjour Pierre,
Je viens de rencontrer à nouveau deux erreurs PaypalAPI hier soir (la même cliente) :

Un client a rencontré un problème avec le module PayPalAPI:
 
PayPal response:
TIMESTAMP -> 2024-11-27T22:01:32Z
L_ERRORCODE0 -> 10730
L_SHORTMESSAGE0 -> Shipping Address Postal Code Empty
L_LONGMESSAGE0 -> The field Shipping Address Postal Code is required
L_SEVERITYCODE0 -> Error

Pourtant, dans les logs Paypal, j'ai bien le code postal d'indiqué.