Bug ?? plugins site.css

rockyhorror · avril 2014

Bonjour,

Il y à quelque chose que je ne comprend pas dans la gestion des fichiers css des plugins.

On peut dans la gestion des plugins, modifier les css des plugins. Les fichiers qui sont chargés lorsque l'on edite le code css du plugin sont "plugins/monplugin/css/site.css" et "plugins/monplugin/css/admin.css".
Cependant lorsque l'on enregistre les modifications, elles sont écrites dans les fichier "plugins/site.css" et "plugins/admin.css".
De plus la fonction plxShow->pluginsCss, utilise les fichiers "plugins/site.css" et "plugins/admin.css".

Est-ce que cela ne devrait pas etre les fichiers "plugins/monplugin/css/site.css" et "plugins/monplugin/css/admin.css" qui devrait etre modifiés, et appelés ensuite par pluginsCss ?

Le problème qui se pose, est que si je ne personnalise pas le code css de mon plugin (ou que je ne fait pas au moins un save) le code css de mon plugin n'est pas chargé par pluginsCSS (fichier plugins/site.css), donc j'ai besoin de l'ajouter avec un appel à ThemeEndHead dans mon plugin (fichier plugins/monplugin/css/site.css).
Mais du coup, si je modifie le code css du plugin ou que je fait un save, je me retrouve avec les deux fichiers chargés, "plugins/site.css" et "plugins/monplugin/css/site.css", dont l'un contient les modifications et pas l'autre.

Il y à un truc ?

danielsan · avril 2014

c'est vrai que je me mélange aussi les pinceaux ... et tu n'es pas encore allé dans data/confi/plugins pour voir s'il n'y avait pas d'autres fichiers CSS ..?

Stéphane · avril 2014

Bonjour

Voilà comment ça fonctionne

Soit les fichiers css

/plugins/monplugin1/css/site.css
/plugins/monplugin1/css/admin.css
/plugins/monplugin2/css/site.css
/plugins/monplugin2/css/admin.css
etc...

Dans l'admin sur l'écran "Code Css" pour "monplugin1" c'est le contenu des fichiers /plugins/monplugin1/css/site.css et /plugins/monplugin1/css/admin.css
qui est affiché.

Dès que tu modifies le code css sur cet écran, c'est sauvegardé dans les fichiers /data/configuration/plugins/monplugin1.site.css et /data/configuration/plugins/monplugin1.admin.css

Si tu reviens sur l'écran "Code Css" c'est maintenant le contenu des fichiers /data/configuration/plugins/monplugin1.site.css et /data/configuration/plugins/monplugin1.admin.css qui est affiché car tu as personnalisé le contenu css initial du plugin définit par son concepteur. Ce n'est plus celui de /plugins/monplugin1/css/site.css et /plugins/monplugin1/css/admin.css qui est affiché.

