On a Plugins SPIP, Contrib et Code des plugins, 3 sites qui parlent de plugins et donc des mêmes plugins.
Je trouve qu’il serait intéressant d’avoir un bloc « standard » dans chaque page concernée d’un plugin qui renvoie vers les pages du même plugin sur les autres sites (si elles existent).
Par exemple, sur Contrib, on a un bloc à droite qui affiche la compatibilité et le téléchargement. On pourrait le compléter par le lien vers Plugins SPIP et vers Code des plugins si le PHPDoc est généré pour ce plugin. Idem pour Plugins SPIP.
J’ai pas réfléchi à l’implémentation mais je trouve que ça aurait un intérêt étant donné que nous n’avons pas un « portail » par plugin.
On a Plugins SPIP, Contrib et Code des plugins, 3 sites qui parlent de plugins et donc des mêmes plugins.
Je trouve qu'il serait intéressant d'avoir un bloc "standard" dans chaque page concernée d'un plugin qui renvoie vers les pages du même plugin sur les autres sites (si elles existent).
Par exemple, sur Contrib, on a un bloc à droite qui affiche la compatibilité et le téléchargement. On pourrait le compléter par le lien vers Plugins SPIP et vers Code des plugins si le PHPDoc est généré pour ce plugin. Idem pour Plugins SPIP.
J'ai pas réfléchi à l'implémentation mais je trouve que ça aurait un intérêt étant donné que nous n'avons pas un "portail" par plugin.
Le problème qu'on peut avoir est que parfois un même article documente plusieurs plugins. Par ex lorsqu'on a plusieurs plugins (plusioeurs préfixes) qui fonctionne de concerts mais sont théoriquement indépendant. Ou encore, lorsqu'on a plusieurs versions d'une même librairie diffusée avec plusieurs préfixes.
Concrèrement cela pourrait être un champ extra associé aux articles qui stockent le préfixe, actualisé en même temps que le reste.
On a Plugins SPIP, Contrib et Code des plugins, 3 sites qui parlent de
plugins et donc des mêmes plugins.
Je trouve qu’il serait intéressant d’avoir un bloc « standard » dans
chaque page concernée d’un plugin qui renvoie vers les pages du même
plugin sur les autres sites (si elles existent).
Par exemple, sur Contrib, on a un bloc à droite qui affiche la
compatibilité et le téléchargement. On pourrait le compléter par le lien
vers Plugins SPIP et vers Code des plugins si le PHPDoc est généré pour
ce plugin. Idem pour Plugins SPIP.
Oui mais le but est pas d’avoir un truc parfait vu qu’on a un historique qui est parfois folklorique.
Mais si on a une possibilité de le faire même manuellement ça serait pas mal je pense.
Et pour les articles à problème et bien tant pis.
On a Plugins SPIP, Contrib et Code des plugins, 3 sites qui parlent de
plugins et donc des mêmes plugins.
Je trouve qu'il serait intéressant d'avoir un bloc "standard" dans chaque
page concernée d'un plugin qui renvoie vers les pages du même plugin sur
les autres sites (si elles existent).
+1
Par exemple, sur Contrib, on a un bloc à droite qui affiche la
compatibilité et le téléchargement. On pourrait le compléter par le lien
vers Plugins SPIP et vers Code des plugins si le PHPDoc est généré pour ce
plugin. Idem pour Plugins SPIP.
Oui, d'autant plus que ce lien vers plugins.spip était bien présent sur l'ancienne maquette, mais perdu en fin de contenu de la colonne centrale, sans trop de contexte donc pas forcément clair. Le placer dans la boite que tu proposes permettrait de lui donner une meilleure visibilité.
J'ai pas réfléchi à l'implémentation mais je trouve que ça aurait un
intérêt étant donné que nous n'avons pas un "portail" par plugin.
Pour le lien vers plugins.spip on a déjà l'info en base, le script de synchro colle l'url dans le champ url_site de l'article de doc correspondant cf :
Je pense qu'on peut garder ça en l'état car chaque plugin a bien une page sur plugin.spip (sauf quelques cas exotiques), et utiliser un champ extra pour le lien PHPDoc qui est bien moins souvent utilisé.
Le lundi 11 mars 2019 à 15:32 +0100, Eric Lupinacci a écrit :
Yep,
Oui mais le but est pas d'avoir un truc parfait vu qu'on a un
historique qui est parfois folklorique.
Mais si on a une possibilité de le faire même manuellement ça serait
pas mal je pense.
Et pour les articles à problème et bien tant pis.
++
Eric
bah éventuellement ce week-end je pourrais ajouter ce champ extra à
l'article et à la synchronisation.
La difficulté majeure que je vois pour le moment est le fait
qu'actuellement on synchronise préfix par préfixe, et pas article par
article. Et que je sais pas (mais peut être que ton API json le permet)
si on peut récupérer facilement tous les prefixes dont la doc pointe
vers un article.
Restera alors à le mettre en forme pour produire un lien vers les
sites... ca c'est de l'intégration et c'est pas ce que j'ai envie de
faire ...)
Le lun. 11 mars 2019 à 15:42, Maïeul Rouquette <maieul@maieul.net> a écrit :
Le lundi 11 mars 2019 à 15:32 +0100, Eric Lupinacci a écrit :
bah éventuellement ce week-end je pourrais ajouter ce champ extra à
l’article et à la synchronisation.
La difficulté majeure que je vois pour le moment est le fait
qu’actuellement on synchronise préfix par préfixe, et pas article par
article. Et que je sais pas (mais peut être que ton API json le permet)
si on peut récupérer facilement tous les prefixes dont la doc pointe
vers un article.
Restera alors à le mettre en forme pour produire un lien vers les
sites… ca c’est de l’intégration et c’est pas ce que j’ai envie de
faire …)
Pas besoin de te charger la barque pour l’instant.
On réfléchit un peu à la solution et après on la code.
Sinon b_b a proposé un truc qui me parait pas mal du tout et c’est vrai que le préfixe ne serait pas de trop comme sur Plugins SPIP.
Pour le lien vers plugins.spip on a déjà l'info en base, le script de synchro colle l'url dans le champ url_site de l'article de doc correspondant cf :
Je pense qu'on peut garder ça en l'état car chaque plugin a bien une page sur plugin.spip (sauf quelques cas exotiques), et utiliser un champ extra pour le lien PHPDoc qui est bien moins souvent utilisé.
++
b_b
----
nope, j'ai désactivé la synchronisation de ce champ, car il peut y avoir des articles qui ont plus d'un plugins associés (cf autre fil de discussions). Ca passait tant que le script de synchro était casse-geule, mais depuis qu'il fonctionne de manière régulière, cela faisait des aller retours.
Donc je verrai plutot un champ extra qui associe à un article / à un doc distant un ou plusieurs prefixe.
pour infos, j'ai documenté ce que fait le script de synchro sur contrib.
Pour le lien vers plugins.spip on a déjà l’info en base, le script de
synchro colle l’url dans le champ url_site de l’article de doc
correspondant cf :
Je pense qu’on peut garder ça en l’état car chaque plugin a bien une
page sur plugin.spip (sauf quelques cas exotiques), et utiliser un champ
extra pour le lien PHPDoc qui est bien moins souvent utilisé.
nope, j’ai désactivé la synchronisation de ce champ, car il peut y avoir
des articles qui ont plus d’un plugins associés (cf autre fil de
discussions). Ca passait tant que le script de synchro était
casse-geule, mais depuis qu’il fonctionne de manière régulière, cela
faisait des aller retours.
Je comprends pas bien cette histoire d’article avec plusieurs plugins.
Plusieurs paquets je dis pas mais plusieurs plugins non.
Donc je pense qu’il faut réactiver la synchronisation de ce champ en considérant que si y a plusieurs préfixes on ne fait rien et si y a plusieurs paquets de toute façon c’est la même page sur Plugins SPIP.
Donc on a tout intéret à garder la synchronisation qui doit marcher pour 95% des cas.
Je comprends pas bien cette histoire d'article avec plusieurs plugins.
Plusieurs paquets je dis pas mais plusieurs plugins non.
Donc je pense qu'il faut réactiver la synchronisation de ce champ en
considérant que si y a plusieurs préfixes on ne fait rien et si y a
plusieurs paquets de toute façon c'est la même page sur Plugins SPIP.
Donc on a tout intéret à garder la synchronisation qui doit marcher
pour 95% des cas.
++
Eric
bah j'ai travaillé sur ca ces deux dernières semaines. Et je dis bien
plusieurs plugins (prefixes) pour un même article. C'est pas hyper
fréquent, masi cela arrive.
Par ex
ce sont des cas où on a préféré avoir des prefixes différents pour des
versions différentes de la librairie.
il y aussi les cas où themes et squelettes sont documentés ensembles.
Le problème c'est qu'actuellement je ne peux pas savoir a priori s'il y
a plusieurs prefixes pour un même article. Du coup, si c'est le cas, le
champ passe son temps à changer de valeur (à chaque fois qu'on
synchronise l'un des prefixes concernés).
bah j’ai travaillé sur ca ces deux dernières semaines. Et je dis bien
plusieurs plugins (prefixes) pour un même article. C’est pas hyper
fréquent, masi cela arrive.
Donc c’est pas trop grave.
On peut s’en passer ou le mettre manuellement.
Le problème c’est qu’actuellement je ne peux pas savoir a priori s’il y
a plusieurs prefixes pour un même article. Du coup, si c’est le cas, le
champ passe son temps à changer de valeur (à chaque fois qu’on
synchronise l’un des prefixes concernés).
J’avoue ne pas comprendre l’aspect « synchronisation ».
De mon point vue, si le champ url_site est vide on synchronise, si il est déjà rempli on ne fait rien.
Ca évite justement ton problème de changement de valeur.
De toute façon l’url de Plugins SPIP ne va pas changer et si c’est le cas on a toujours la possibilité de corriger le champ manuellement dans contrib.
Je pense que ça peut fonctionner simplement ainsi et on retrouvera cette information qui me parait quand même importante.
Pour le code des plugins comme le dit b_b un champ extra uniquement manuel suffit amplement pour le moment.
Le lundi 11 mars 2019 à 17:22 +0100, Eric Lupinacci a écrit :
Ok,
Le lun. 11 mars 2019 à 17:03, Maïeul Rouquette <maieul@maieul.net> a
écrit :
> bah j'ai travaillé sur ca ces deux dernières semaines. Et je dis
> bien
> plusieurs plugins (prefixes) pour un même article. C'est pas hyper
> fréquent, masi cela arrive.
>
Donc c'est pas trop grave.
On peut s'en passer ou le mettre manuellement.
> Le problème c'est qu'actuellement je ne peux pas savoir a priori
> s'il y
> a plusieurs prefixes pour un même article. Du coup, si c'est le cas,
> le
> champ passe son temps à changer de valeur (à chaque fois qu'on
> synchronise l'un des prefixes concernés).
>
J'avoue ne pas comprendre l'aspect "synchronisation".
De mon point vue, si le champ url_site est vide on synchronise, si il
est déjà rempli on ne fait rien.
Ca évite justement ton problème de changement de valeur.
De toute façon l'url de Plugins SPIP ne va pas changer et si c'est le
cas on a toujours la possibilité de corriger le champ manuellement
dans contrib.
Je pense que ça peut fonctionner simplement ainsi et on retrouvera
cette information qui me parait quand même importante.
Pour le code des plugins comme le dit b_b un champ extra uniquement
manuel suffit amplement pour le moment.
++
Eric
yep, faut un peu plus de subtilité que ce qu'il y avait avant, qui
remplacait les données. Avec un test préalable, pourquoi pas. Je m'en
occupe dès que possible.
comme ça on peut demander à nicod de prévoir l’affichage correspondant dans le bloc de droite.
Et là pour Contrib c’est plié.
Le lun. 11 mars 2019 à 17:29, Maïeul Rouquette <maieul@maieul.net> a écrit :
Le lundi 11 mars 2019 à 17:22 +0100, Eric Lupinacci a écrit :
Ok,
Le lun. 11 mars 2019 à 17:03, Maïeul Rouquette <maieul@maieul.net> a
écrit :
bah j’ai travaillé sur ca ces deux dernières semaines. Et je dis
bien
plusieurs plugins (prefixes) pour un même article. C’est pas hyper
fréquent, masi cela arrive.
Donc c’est pas trop grave.
On peut s’en passer ou le mettre manuellement.
Le problème c’est qu’actuellement je ne peux pas savoir a priori
s’il y
a plusieurs prefixes pour un même article. Du coup, si c’est le cas,
le
champ passe son temps à changer de valeur (à chaque fois qu’on
synchronise l’un des prefixes concernés).
J’avoue ne pas comprendre l’aspect « synchronisation ».
De mon point vue, si le champ url_site est vide on synchronise, si il
est déjà rempli on ne fait rien.
Ca évite justement ton problème de changement de valeur.
De toute façon l’url de Plugins SPIP ne va pas changer et si c’est le
cas on a toujours la possibilité de corriger le champ manuellement
dans contrib.
Je pense que ça peut fonctionner simplement ainsi et on retrouvera
cette information qui me parait quand même importante.
Pour le code des plugins comme le dit b_b un champ extra uniquement
manuel suffit amplement pour le moment.
++
Eric
yep, faut un peu plus de subtilité que ce qu’il y avait avant, qui
remplacait les données. Avec un test préalable, pourquoi pas. Je m’en
occupe dès que possible.
Ah oui à ce propos.
Si on veut modifier l’url site manuellement aussi il faut changer la configuration du site (contenu).
Pour utiliser un champ extra il faut aussi activer les plugins associés (CE et son interface).