Conserver ses modifications

[roland_d_alsace]

Re : Conserver ses modifications

Je vais donc m'en tenir à l'option consistant à refaire les modifs si elle sont écrasées par la MAJ. Elles sont en nombre limité.
Merci

Dans tous les cas fait une copie du template et utilises cette copie en prod, c'est bien plus sur pour tes modifs.

Voici comment je ferais :

1. Tu dupliques ton template de base (beez2 en beez2_ref)
2. Tu dupliques une 2ème fois ton template de base, 2ème copie que tu nommes "montemplate" par ex et qui sera le template par défaut de ton site.
   Tu y fais tes modifications et les encadrant bien de commentaires (p.e. "mes modifs" + tes initiales + date) afin de les retrouver rapidement sur une recherche du "mes modifs" dans le dossier "montemplate".

Après chaque upgrade de joomla tu fais un winmerge (ou autre utilitaire de ce genre) entre les dossiers ton template de base et sa duplique qui a servi de référence pour tes modifs (donc entre beez2 et beez2_ref).

Tu verras alors tout de suite s'il y a eu des correctifs lors de la maj de joomla (portés donc dans beez2 et pas dans sa sauvegarde beez2_ref), modifs qu'il te suffira alors de porter dans le template modifié dossier "montemplate" (en faisant un winmerge entre beez2 et montemplate).

Il faut alors encore refaire une duplique du template beez2 en beez2_ref pour avoir la nouvelle référence de base pour la prochaine maj de joomla.

Ainsi, même si tu "rates" un contrôle et une correction lors d'une maj de Joomla, vu que tu as toujours ton template de référence (beez2_ref) , tu pourras les récupérer (dans montemplate) lors d'une maj de joomla suivante, sans pertes et sans problèmes.

[PhilJ]

Re : Conserver ses modifications

Bonjour,

J'ai modifié les css et le php dans le template de base Beez 3 style Red et le résultat me convient.

A la prochaine mise à jour ces modifs vont être écrasées.