Maintenant pour éviter de devoir afficher tous les fichiers css des Plugins (s'ils existent), PluXml regroupe le contenu de
/data/configuration/plugins/monplugin1.site.css
/data/configuration/plugins/monplugin1.admin.css
/data/configuration/plugins/monplugin2.site.css
/data/configuration/plugins/monplugin2.admin.css

dans respectivement un seul fichier (une sorte de cache) dans
/plugins/site.css
/plugins/admin.css

La fonction pluginsCss() utilise et affiche le code css de ces 2 fichiers stockés dans /plugins.

De plus le contenu est minimisé pour réduire la taille des 2 fichiers et donc accélérer le temps de chargement et d'affichage.

Lors de la conception du plugin pour tes tests, quand tu modifies les fichiers
/plugins/monplugin1/css/site.css
/plugins/monplugin1/css/admin.css
assure toi de supprimer les fichiers
/data/configuration/plugins/monplugin1.site.css
/data/configuration/plugins/monplugin1.admin.css
va sur l'écran "Code css" de ton plugin et clic sur "Enregistrer" pour régénérer le cache (/plugins/site.css et /plugins/admin.css)
Tu verras alors les modifs coté visiteurs ou administration

danielsan · avril 2014

okayyyyy. Je comprends mieux maintenant !
Merci pour cette explication.

j'adore cette partie :

Stéphane a écrit:

car tu as personnalisé le contenu css initial du plugin définit par son concepteur.

ça fait penser à Tron

Et sinon y a-t-il un moyen pour ne pas appliquer les éditeurs WYSIWYW aux textarea des CSS ?

Stéphane · avril 2014

danielsan a écrit:

Et sinon y a-t-il un moyen pour ne pas appliquer les éditeurs WYSIWYW aux textarea des CSS ?

Au plugin de gérer quand et où il doit être utilisé (donc à celui qui conçoit le plugin)

rockyhorror · avril 2014

OK, mais comment on fait quand l'utilisateur n'a pas de vélléité à modifier le code CSS du plugin, ou qu'il ne fait pas au moins une fois un save sur l'écran "Code CSS".
Parce que dans ce cas, le css du plugin n'est pas chargé.

Est-ce qu'il faut que je m'arrange pour le faire au moment de l'activation du plugin ? ou est-ce qu'il faut que je vérifie la présence du fichier "/data/configuration/plugins/monplugin.site.css" dans la fonction ThemeEndHead pour savoir si je dois inclure ou non le fichier css.

danielsan · avril 2014

Stéphane a écrit:

Au plugin de gérer quand et où il doit être utilisé (donc à celui qui conçoit le plugin)

me reste donc à trouver le mec qui a pondu CKEditor pour lui taper dessus alors

danielsan · avril 2014

rockyhorror a écrit:

OK, mais comment on fait quand l'utilisateur n'a pas de vélléité à modifier le code CSS du plugin, ou qu'il ne fait pas au moins une fois un save sur l'écran "Code CSS".
Parce que dans ce cas, le css du plugin n'est pas chargé.

s'il a cliqué sur save sans rien faire il chargera la même chose.

rien ne t'empêche de faire une CSS fixe (chargée dans themeEnd) pour la composition et une de "decorum" personnalisable chargée via pluginCSS ...

Stéphane · avril 2014

@rockyhorror: fait les initialisations nécessaires au fonction du plugin dans la methode OnActivate de ton plugin

@danielsan: si tu trouves celui qui a fait le plugin CkEditor, passe lui le bonjour de ma part

Francis · avril 2014

DanielSan, c'est Stéphane qui a fait le plugin CkEditor ! :P

danielsan · avril 2014

Francis a écrit:

DanielSan, c'est Stéphane qui a fait le plugin CkEditor ! :P

je sais c'est marqué dans le panneau de config ...

:P

Gari · février 2015

Bonjour,

je reviens sur le sujet initial (gestion du cache css). Je réponds dans ce fil du fait de la forte adhérence avec mes propres desiderata, au lieu de créer un nouveau fil dans "Discussions".

J'ai exactement la même remarque que rockyhorror :

rockyhorror a écrit:

OK, mais comment on fait quand l'utilisateur n'a pas de vélléité à modifier le code CSS du plugin, ou qu'il ne fait pas au moins une fois un save sur l'écran "Code CSS".
Parce que dans ce cas, le css du plugin n'est pas chargé.

Est-ce qu'il faut que je m'arrange pour le faire au moment de l'activation du plugin ? ou est-ce qu'il faut que je vérifie la présence du fichier "/data/configuration/plugins/monplugin.site.css" dans la fonction ThemeEndHead pour savoir si je dois inclure ou non le fichier css.

Bien entendu, on peut effectivement faire des initialisations dans le OnActivate ou, comme le propose rockyhorror, dans le hook ThemeEndHead ou encore, et ça me parait encore plus pertinent, dans le hook plxShowPluginsCss pour site.css et AdminTopEndHead pour admin.css.
Cependant, étant donné que toute une structure de gestion de css est mise en place (autour des fichiers bien spécifiques plugins/monplugin/css/site.css et admin.css), je trouverais ça assez logique que ces fichiers soient chargés automatiquement par le moteur de pluXml. Après tout, si je créé ces fichiers, c'est bien que j'ai envie qu'ils soient intégralement pris en charge, et pas juste pour la gestion du cache (qui est, au passage, une super idée

).

Je propose donc, pour gérer le site.css, d'ajouter le code suivant dans plxShow::pluginsCss(), juste après le "eval" :

		// On insère le css "site.css" des plugins si un fichier de cache n'existe pas pour eux
		foreach($this->plxMotor->plxPlugins->aPlugins as $plugName => $plugInstance)
		{
			$filename = PLX_ROOT.PLX_CONFIG_PATH.'plugins/'.$plugName.'.site.css';
			if(!is_file($filename)) 
			{
				$filename = PLX_PLUGINS.$plugName.'/css/site.css';
				if(is_file($filename)) 
					echo '<link rel="stylesheet" type="text/css" href="'.$filename.'" media="screen" />'."\n";
			}
		}

