Ca pourrait aussi être pertinent de le scinder en 2 :
- la liste des plugin-dist
- les autres
Voire, encore plus pertinent :
- la liste des plugins du core non utilisés
- les autres (qu'ils soient dans dist ou non)
Author: cedric@yterium.com
Date: 2013-11-27 14:40:10 +0100 (mer, 27 nov 2013)
New Revision: 21012Log:
le header qui donne la liste des plugins est de plus en plus souvent
incomplet car tronqué à 900 caractères.
On en met une version complète dans local/config.txt (sauf si la globale
spip_header_silencieux specifie qu'on en veut pas)Pour le moment on ne touche pas au header, mais sans doute pourrait-on le
diminuer la longueur maxi et referencer le chemin vers ce fichier si il
dépasse la longueur maxi, ça eviterait de trimbaler 1ko pour rien à chaque
hit.Ca pourrait aussi être pertinent de le scinder en 2 :
- la liste des plugin-dist
- les autres
Voire, encore plus pertinent :
- la liste des plugins du core non utilisés
- les autres (qu'ils soient dans dist ou non)
Et un peu sur le même sujet des plugins, pourrait-on créer une globale qui
liste les objets (oui on a déjà $GLOBALS['tables_principales'] et
$GLOBALS['tables_auxiliaires']) installés par chaque plugin ?
Exemple :
$GLOBALS['tables']['prefixe_plugin']['spip_objet']['fields']
ça permettrait de retrouver nos petits plus facilement...
Ybbet.
Quelle utilité ?
Tout ce qui nous intéresse c’est de savoir quels sont les plugins actifs pour aider au debug des utilisateurs.
Dans ce but, savoir que le plugin est dans un dossier ou dans un autre, ou savoir qu’un plugin n’est pas actif n’a aucune espèce d’intérêt amha.
Cédric
Hello,
moui, on s’écarte quand même pas mal du sujet du commit…
1/ Les globale ça pollue, on ne devrait jamais en utiliser. Les 2 globales que tu cites sont là pour des raisons de compat historique, mais elles ont plutot vocation à disparaitre qu’autre chose, on va pas en créer une nouvelle
2/ d’un point de vue fonctionnel, seul nous importe qu’un objet éditorial existe, pas de savoir quel plugin l’implémente. Que ce soit le plugin A ou le plugin B ne change rien à son existence et à son fonctionnement. Qui plus est, ce peut être le plugin A + le plugin B. Tu le ranges où ?
De quels petits parle-tu, justement ?…
Cédric
Hello,
Et un peu sur le même sujet des plugins,
moui, on s’écarte quand même pas mal du sujet du commit…
^^
pourrait-on créer une globale qui liste les objets (oui on a déjà
$GLOBALS['tables_principales'] et $GLOBALS['tables_auxiliaires']) installés
par chaque plugin ?
Exemple :$GLOBALS['tables']['prefixe_plugin']['spip_objet']['fields’]
1/ Les globale ça pollue, on ne devrait jamais en utiliser. Les 2 globales
que tu cites sont là pour des raisons de compat historique, mais elles ont
plutot vocation à disparaitre qu’autre chose, on va pas en créer une
nouvelle
Ok.
J'ai pensé à une globale pour ne pas avoir à créer une table pour cela ou
même une meta.
Pour la table, ça risque d'allourdir la BDD. Drupal, de ce que j'ai
compris, crée une table de ce genre listant chaque table créée et les
champs de ces tables.
Pour la meta, ce n'est pas très lisible humainement. Mais surtout que pour
s'y insérer, il faut faire un unserialize, puis insérer notre donnée dans
le tableau et serialize pour le remettre dans la meta.
Un peu fastidieux.
2/ d’un point de vue fonctionnel, seul nous importe qu’un objet éditorial
existe, pas de savoir quel plugin l’implémente. Que ce soit le plugin A ou
le plugin B ne change rien à son existence et à son fonctionnement. Qui
plus est, ce peut être le plugin A + le plugin B. Tu le ranges où ?
D'un point de vue fonctionnel, ça permet de savoir quel est le plugin qui a
installé la table. Je ne parle pas des plugins qui ajoutent un/des champ(s)
à une table (exemple: compositions)
Il arrive à des développeurs de reprendre un site existant avec une foison
de tables et de plugins. La relation nom_de_table/prefixe_plugin n'est pas
toujours aisée à retracer.
Cette globale (ou tout autre solution plausible) facilitera la trace.
De plus, l'idée de la globale permet une insertion plus facile sans se
soucier de ce qu'il y a avant ou après.
Cela serait étonnant de trouver 2 plugins qui installent la même table et
ayant le même préfixe. Aurais-tu un exemple dans le cas contraire ?
ça permettrait de retrouver nos petits plus facilement…
De quels petits parle-tu, justement ?…
cf. plus haut.
Ybbet
Alors si on cherche à répondre à ce besoin, quelle utilité de peupler une globale et de consommer des ressources matérielles cpu, mémoire à chaque hit d’une page du site ? On a besoin de l’information une fois de temps en temps, pour un développeur qui a accès au code…
La première solution simple c’est grep
grep -r “spip_matablejesaispasquoi” plugins/*
La deuxième solution serait éventuellement de renseigner ces informations dans un fichier texte dans le dossier tmp/, mais cela suppose de construire un mécanisme de déclaration pour cela.
La troisième solution, c’est d’ajouter un commentaire SQL dans la declaration de la table quelque part (sur le nom de champ de la clé primaire par exemple ?), mais pas sur que ce soit supporté dans tous les gestionnaires SQL.
Cédric