[spip-dev] [Ecriveur] Erreur sur ressourcotheque

2020-05-15 Par sujet salvatore
Erreur : il y a deja un fichier 
salvatore/modules/ressourcotheque--ressourcotheque-6c443/ressourcotheque.commit.json
 avec des commits en attente

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Accès restreint : protection des documents HS

2020-05-15 Par sujet nicod_

Le 09/05/2020 à 17:56, nicod_ a écrit :

Le 08/05/2020 à 19:51, nicod_ a écrit :
Je pense comprendre le principe, mais simplement, est ce que cette 
clause zzzd.objet NOT IN ('rubrique','article','breve','forum') 
pourrait être optionnelle par exemple ?


Bon, j'ai fait une PR dans ce sens :
https://git.spip.net/spip-contrib-extensions/acces_restreint/pulls/1


"Petit up", comme on dit, vu qu'il y a un +1 et qu'on n'a pas de 
notifications...


--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Cloner tout git.spip.net

2020-05-15 Par sujet nicod_

Le 15/05/2020 à 09:38, Cerdic a écrit :
Ah oui le .gitignore j’y ai pensé et puis j’ai oublié parce que chez moi 
je clone à coté (j’ai mis un lien symbolique sur le mirror.php), mais je 
pense que ce serait bien en effet.


Pour info :
https://git.spip.net/spip-contrib-outils/gitea_mirror/pulls/1

(ton README était en iso-8859)

Et oui pour ajouter une ligne dans le readme a propos de checkout.php 
j’avais oublié ça aussi


J'ai pas mis à jour le README mais je propose un test :
https://git.spip.net/spip-contrib-outils/gitea_mirror/pulls/2

--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Cloner tout git.spip.net

2020-05-15 Par sujet nicod_

Le 15/05/2020 à 16:34, RastaPopoulos a écrit :

Juste parce que je suis pas sûr d'avoir tout compris : non gérés par quoi ? Car 
tous ces fichiers sont *à l'extérieur* de chaque dépôt Git non ?

À moins qu'on parle de transformer soi-même l'ensemble immense en un autre 
dépôt Git perso contenant tout ?


Tu as testé gitea_mirror ? tu devrais, tu comprendrais mieux.

Une fois que tu l'as cloné et que tu le lances, il crée un cache et 
télécharge tout par défaut dans son propre répertoire, ce qui crée plein 
de fichiers (toute la zone) qui sont untracked.

Si tu fais un git status, tu t'en rends compte tout de suite.

--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Cloner tout git.spip.net

2020-05-15 Par sujet RastaPopoulos
Le 15/05/2020 à 15:40, nicod_ a écrit :
> Les script crée un dossier cache et un dossier par répos des orgas dans son 
> propre répertoire, donc ça ajoute des fichiers non gérés qu'il vaut mieux 
> ignorer.

Juste parce que je suis pas sûr d'avoir tout compris : non gérés par quoi ? Car 
tous ces fichiers sont *à l'extérieur* de chaque dépôt Git non ?

À moins qu'on parle de transformer soi-même l'ensemble immense en un autre 
dépôt Git perso contenant tout ?

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Meta dans une table spécifique

2020-05-15 Par sujet Eric Lupinacci
Hello,

> Le 15 mai 2020 à 15:10, Eric Lupinacci  a écrit :
> 
> J’essaye de mettre en place une configuration de plugins dans une table 
> différente que spip_meta et je me heurte à quelques incohérences dans les API 
> SPIP.
> ...
> Donc il me semble qu’il y a plusieurs incohérences voire bugs :
> - l’API Config et Meta ne fonctionnent pas de la même façon vis-à-vis d’un 
> table différente de spip_meta
> - l’upgrade fait appel à l’API meta et pas à l’API Config ce qui provoque en 
> partie le problème.
> - l’attribut meta ne semble pas être utilisé correctement lors de 
> l’installation.
> 

Premiers éléments de réponse :

La fonction qui permet d’installer ou de dés installer un plugin est dans la 
plupart des cas spip_plugin_install().
Cette fonction a le code suivant :

function spip_plugin_install($action, $infos, $version_cible) {
   $prefix = $infos['prefix'];
   if (isset($infos['meta']) and (($table = $infos['meta']) !== 'meta')) {
  $nom_meta = "base_version";
   } else {
  $nom_meta = $prefix . "_base_version";
  $table = 'meta';
   }
   switch ($action) {
  case 'test':
 return (isset($GLOBALS[$table])
and isset($GLOBALS[$table][$nom_meta])
and spip_version_compare($GLOBALS[$table][$nom_meta], 
$version_cible, '>='));
 break;
  case 'install':
 if (function_exists($upgrade = $prefix . "_upgrade")) {
$upgrade($nom_meta, $version_cible, $table);
 }
 break;
  case 'uninstall':
 if (function_exists($vider_tables = $prefix . "_vider_tables")) {
$vider_tables($nom_meta, $table);
 }
 break;
   }
}
C’est donc elle qui appelle les fonctions contenues dans 
_administrations.php.
On voit aussi qu’elle examine la paquet du plugin pour savoir si l’attribut « 
meta » a été rempli avec une table autre que meta.
Et donc la chose importante est que le prototype de la fonction upgrade ou 
vider_tables possède toujours un argument $table à la fin qui indique la table 
des metas pour le plugin.
Et cet argument est systématiquement absent de tous nos plugins et cela est 
renforcé par le fait que la Fabrique et Programmer n’en font pas référence.