Je propose de la même manière d'ajouter, pour le admin.css, le code suivant dans core/admin/top.php (juste avant le file_exists):

	// On insère le css "admin.css" des plugins si un fichier de cache n'existe pas pour eux
	foreach($plxAdmin->plxPlugins->aPlugins as $plugName => $plugInstance)
	{
		$filename = PLX_ROOT.PLX_CONFIG_PATH.'plugins/'.$plugName.'.admin.css';
		if(!is_file($filename)) 
		{
			$filename = PLX_PLUGINS.$plugName.'/css/admin.css';
			if(is_file($filename)) 
				echo '<link rel="stylesheet" type="text/css" href="'.$filename.'" media="screen" />'."\n";
		}
	}

J'ai essayé ce code chez moi et, sauf loupé de ma part, ça marche.

Etant donné la quasi égalité des deux codes, on devrait même pouvoir créer une méthode de classe (plx::Utils ?) pour les appeler, avec en paramètre "site" ou "admin". Comme je n'ai pas trop d'idée sur l'endroit où mettre cette méthode, je préfère en rester à ma proposition ci-dessus.

L'inconvénient de devoir boucler sur les plugins pour rechercher les fichiers n'est que bénin, dans le sens où les plugins doivent de toute façon faire peu ou prou le même travail de leur côté et user des hooks pour ce faire. De plus, mettre cette mécanique en place motiverait certainement les développeurs de plugin à l'utiliser (je n'ai pas l'impression que ce soit très utilisé actuellement, je peux me tromper bien sûr, n'ayant pas fait un audit des plugins !...).

Gari

Edit1:retrait d'une ligne de code inutile qui s'était incrustée...

Stéphane · février 2015

Bonjour Gari

Ta solution est intéressante, mais ne me convient pas pour les raisons suivantes
- on perd l’intérêt du cache s'il faut parcourir la liste de tous les plugins... le but est de charger que ce qui existe.
- la boucle de lecture est à optimiser en ne prenant que les plugins actifs, ce qui évitera de faire des IO disque inutilement pour tester la présence des .css

Je n'ai pas de meilleure solution à proposer pour le moment et peut-être qu’après réflexion ta solution (après quelques réglages) est à appliquer.
Faut que ça mûrisse pour peser le pour et le contre de cette solution.
Il faudrait étudier si ce n'est pas plutôt coté admin qu'il faudrait améliorer la gestion des .css, notamment à l'activation du plugin.
Pour le moment le foreach en testant si le plugin est actif avant de faire la suite des traitements (test à rajouter) est pas mal comme idée.

Gzyg · février 2015

Je m'excuse de m'incruster dans ce débat de développeurs mais en tant qu'intégrateur (j'ai déjà posé la question) je ne conçois pas l'intérêt de CSS propres aux plugins.
Les plugins ne sont pas des pages web en soi. S'ils doivent afficher quelque chose à l'écran, la feuille de style centrale de PluXml (customisée ou non) a déjà défini un style pour chaque balise (à moins que les plugins n'utilisent des balises exotiques, ce que je n'ai pas encore rencontré).

Perso je les désactive systématiquement.

Il serait plus intéressant (point de vue intégration) d'avoir une liste des dites balises avec des classes css associées qui pourraient (par exemple) prendre le nom du plugin de façon à être identifiées plus facilement si besoin de styles spécifiques.

Exemple : <div class="plxMyContact"> plutôt que <div id="form_contact">

Ainsi, s'il y a besoin d'une personnalisation du formulaire de contact, les déclarations .plxMyContact form, .plxMycontact label, etc, y pourvoieront sans qu'il y ait besoin d'examiner le code du plugin.

Et puis ça allègerait d'autant les plugins. (joke)

à plus,

Gzyg

Gari · février 2015

Je suis d'accord avec Jormun sur le côté plug&play désactivable par l'intégrateur.

Cela dit, pour aller dans le sens de Gzyg, il me semble intéressant effectivement de bien "baliser" les ajouts de plugins. C'est ce que je suis d'ailleurs en train de revoir sur mon plugin plxCalendrier.
En gros, j'essaie de mettre des "conteneurs" bien balisés. Par exemple, pour ma page d'administration du plugin, qui est tout de même un peu spécifique par rapport au style classique de pluXml, j'ai tout balancé dans un <div class="plxCalendrierAdmin">, de manière à ce qu'il soit aisé ensuite de faire joujou avec le css de ce qui se trouve dans ce conteneur. Je fais de même avec les styles côtés site (avec des objets ayant des classes de type "plxCalendrierMonth", "plxCalendrierBig", etc.). L'idée est également d'éviter les conflits avec d'autres plugins (c'est si facile de créer des classes "info", "erreur", "actif" qu'on peut aisément imaginer que de nombreux plugins embarquent des css utilisant les mêmes noms de classe).