Je pourrais faire des copies et réaliser mon template perso qui lui ne sera pas écrasé MAIS qui ne sera pas mis à jour (et que je ne saurais pas mettre à jour, parce que je ne saurais pas comment faire, ce qui n'est pas bon).

En résumé : afin d'éviter l'écrasement des modifications lors d'une mise à jour logicielle, il est en effet possible de travailler sur une copie du template. C'est parfois même la meilleure solution, spécialement lorsque la structure du template est modifiée (par exemple : ajout d'une nouvelle position au template). Toutefois, dans la majorité des cas, si le template est déjà riche en fonctionnalités, ce n'est nullement une obligation.

Plus précisément, comme il a été dit, il faut bien distinguer les deux problématiques : modifications CSS et modifications PHP.

____________________

Mais même concernant les fichiers PHP, il faut distinguer à nouveau : les « bases » du code, et les « vues ».
—
Les vues contrôlent l'affichage, le rendu final (HTML) des (ou dans les) pages du site.

Elles sont modifiables sans grand risque dans les sous-dossiers situés dans /templates/nom-du-template/html/.

Lorsque la vue existe nativement à cet endroit, par exemple pour un composant tel que com_content, qui gère les articles et les catégories d'articles Joomla, le template d'origine est alors altéré, mais dans une proportion moindre que lorsqu'une modification est appliquée dans sa structure profonde (ce qui serait le cas par exemple si on modifiait /templates/nom-du-template/index.php et /templates/nom-du-template/templateDetails.xml).

Beez3 est d'origine livré avec un petit nombre de « vues Beez3 ».

Voilà par exemple le dossier où se trouve la vue 'Articles' PHP Beez3 d'origine :

|_beez3
——|_html
————|_com_content
——————|_article : fichier default.php

Pour modifier le rendu des articles Joomla avec le template Beez3, il suffit donc d'altérer ce seul fichier default.php.

Avant toute modification de ce fichier, étant donné qu'il appartient au template Beez3 d'origine, il est bien sûr vivement recommandé d'en faire préalablement une copie — que vous conserverez sur votre ordinateur, au cas où.

Le cas est différent lorsque la vue n'existe pas nativement dans le template. Cependant, le principe est exactement le même : il est facile de la créer, toujours dans un sous-dossier de /templates/nom-du-template/html. Cette nouvelle vue est, elle aussi, une surcharge (anglais override) : soit une surcharge d'un composant ou d'un module Joomla, soit une surcharge d'une extension tierce.

Par exemple, pour modifier le rendu du module mod_login natif sans modifier Joomla, il suffit de créer un dossier /templates/nom-du-template/html/mod_login, puis d'y placer une copie exacte du fichier d'origine /modules/mod_login/tmpl/default.php. On modifie alors sans aucun risque la nouvelle vue, c'est-à-dire le fichier /templates/nom-du-template/html/mod_login/default.php (documentation officielle, en anglais : https://docs.joomla.org/How_to_overr...e_Joomla!_core).

On peut facilement, de cette même façon, altérer l'affichage de presque tous les composants, modules, et même plugins (plugins sous réserve qu'ils possèdent d'origine un fichier .../tmpl/default.php), et cela sans aucun risque d'écrasement lors d'une mise à jour, du moment que les modifications se font dans un sous-dossier html/... du template.


____________________

Concernant maintenant les apparences : couleurs, taille des caractères, dimensions, etc., c'est principalement l'affaire du stylage, donc des directives CSS.

Là aussi, on aura sûrement à cœur de prévenir tout écrasement intempestif dû à une mise à jour (de Joomla ou du template lui-même).

Il faut bien reconnaître qu'ici il y a deux écoles : celle de ceux qui préconisent de toujours travailler sur une copie du template, et celle de ceux qui préfèrent continuer d'utiliser le template d'origine, mais en lui ajoutant une feuille de style complémentaire jouant le rôle de surcharge.

Personnellement, sauf cas particulier où la structure du template est modifiée, je suis enclin à utiliser la seconde méthode, et cela pour deux raisons : en premier lieu, une mise à jour du template peut s'appliquer pratiquement sans risque (même si bien sûr, par précaution, une sauvegarde préalable est tout de même conseillée), mais surtout, en second lieu, cette feuille de style permet de centraliser très simplement toutes les modifications apportées au site, c.-à-d. non seulement les modifications de style apportées au template lui-même, mais aussi toutes celles que l'on souhaite appliquer aux extensions tierces installées.

Reste que ce fichier de style ajouté, souvent nommé custom.css, doit évidemment être chargé par le site pour pouvoir jouer son rôle.

3 possibilités pour cela :
—

1. Modifier le template... mais c'est exclu, puisque le but est justement de ne pas le modifier.
2. Utiliser le template : certains templates permettent d'indiquer qu'un fichier de surcharge est à ajouter à la liste des fichiers à charger pour afficher le site. Il suffit alors d'en préciser le nom dans la configuration du template.
3. Utiliser un petit plugin qui se chargera d'injecter à la volée le code d'appel au fichier CSS dans la zone <head> du template.

Pour les méthodes 2 et 3, le fichier (traditionnellement appelé custom.css, mais ce n'est pas une obligation) sera inséré dans le dossier /templates/nom-du-template/css.

Pour la 3^e méthode : vous trouverez facilement de tels plugins sur le JED.

Cependant, certains d'entre eux injectent le code d'appel, quelque chose du genre <link rel="stylesheet" href="/templates/nom-du-template/css/custom.css" type="text/css" /> au petit bonheur la chance... et la chance est rarement du côté attendu.

En effet, étant donné que fichier doit jouer le rôle d'une surcharge, il est vraiment préférable qu'il soit chargé en dernier dans le code, donc le plus près possible de la balise fermante </head>, de sorte que les directives qu'il contient prévaudront toujours sur les directives des autres fichiers CSS chargés plus haut dans la zone <head>...</head>.

En voici deux qui remplissent bien cette condition : http://lomart.fr/telecharger.html, de l'ami Lomart ici présent, ou bien http://www.openpotion.com/website-de...oomla/#plugins. A souligner : le premier permet aussi des surcharges CSS dans l'administration.


Cordialement,



PhilJ