Donc une bonne pratique serait maintenant de rajouter cet argument dans ces 
fonctions.
Cet argument $table devant être passé à la fonction maj_plugin() ou à 
effacer_meta par exemple.

Après ces modifications, il ne reste plus qu’un seul problème : la table 
spécifique des meta n’existe pas la première fois et comme l’API meta ne la 
crée pas au contraire de l’API config on a une erreur SQL. Je pense que c’est 
sur ce point qu’il faut faire une correction.

++
Eric




___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Cloner tout git.spip.net

2020-05-15 Par sujet nicod_

Le 15/05/2020 à 09:42, Eric Lupinacci a écrit :

Je pige pas.
Le .gitignore de SPIP doit suffire non, pourquoi le copier dans chaque repo 
puisque qu’on devrait pas en avoir besoin ?


Les script crée un dossier cache et un dossier par répos des orgas dans 
son propre répertoire, donc ça ajoute des fichiers non gérés qu'il vaut 
mieux ignorer.


--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Meta dans une table spécifique

2020-05-15 Par sujet Eric Lupinacci
Hello,

J’essaye de mettre en place une configuration de plugins dans une table 
différente que spip_meta et je me heurte à quelques incohérences dans les API 
SPIP.

1) L’API Config.
Les fonctions lire_config(), ecrire_config() et effacer_config() permettent 
aujourd’hui de spécifier la table dans laquelle lire ou écrire une variable de 
configuration.
Il suffit pour ça de rajouter /nom_table_sans_spip/ devant le nom de la 
variable.
Cela fonctionne parfaitement surtout que l’API gère également la création 
automatique de la table voire sa suppression quand cela est nécessaire.

2) L’API Meta et les upgrade de base
C’est là que ça se gâte.
Après avoir créé une meta de configuration dans une table autre que spip_meta 
pour mon plugin, appelons-la spip_mameta, je me suis dis que pour être cohérent 
il serait mieux de mettre la meta standard du plugin préfixe_base_version.

Donc j’ai utilisé la déclaration meta du paquet.xml (attribut de la balise 
paquet) qui est censée indiquer justement que les metas du plugin doivent être 
stockées dans une table donc le nom est celui de l’attribut préfixé par meta.
Donc j’ai ajouté cet attribut dans le paquet.xml, meta=« mameta » et lancé 
l’installation. Résultats des erreurs : 
https://framapic.org/JsNg3KT0MQmw/qceJT2ZbZuzM.png 
 et pourtant un plugin 
installé mais aucune table créée, ni la meta mameta_version_base. Par contre, 
la configuration écrite via l’API Config est bien dans spip_mameta et la meta 
tables_config contient bien cette table.

Néanmoins, il existe dans la fonction maj_plugin() un quatrième argument qui 
permet de passer justement la table meta à utiliser : elle devrait être déduite 
par l’attribut mais pour essayer je saisis donc mameta dans l’appel de 
maj_plugin().
Le résultat semble plus probant mais les écritures dans la table spip_mameta ne 
se font pas car la table n’est pas créée automatiquement si elle n’existe pas 
comme pour l’API  Config.
Donc il me semble qu’il y a plusieurs incohérences voire bugs :
- l’API Config et Meta ne fonctionnent pas de la même façon vis-à-vis d’un 
table différente de spip_meta
- l’upgrade fait appel à l’API meta et pas à l’API Config ce qui provoque en 
partie le problème.
- l’attribut meta ne semble pas être utilisé correctement lors de 
l’installation.

Est-ce que j’utilise mal les API ou confiez-vous les bugs ?
Si bug, il serait bon de les corriger en 3.3.

++
Eric

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Plugins groupes_mots_arborescents et medias_responsive_mod en 404

2020-05-15 Par sujet glopglop
Bonjour à tou·tes,

Tout d'abord, toutes mes excuses si ce n'est pas le bon endroit pour
signaler ce problème.

Je suppose que c'est lié aux erreurs apparues sur le système de
fichiers de git.spip.net la semaine dernière (d'après les mails
lus ici), mais les plugins groupes_mots_arborescents et
medias_responsive_mod sont en erreur 404 sur plugins.spip.net :
- https://plugins.spip.net/gma.html
- https://plugins.spip.net/medias_responsive_mod.html