Bref, je pense qu'avec un peu de méthode, on doit pouvoir arriver à concilier les deux points de vue.

Existe-t-il un "guide des bonnes pratiques" à l'usage des développeurs de plugin, en ce qui concerne les css ? Si ce n'est pas le cas, ça pourrait valoir le coup d'en discuter...

Pour revenir sur ma demande initiale, je découvre que mon code prend également les plugins inactifs. Chouette, j'apprends des choses ^^ Je vais mettre le nez dans le cambouis pour ajouter le test d'activation du plugin. Il est vrai que je n'avais pas testé mon code avec des plugins inactifs possédant des css site.css et admin.css.
Par contre, Stéphane, quand tu pointes du doigt que "on perd l’intérêt du cache s'il faut parcourir la liste de tous les plugins... le but est de charger que ce qui existe.", il me semble tout de même que la quasi-totalité des plugins (actifs ^^) font déjà du chargement de css (dans ThemeEndHead par exemple), et s'ils veulent utiliser admin.css et site.css, ils sont obligés de faire le même travail de vérification de la présence du fichier de cache (et s'ils ne font pas ce travail, il y a risque fort de conflit avec le cache). Bref, on alourdit peut-être le code de pluXml, mais on gagne en allégement ET cohérence des plugins.

Gari · février 2015

En attendant l'éventuelle prise en compte des css automatiquement dans pluXml, ou un changement plus drastique de politique de gestion des css, voici ce que j'ai rajouté dans mon plugin et qui peut être utilisé dans tous les plugins (en n'oubliant pas de déclarer les deux hooks dans le constructeur) :

[== PHP ==]
	public function plxShowPluginsCss()	{$this->LoadCss("site");}
	public function AdminTopEndHead()	{$this->LoadCss("admin");}

	// On affiche le css demandé (site ou admin) seulement s'il n'existe pas de css modifié par l'utilisateur
	// et présent en cache 
	// @param : $type= ("admin"|"site")
	public function LoadCss($type)
	{
		$filename = PLX_ROOT.PLX_CONFIG_PATH.'plugins/'.$this->plug["name"].'.'.$type.'.css';
		if(!is_file($filename)) 
		{
			$filename = PLX_PLUGINS.$this->plug["name"].'/css/'.$type.'.css';
			if(is_file($filename)) 
				echo '<link rel="stylesheet" type="text/css" href="'.$filename.'" media="screen" />'."\n";
		}
	}

Stéphane · février 2015

Gari a écrit:

Pour revenir sur ma demande initiale, je découvre que mon code prend également les plugins inactifs. Chouette, j'apprends des choses ^^ Je vais mettre le nez dans le cambouis pour ajouter le test d'activation du plugin. Il est vrai que je n'avais pas testé mon code avec des plugins inactifs possédant des css site.css et admin.css.
Par contre, Stéphane, quand tu pointes du doigt que "on perd l’intérêt du cache s'il faut parcourir la liste de tous les plugins... le but est de charger que ce qui existe.", il me semble tout de même que la quasi-totalité des plugins (actifs ^^) font déjà du chargement de css (dans ThemeEndHead par exemple), et s'ils veulent utiliser admin.css et site.css, ils sont obligés de faire le même travail de vérification de la présence du fichier de cache (et s'ils ne font pas ce travail, il y a risque fort de conflit avec le cache). Bref, on alourdit peut-être le code de pluXml, mais on gagne en allégement ET cohérence des plugins.

Les fichiers site.css et admin.css ne contiennent que les css des plugins actifs. le cache est réactualisé quand on active/désactive un plugin ou si on modifie le css d'un plugin via l'interface d'admin.
Refaire une boucle dans plxShow::PluginCss vient faire double emploi avec une tâche qui est déjà faite en amont. C'est en sens que j'argumentais pour voir s'il ne vaut pas mieux travailler au niveau de l'admin et limiter les traitements coté visiteurs. Je conviens que cette boucle c'est pas la mort et c'est pas ça qui va consommer beaucoup de temps, sauf que si à chaque fois on en rajoute un peu... L'esprit de PluXml c'est aussi de grapiller dès qu'on peut pour rester performant

Gari a écrit:

Existe-t-il un "guide des bonnes pratiques" à l'usage des développeurs de plugin, en ce qui concerne les css ? Si ce n'est pas le cas, ça pourrait valoir le coup d'en discuter...

Non.

Gari a écrit:

Cela dit, pour aller dans le sens de Gzyg, il me semble intéressant effectivement de bien "baliser" les ajouts de plugins. C'est ce que je suis d'ailleurs en train de revoir sur mon plugin plxCalendrier.

Pas forcément facile à faire si on intègre des composants tiers développés par quelqu'un d'autres (un slider en jquery par exemple)
Tant que tout le code t'appartient c'est envisageable. Le cas échéant difficile de normaliser

Gzyg · février 2015

Jormun :

Jormun a écrit:

Sans css il faudrait ensuite dans la plupart des cas que l'intégrateur aille ajouter quelques CSS.

Je pense l'inverse. Sans CSS, le plugin s'intègre "naturellement" dans le design pré-établi (il suffit de le tester pour s'en apercevoir) et il n'y a rien à faire.

Du coup, moins de boulot pour le développeur, pour l'intégrateur, pour l'utilisateur et pour la communauté et donc on sauve des arbres et des kilowatt/heures.

Stéphane :

Stéphane a écrit:

Pas forcément facile à faire si on intègre des composants tiers développés par quelqu'un d'autres (un slider en jquery par exemple)

Certes. Mais tant qu'à intégrer des composants tiers, rajouter une classe sur le conteneur du plugin ne devrait pas représenter un gros boulot supplémentaire (enfin, j'imagine...) ?

Après, effectivement pour les sliders, les lightbox-like et autres, il faut de toute façon éditer leur CSS si on souhaite une parfaite intégration (ce qui peut poser souci lors d'une mise à jour).

Avec des plugins pré-stylés, on court le risque de contraster un peu trop franchement avec le design du site, voire de créer des conflits comme l'a souligné Gari, sur des noms de classe trop génériques.

à plus,

Gzyg

Gari · février 2015

Stéphane a écrit:

Le cache est réactualisé quand on active/désactive un plugin ou si on modifie le css d'un plugin via l'interface d'admin. Refaire une boucle dans plxShow::PluginCss vient faire double emploi avec une tâche qui est déjà faite en amont.

Ok je vais me pencher là-dessus. Merci.

Gari · février 2015

Bonjour,

Ha mais n'importe quoi en fait, effectivement. Tout ce que j'ai raconté sur le chargement des css ne sert à rien, je suis même étonné de ne pas m'être plus fait rentrer dedans. Les morceaux de code que je propose ne servent à rien, puisqu'ils ajoutent des chargements de css ayant déjà été ajoutés dans les fichiers de cache admin.css et site.css (je croyais, comme RockyHorror, que seul le fichier css modifié était chargé dans les fichiers de cache, et non les fichiers originaux, et que ce n'était que dans le cas où on modifiait un css dans la page admin).

Et donc, finalement, tout fonctionne parfaitement.

Lors de mes tests, je me suis fait complètement avoir par le fait qu'il faut désactiver et réactiver mon plugin pour qu'il prenne en compte les fichiers admin.css et site.css de mon plugin, or j'ai créé ces fichiers directement sur mon environnement de dev alors que le plugin était déjà activé avant. Résultat, pas de prise en compte... J'ai transféré mon plugin sur un environnement de test pour voir, et bien entendu tout est correctement chargé.

J'ai une nouvelle remarque, que j'espère plus pertinente que la précédente : lorsqu'on modifie un fichier css dans l'interface d'admin, il ne semble pas possible de "revenir" à la version originale du fichier css. Autrement dit, si sans le faire exprès j'efface le contenu du fichier, je perds tout. Seule action corrective possible : se connecter à la main sur l'environnement pour détruire le fichier css modifié. C'est peu "user-friendly", surtout si on ne sait pas quel fichier détruire.
Ne serait-il pas possible, dans l'interface d'admin, de rajouter un petit bouton "Revenir à la version originale du fichier css" ?

Stéphane · février 2015

Gari a écrit:

Bonjour,

Ha mais n'importe quoi en fait, effectivement. Tout ce que j'ai raconté sur le chargement des css ne sert à rien, je suis même étonné de ne pas m'être plus fait rentrer dedans.

C'est pas le genre de la maison :-)

Sinon le fichier css original n'est pas perdu car PluXml travaille sur une copie. Vide la zone "ccs site" ou "css admin", sauvegarde: le contenu du fichier css original réapparaît, mais le fichier en cache est vide (car zone vide sauvegardée). Fait une modif dans le css, sauvegarde: le cache contient maintenant le code modifié.

Bug ?? plugins site.css

Réponses