Je ne suis pas bien familier avec la manière dont sont construites
les pages de plugins.spip.net, mais je me dis que le fait que les
liens vers les releases de ces plugins sur git.spip.net renvoient
aussi des 404 n'y est peut-être pas étranger :
- 
https://git.spip.net/spip-contrib-extensions/groupes_mots_arborescents/src/tag/v1.2.10
- 
https://git.spip.net/spip-contrib-extensions/groupes_mots_arborescents/src/tag/v1.2.11
- 
https://git.spip.net/spip-contrib-extensions/medias_responsive_mod/src/tag/v1.11.6

Bon courage à vous, en tout cas, et merci beaucoup pour le boulot !

++
Glop
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] html5up_hyperspace à vérifier après réparation

2020-05-15 Par sujet jeanmarie

J'ai l'impression que c'est tout bon.

Merci :)

                        jean marie

Le 14/05/2020 à 09:44, Cerdic a écrit :

Hello Jean-Marie,

j’ai donc supprimé et reconstruit le repo de html5up_hyperspace, 
notamment en nettoyant les vieux tags, refaisant la branche v2 et le 
commit+tag de la v3.0.3

Si tu peux vérifier que tout te semble bien ?

https://git.spip.net/spip-contrib-squelettes/html5up_hyperspace

--
Cédric

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Saisies toujours

2020-05-15 Par sujet Maïeul Rouquette

Le 14/05/2020 à 22:46, Stephane Santon a écrit :

Bonjour,

Dans je ne sais plus dans quel exemple de formulaire de configuration, 
il y a


     array( // hors fieldset : avis
     'saisie' => 'oui_non',
     'options' => array(

Et je ne trouve pas le type de saisie 'oui_non' dans les références
https://contrib.spip.net/Reference-des-saisies

...

a oui c'est parce que la saisie oui non est considéré comme obsolète. On 
ne pousse donc plus à l'utiliser, et donc référence de saisies ne la 
liste plus.


Il vaut mieux utiliser une saisie radio avec des labels explicites.

Si tu retrouve l'exemple, on pourra corrigé.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Cloner tout git.spip.net

2020-05-15 Par sujet Eric Lupinacci
Hello,

> Le 15 mai 2020 à 09:38, Cerdic  a écrit :
> 
> Ah oui le .gitignore j’y ai pensé et puis j’ai oublié parce que chez moi je 
> clone à coté (j’ai mis un lien symbolique sur le mirror.php), mais je pense 
> que ce serait bien en effet.
> 

Je pige pas.
Le .gitignore de SPIP doit suffire non, pourquoi le copier dans chaque repo 
puisque qu’on devrait pas en avoir besoin ?

++
Eric


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Cloner tout git.spip.net

2020-05-15 Par sujet Cerdic
Ah oui le .gitignore j’y ai pensé et puis j’ai oublié parce que chez moi je 
clone à coté (j’ai mis un lien symbolique sur le mirror.php), mais je pense que 
ce serait bien en effet.

Et oui pour ajouter une ligne dans le readme a propos de checkout.php j’avais 
oublié ça aussi

Merci à toi !

--
Cédric
Le 14 mai 2020 à 23:16 +0200, nicod_ , a écrit :
> Le 14/05/2020 à 10:27, Cerdic a écrit :
> > Hello,
> >
> > c’est un besoin un peu à la marge mais qui existe :
> > comment avoir une copie de tous les repos de git.spip.net en local pour
> > faire des recherche dans la base de code par exemple ?
> >
> > C’est maintenant possible avec le script mirror.php que vous trouverez là
> > https://git.spip.net/spip-contrib-outils/gitea_mirror
> >
> > Le script veille à ne pas charger le serveur inutilement : les appels à
> > l’API gitea sont mis en cache et seuls les repositories modifiés depuis
> > le dernier appel sont pull à nouveau.
> > Il peut donc être utilisé sans crainte de charger git.spip.net :)
> > (il n’y a que le premier clone complet qui génère vraiment une charge)
>
> Merci, ça marche super bien.
>
> Une suggestion : l'ajout d'un .gitignore pour le cache et les dossiers
> créés pour chaque orga, je sais pas ce que tu en penses.
>
> Sinon, j'avais des erreurs quand j'ai lancé le script, que je n'ai pas
> vues au départ : il m'affichait la liste des 1196 dépots en erreur,
> parce que je n'avais pas checkout.php dans mon PATH.
> Mais avec 1196 lignes d'erreurs affichées je n'avais pas vu les messages
> indiquant que checkout n'était pas trouvé.
>
> Peut être indiquer dans le readme qu'il faut installer checkout ? ou
> bien vérifier qu'il est bien installé ?
>
> --
> nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip