Re: [spip-dev] [fontawesome5] mise à jour du plugin picto à la version fontawesome (...)

2020-09-26 Par sujet JLuc

Je complète car j'ai pas été au bout.

J'ai l'impression qu'avec ces polices, ou avec bootstrap peut être, et d'autres sûrement, la notion de "nouvelle version 
principale" est un peu différente de cette même notion quand il s'agit d'un plugin fonctionnel.


Les saisies en sont à leur version x=3 mais elles font toujours la même chose, de même que les crayons qui en sont à 
leur version 2.
Pour ces plugins fonctionnels, "mettre à jour", c'est bénéficier d'un fonctionnement amélioré et de nouvelles 
fonctionnalités, mais le service rendu est le même pour ce que existe déjà,

et d'ailleurs, je n'ai pas souvenir davoir rencontré des incompatibilités 
significatives lors des upgrades.
Bien sur il pourrait y avoir des incompatibilité si j'ai bidouillé un peu trop 
profondément l'usage
mais pas vraiment en général, du moins si je suis resté dans un usage banal.

Alors qu'avec bootstrap ou ces polices, ce sont des versions très différentes,


Et surtout : ces différentes versions en "x" ne traduisent pas absolument un 
"progrès".
Car la version 3 des saisies est "mieux" que la 2,
et donc on peut supposer qu'il faudra "nécessairement" y passer un jour ou 
l'autre,
alors qu'avec bootstrap ou ces polices, on peut supposer qu'on veuille 
durablement rester dessus,
en juste corrigeant les problèmes ou en intégrant les améliorations.

Chacune des nouvelles versions de ces plugins est un peu comme un fork du 
précédent,
qui ne l'invalide pas.


un peu comme si c'était des plugins différents.

Disais-je donc.

Car en effet il semble que SVP ne prend pas très bien cette éventualité
et que pour faire avec, il est plus simple d'en faire des plugins différents.
JL

___
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] [fontawesome5] mise à jour du plugin picto à la version fontawesome (...)

2020-09-26 Par sujet JLuc

Le 26/09/2020 à 12:54, Eric Lupinacci a écrit :

RastaPopoulos a écrit le 26/09/2020 à 12:05 :
> Si on a un problème ergonomique avec SVP quand il gère et prévient les 
gens des mises à jour : c'est ça qu'il faudrait corriger absolument, pas faire un 
préfixe par version majeur de plugin, non ?
(PS : c'est la même chose avec le plugin foundation)


J'ai l'impression qu'avec ces polices, ou avec bootstrap peut être, et d'autres sûrement, la notion de "nouvelle version 
principale" est un peu différente de cette même notion quand il s'agit d'un plugin fonctionnel.


Les saisies en sont à leur version x=3 mais elles font toujours la même chose, de même que les crayons qui en sont à 
leur version 2.
Pour ces plugins fonctionnels, "mettre à jour", c'est bénéficier d'un fonctionnement amélioré et de nouvelles 
fonctionnalités, mais le service rendu est le même pour ce que existe déjà,

et d'ailleurs, je n'ai pas souvenir davoir rencontré des incompatibilités 
significatives lors des upgrades.
Bien sur il pourrait y avoir des incompatibilité si j'ai bidouillé un peu trop 
profondément l'usage
mais pas vraiment en général, du moins si je suis resté dans un usage banal.

Alors qu'avec bootstrap ou ces polices, ce sont des versions très différentes,
un peu comme si c'était des plugins différents.

JL

___
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] Citer les branches

2020-09-24 Par sujet JLuc

Le 24/09/2020 à 16:02, Matthieu Marcillaud a écrit :

Le 24/09/2020 à 13:41, JLuc a écrit :

serait il possible de citer la branche sur laquelle se fait le commit
dans le mail de notification ?

J’ai corrigé en ce sens (à vérifier) (hors master).

Super, bravo :-)


Par contre je n’ai manifestement pas réussi à enlever le  qui remplace 
les -- .

C'est Spip-typo qui remplace -- par  ?
Mais pourquoi dans les notifs de commits ?

JL

___
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] Citer les branches

2020-09-24 Par sujet JLuc

Mystère : sur la liste des commits on voit passer des commits en double.

C'est parce que la branche est différente !

Alors serait il possible de citer la branche sur laquelle se fait le commit
dans le mail de notification ?

Du moins quand c'est pas 'master'.
Surtout que le nom est parfois sémantique
ou fait référence à un n° de ticket qui cause aussi.

JL

___
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] SPIP 3.3 et Compositions

2020-09-17 Par sujet JLuc

> Le 17/09/2020 à 17:53, Cerdic a écrit :
>> C’est là >> https://git.spip.net/spip/spip/commit/9ef4c078fae4ccef00782a3901b340fe9888d2d3Le 17/09/2020 à 19:24, et 
Bruno Bergot a écrit Et aussi un peu par ici si je ne me trompe pas :)> 
https://git.spip.net/spip/spip/commit/da298555d81f323361ca320fb8d3c97307390742

Ça le fait effectivement ici pour les icones et les puces,
mais http_img_pack n'est pas appelé dans le code précité de composition
qui ne contient qu'un pur 

Par contre je crois avoir trouvé : ya le même code dans find_in_theme
qui lui est bien appelé par chemin_image :
https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/utils.php#L1427

OK
JLuc

___
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] SPIP 3.3 et Compositions

2020-09-17 Par sujet JLuc

Le 17/09/2020 à 17:34, Bruno Bergot a écrit :

Point de sorcellerie, juste de la magie :)
https://git.spip.net/spip/spip/commit/b572418d55c7cad0d9e1542a9f7f18e8ff7db25e


Hihi non je ne crois pas que cette ligne spoile le "truc"
car elle teste si le fichier existe, auquel cas ça le renvoie,
et donc ok ça permet à #CHEMIN_IMAGE de renvoyer un SVG reçu en paramètre...
mais dans le code de composition corrigé, #CHEMIN_IMAGE reçoit un PNG en 
argument

et renvoie un SVG
c'est bien ça ?
Alors c'est autre chose. Ça pourrait être dans
https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/icone_renommer.php
qui fait de la magie aussi, mais je vois pas où car nulle par ça ne favorise un 
svg
et le fichier n'a pas changé dans la branche "icones_svg"
...

JL



___
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] SPIP 3.3 et Compositions

2020-09-17 Par sujet JLuc

Le 17/09/2020 à 13:34, Bruno Bergot a écrit :
Ça vient de l'introduction de la version svg du cadenas par 
	
Il doit suffire de spécifier la taille de l'image dans 
https://git.spip.net/spip-contrib-extensions/compositions/src/branch/master/formulaires/editer_composition_objet.html#L22

C'est corrigé cf 
https://git.spip.net/spip-contrib-extensions/compositions/commit/1f0f6f5b944c76bd04bff3528aa7a81b5eb9bd6b


Pour info, par quelle sorcellerie est-ce que 
va chercher prive/themes/spip/images/cadenas-xx.svg ?

JL

___
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] Fancybox pour une mise a jour de la mediabox ?

2020-09-15 Par sujet JLuc

Le 11/09/2020 à 13:42, nicod_ a écrit :
Non, je pense que la mention en question est pour éviter à l'auteur de voir des chacals empaqueter la lib dans un 
plugin WP (au hasard) et de vendre le plugin en question.
Je pense qu'il n' a pas de problème pour l'inclure dans SPIP, 
mais quand on vend un site SPIP à un client, il me semble 
qu'on est redevable de la licence dans ce cas.


Ça semble être une possibilité.
Est-ce que c'est rédhibitoire ?

Il décrit aussi :
Q : Can I use fancybox in product sold for multiple clients (for example, in 
theme sold on Themeforest)?
A : By purchasing ONE "Extended Commercial license", you are allowed to include fancybox in ONE product (for example: 
premium theme, plugin or template) for sale. Customers and users of your product do not need to purchase their own 
license — as long as they are not developing their own commercial products with fancybox.


Ça laisse donc ouvert la possibilité que quelqu'un ou quelque chose achète la licence 
"extended" pour un plugin spip
et que cela concéderait le droit de distribuer ce plugin (de manière payante et 
sans doute aussi de manière gratuite).


Mais le plus simple amha est de contacter l'auteur pour lui poser la question.

Effectivement, en précisant la question que je me pose.
Quelqu'un l'a contacté ?


Je veux bien le contacter mais quelle est la question à poser au juste ?


JLuc

___
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] Données Exif des images réduites

2020-09-07 Par sujet JLuc

J'ai fait ticket (https://core.spip.net/issues/4546)
mais ne vais pas creuser car j'ai pu contourner en utilisant des css
(https://www.educative.io/edpresso/how-to-crop-an-image-in-css).

JLuc



Le 06/09/2020 à 02:38, JLuc a écrit :

Le 04/09/2020 à 17:37, JLuc a écrit :

Le 04/09/2020 à 13:02, Cerdic a écrit :
Je pense que pour image_reduire ça dépend aussi de la méthode que tu as choisi dans ecrire/ pour la création des 
vignettes.

Certaines méthodes probablement perdent aussi les données.

J'ai essayé GD2 et CONVERT avec les mêmes résultats.


OUPS NON les caches des proxies m'avaient joué un tour.
En testant avec de nouveaux documents je vois que  image_reduire perd les EXIF 
de rotation avec GD2
mais que CONVERT les préserve (c'est la librairie que j'utilisais initialement).

Il faudrait parvenir à généraliser les bonnes pratiques de CONVERT avec 
image_reduire.

Mais ensuite, pour tous les filtres qui transforment les images (donc modifient son  contenu au delà d’une simple 
mise à l’échelle, donc y compris recadrent) il y a en effet création d’une nouvelle image via GD2 et aucun processus 
de recopie des exif de la source vers la destination.


J'ignore la mécanique de spip pour ces traitements, mais je vois que les différentes images réduites bénéficient bien 
de la rotation EXIF de l'image initiale, alors que celle qui passe par image_recadre ou image_proportions (qui appelle 
image_recadre) n'en dispose plus.

N'y a t il pas création d'une nouvelle image dans les 2 cas ?


Oui mais il y a plusieurs manières possibles de créer une nouvelle image.
Par exemple la fonction _image_creer_vignette dans le cas GD2 utilise 
ImageCopyResampled
et sinon utilise ImageCopyResized.
On ne semble pas passer par là pour image_reduire mais ce serait une piste !

Je vois aussi qu'une bonne part du code garde les stigmates trompeurs d'une histoire où gd était la principale ou seule 
librairie :

- la fonction appelée "_image_gd_output" est en fait appelée par d'autres 
méthodes que gd (yc convert)
- "_image_valeurs_trans" est utilisée par toutes les méthodes (yc convert) alors qu'un commentaire indique que c'est 
réservé à GD2  (https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres_images_lib_mini.php#L105)


Au passage je découvre que var_mode=images permet de refaire les calculs 
d'images.
Yeah bonne pioche !
À documenter dans https://www.spip.net/fr_article4453.html ?

JLuc




___
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] Données Exif des images réduites

2020-09-05 Par sujet JLuc

Le 04/09/2020 à 17:37, JLuc a écrit :

Le 04/09/2020 à 13:02, Cerdic a écrit :
Je pense que pour image_reduire ça dépend aussi de la méthode que tu as choisi dans ecrire/ pour la création des 
vignettes.

Certaines méthodes probablement perdent aussi les données.

J'ai essayé GD2 et CONVERT avec les mêmes résultats.


OUPS NON les caches des proxies m'avaient joué un tour.
En testant avec de nouveaux documents je vois que  image_reduire perd les EXIF 
de rotation avec GD2
mais que CONVERT les préserve (c'est la librairie que j'utilisais initialement).

Il faudrait parvenir à généraliser les bonnes pratiques de CONVERT avec 
image_reduire.

Mais ensuite, pour tous les filtres qui transforment les images (donc modifient son  contenu au delà d’une simple mise 
à l’échelle, donc y compris recadrent) il y a en effet création d’une nouvelle image via GD2 et aucun processus de 
recopie des exif de la source vers la destination.


J'ignore la mécanique de spip pour ces traitements, mais je vois que les différentes images réduites bénéficient bien de 
la rotation EXIF de l'image initiale, alors que celle qui passe par image_recadre ou image_proportions (qui appelle 
image_recadre) n'en dispose plus.

N'y a t il pas création d'une nouvelle image dans les 2 cas ?


Oui mais il y a plusieurs manières possibles de créer une nouvelle image.
Par exemple la fonction _image_creer_vignette dans le cas GD2 utilise 
ImageCopyResampled
et sinon utilise ImageCopyResized.
On ne semble pas passer par là pour image_reduire mais ce serait une piste !

Je vois aussi qu'une bonne part du code garde les stigmates trompeurs d'une histoire où gd était la principale ou seule 
librairie :

- la fonction appelée "_image_gd_output" est en fait appelée par d'autres 
méthodes que gd (yc convert)
- "_image_valeurs_trans" est utilisée par toutes les méthodes (yc convert) alors qu'un commentaire indique que c'est 
réservé à GD2  (https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres_images_lib_mini.php#L105)


Au passage je découvre que var_mode=images permet de refaire les calculs 
d'images.
Yeah bonne pioche !
À documenter dans https://www.spip.net/fr_article4453.html ?

JLuc

___
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] Données Exif des images réduites

2020-09-04 Par sujet JLuc

Le 04/09/2020 à 13:02, Cerdic a écrit :

Je pense que pour image_reduire ça dépend aussi de la méthode que tu as choisi 
dans ecrire/ pour la création des vignettes.
Certaines méthodes probablement perdent aussi les données.


J'ai essayé GD2 et CONVERT avec les mêmes résultats.

Mais ensuite, pour tous les filtres qui transforment les images (donc modifient son  contenu au delà d’une simple mise à 
l’échelle, donc y compris recadrent) il y a en effet création d’une nouvelle image via GD2 et aucun processus de recopie 
des exif de la source vers la destination.


J'ignore la mécanique de spip pour ces traitements, mais je vois que les différentes images réduites bénéficient bien de 
la rotation EXIF de l'image initiale, alors que celle qui passe par image_recadre ou image_proportions (qui appelle 
image_recadre) n'en dispose plus.

N'y a t il pas création d'une nouvelle image dans les 2 cas ?

Ya quelque chose qui cloche là dedans 
(https://www.youtube.com/watch?v=eryzp0Pklc8)

JL


Le 4 sept. 2020 à 12:18 +0200, JLuc , a écrit :

Le 17/07/2020 à 15:49, JLuc a écrit :

J'ai l'impression que le filtre image_reduire ne tient pas compte des données 
exif des photos,
et ne fournit aucune exif au fichier de l'image-réduite.


Vacances finies je rééxamine le squelette et les exifs des différentes images 
produites aux différentes étapes du
traitement, et il m'apparaît que image_reduire conserve bien les données EXIF
mais que c'est image_proportion qui les fait disparaître.
Est-ce que ça facilite t il la prise en compte de ce soucis ?

JL


Du coup, des photos prises en penchant l'appareil photo, qui ont donc une exif 
de rotation qui leur permet d'apparaître
partout à l'endroit car les lieux communs de visualisation d'une image tiennent 
compte des données exifs de rotation
apparaissent tournées une fois réduites


___
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] Données Exif des images réduites

2020-09-04 Par sujet JLuc

Le 17/07/2020 à 15:49, JLuc a écrit :

J'ai l'impression que le filtre image_reduire ne tient pas compte des données 
exif des photos,
et ne fournit aucune exif au fichier de l'image-réduite.


Vacances finies je rééxamine le squelette et les exifs des différentes images produites aux différentes étapes du 
traitement, et il m'apparaît que image_reduire conserve bien les données EXIF

mais que c'est image_proportion qui les fait disparaître.
Est-ce que ça facilite t il la prise en compte de ce soucis ?

JL

Du coup, des photos prises en penchant l'appareil photo, qui ont donc une exif de rotation qui leur permet d'apparaître 
partout à l'endroit car les lieux communs de visualisation d'une image tiennent compte des données exifs de rotation

apparaissent tournées une fois réduites


___
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] Fwd: #LOGO_ARTICLE not taking translated logo

2020-08-07 Par sujet JLuc

Le 07/08/2020 à 12:19, Rainer Müller a écrit :

En fait, ce teste avait rajouté pour éviter un bug lors de la création d'articles 
avec spip 3.2 >
voir https://contrib.spip.net/Site-multilingue-facile-4145#comment498199.
Je n'avais pas  trouvé exactement ce qui avait changé et pour éviter des 
problèmes j'ai sorti le bazooka.

Je cite :
« lors de la création d’une traduction d’un article le logo de l’article original disparaît, il faut alors le 
rée-uploader. »


Je rencontre un peu le même pb semble t il avec Duplicator
sur des sites 3.3 pas récents (entre 3.2.7 et 3.3 d'aujourd'hui)
= le logo de l'article d'origine est transféré au nouvel article copié,
mais l'article original perd le sien, soit à la copie,
soit quand je supprime le logo du nouvel article pour en mettre un autre
(je n'ai pas encore investigué et ne peux en dire plus pour l'instant)

JL






En tout cas, Urs qui est en 3.2.7 a remplacé 3.2 par 3.3
(ce qui revient au même pour lui que supprimer ce test)
et ça marche pour lui.

JLuc





___
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] Fwd: #LOGO_ARTICLE not taking translated logo

2020-08-06 Par sujet JLuc

Le 30/07/2020 à 16:38, JLuc a écrit :

Le 29/07/2020 à 18:18, Jacques B a écrit :
Je crois bien que ça a été intégré en SPIP 3.2 ! (j'utilise maintenant le plugin multilingue mais avant les logos 
étaient déjà intégrés) . Lorsqu'une traduction de l'article est faite elle intègre tous les éléments de l'article : 
logo, mots clés, illustrations, composition...


Et attention il semble bien que le gars ne parle pas de la 3.3, puisqu'il dit "I've updated to the latest stable 
version". Donc en 3.2 il faudrait voir s'il n'aurait pas un autre plugin qui vienne foutre la grouille.


En effet, urs précise qu'il utilise la 3.2.7.
Du coup si ça marchait avant, ça devrait encore marcher ?!...


Le pb vient, me semble t il, de la confusion lors du commit
https://git.spip.net/spip-contrib-extensions/multilingue/commit/f0215ecb5686ab1236bee5f4649f54db3c973058
entre 2 fonctionnalités :

- *recopier le logo lors de la création d'une nouvelle traduction* : c'est ce que fait le commit 
https://core.spip.net/projects/spip/repository/revisions/23517 dans le core > SPIP 3.2 dans inc_completer_traduction_dist


- *chercher le logo de l'article d'origine lorsqu'une traduction n'a pas de logo*. C'est ce que faisait multilingue et 
ce que ne fait plus multilingue pour toutes les traductions créées *avant* l'upgrade d'un spip en 3.2, qui n'ont PAS de 
logo.


DONC peut être faut il simplement *supprimer* ce test
if (spip_version_compare(spip_version( ), '3.2.*', '<')) de multilingue
https://git.spip.net/spip-contrib-extensions/multilingue/src/branch/master/multilingue_fonctions.php#L8
?

En tout cas, Urs qui est en 3.2.7 a remplacé 3.2 par 3.3
(ce qui revient au même pour lui que supprimer ce test)
et ça marche pour lui.

JLuc



Le 29/07/2020 à 12:05, Bruno Bergot a écrit :

Et donc, en lisant ça :

https://git.spip.net/spip-contrib-extensions/multilingue/commit/f0215ecb5686ab1236bee5f4649f54db3c973058

Il semble que c'est le plugin multilingue qui gère ça automagiquement, et il est fort possible qu'il ne soit pas 
encore compatible ou adapté au fonctionnement des logos de SPIP 3.3.


++
b_b

Le 29/07/2020 à 11:53, Bruno Bergot a écrit :

Hop,

Le 29/07/2020 à 11:41, Victor / tokiop a écrit :


Mais d'après 
https://git.spip.net/spip-contrib-extensions/multilingue/src/branch/master/multilingue_fonctions.php#L11 ça a été 
intégré en natif en 3.2





___
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] Fwd: #LOGO_ARTICLE not taking translated logo

2020-07-30 Par sujet JLuc

Le 29/07/2020 à 18:18, Jacques B a écrit :
Je crois bien que ça a été intégré en SPIP 3.2 ! (j'utilise maintenant le plugin multilingue mais avant les logos 
étaient déjà intégrés) . Lorsqu'une traduction de l'article est faite elle intègre tous les éléments de l'article : 
logo, mots clés, illustrations, composition...


Et attention il semble bien que le gars ne parle pas de la 3.3, puisqu'il dit "I've updated to the latest stable 
version". Donc en 3.2 il faudrait voir s'il n'aurait pas un autre plugin qui vienne foutre la grouille.


En effet, urs précise qu'il utilise la 3.2.7.
Du coup si ça marchait avant, ça devrait encore marcher ?!...

JL



Le 29/07/2020 à 12:05, Bruno Bergot a écrit :

Et donc, en lisant ça :

https://git.spip.net/spip-contrib-extensions/multilingue/commit/f0215ecb5686ab1236bee5f4649f54db3c973058

Il semble que c'est le plugin multilingue qui gère ça automagiquement, et il est fort possible qu'il ne soit pas 
encore compatible ou adapté au fonctionnement des logos de SPIP 3.3.


++
b_b

Le 29/07/2020 à 11:53, Bruno Bergot a écrit :

Hop,

Le 29/07/2020 à 11:41, Victor / tokiop a écrit :


Mais d'après 
https://git.spip.net/spip-contrib-extensions/multilingue/src/branch/master/multilingue_fonctions.php#L11 ça a été 
intégré en natif en 3.2





___
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


[spip-dev] Fwd: #LOGO_ARTICLE not taking translated logo

2020-07-28 Par sujet JLuc


Ça pourrait être en rapport avec la nouvelle gestion des logos
alors je transmet ici.

En bref : d'après Urs, il semble qu'avant, le #LOGO_ARTICLE d'un article traduit
renvoyait directement le LOGO de l'article dans la langue d'origine.

Et ce n'est plus le cas.

JLuc

 Message transféré 
From:   Urs Riggenbach via spip-en 
Newsgroups: gmane.comp.web.spip.english
Subject:#LOGO_ARTICLE not taking translated logo

Dear All,

I have recently noticed that on one of my websites a lot of images disappeared 
on the translated articles.

Before, the translated articles simply took the logo from the original article, if it had one set. (I'm using the 
#LOGO_ARTICLE tag).


I am not sure what changed this behavior (or if this is the default behaviour) - but this was really great and I would 
like to get this functionality back. Otherwise I have to upload all logos to the other articles as well.


Does anyone know how to do that, or why this functionality could appear/disappear? Perhaps this functionality is part of 
a plugin?


I've updated to the latest stable version but still #LOGO_ARTICLE does not use the original article's logo on the 
translated articles.


Warm regards,
Urs


--
Urs Riggenbach
Energy - Webdesign - Consulting

Weissensteinstrasse 76
4500 Solothurn
Switzerland

+41 79 918 0663 (CH)
+358 45 872 3836 (FI)


https://ursrig.com


___
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] ***UNCHECKED*** Re: Données Exif des images réduites

2020-07-17 Par sujet JLuc

Le 17/07/2020 à 18:53, "Rémi Suinot via spip-dev 
"@alan.cursys.net a écrit :

J'avais commencé à voir pour faire un filtre exif, sur les images pour le 
plugin html5up_lens, mais après un petit moment,  j'ai fait le constat que ce 
devait être à l'utilisateur de modifier l'image avant de la placer sur le site.
Cependant, mon problème était à la base, pour des images de type "dessin 
d'art", ce n'était pas des photos.
Je crois avoir gardé le code du filtre si tu veux.


Merci de proposer ton aide.
Il y a plusieurs plugins déjà qui interrogent et présentent les exif :
https://contrib.spip.net/Metadonnees-Photo est le plus récent je crois
https://contrib.spip.net/Balise-EXIF-recuperer-les le plus ancien, mais le code 
central doit être encore bon
et https://contrib.spip.net/Afficher-les-donnees-EXIF-des-images

Mais ce que je voudrais c'est que les utilisateurs qui uploadent une image
et qui la voient "à l'endroit" sur leur bureau (car celui ci tient compte de la 
rotation exif)
puissent simplement la télécharger sans jamais savoir qu'il eiste des exifs
et la voir également et tout simplement "à l'endroit" sur le site spip.

J'imagine qu'il faudait...
soit que image_reduire réinjecte les metadonnées exif après avoir réduit (?)
soit que l'upload en tienne compte pour assurer "physiquement" la rotation 
décrite par les métadonnés...

JL


RS.

17 juillet 2020 15:49 "JLuc"  a écrit:


J'ai l'impression que le filtre image_reduire ne tient pas compte des données 
exif des photos,
et ne fournit aucune exif au fichier de l'image-réduite.

Du coup, des photos prises en penchant l'appareil photo, qui ont donc une exif 
de rotation qui leur
permet d'apparaître
partout à l'endroit car les lieux communs de visualisation d'une image tiennent 
compte des données
exifs de rotation
apparaissent tournées une fois réduites

Je m'étonne d'avoir mis si longtemps à m'en apercevoir.
(n'avez vous pas constaté ça aussi ?)

Et du coup comment faire pour avoir des vignettes toujours à l'endroit ?

JL

___
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


[spip-dev] Données Exif des images réduites

2020-07-17 Par sujet JLuc

J'ai l'impression que le filtre image_reduire ne tient pas compte des données 
exif des photos,
et ne fournit aucune exif au fichier de l'image-réduite.

Du coup, des photos prises en penchant l'appareil photo, qui ont donc une exif de rotation qui leur permet d'apparaître 
partout à l'endroit car les lieux communs de visualisation d'une image tiennent compte des données exifs de rotation

apparaissent tournées une fois réduites

Je m'étonne d'avoir mis si longtemps à m'en apercevoir.
(n'avez vous pas constaté ça aussi ?)

Et du coup comment faire pour avoir des vignettes toujours à l'endroit ?

JL


___
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] Wheels et paragraphes intempestifs

2020-07-12 Par sujet JLuc

Le 12/07/2020 à 23:09, nicod_ a écrit :

Le 12/07/2020 à 20:33, JLuc a écrit :

C'est peut être que propre applique "paragrapher" sur  quand il en 
reçoit une,
alors que le pipeline transforme le raccourci AVANT propre, si bien que propre n'a 
plus de  à paragrapher.


Oui, c'est sûrement la bonne explication.


Voir aussi https://core.spip.net/issues/2416 a propos de $toujours_paragrapher


Ah ok, pendant mes tests, je m'étais rendu compte effectivement que cette constante ne faisait plus rien du tout, j'ai 
pas rêvé donc :)


Du coup, https://www.spip.net/fr_article5051.html est peut être à dépublier ?
Ou bien préciser que c'est obsolète ?


Au vu du ticket j'ai l'impression que c'est toujours valable,
mais que ça doit être fait seulement dans le mes_options, comme c'est indiqué,
et pas dynamiquement le temps de l'appel d'une fonction dans un pipeline par 
exemple.

J'imagine que TextWheel recopie la globale dans une variable statique de classe
en initialisant sa machine à textes mais je n'ai pas vu où dans le source.

JL



___
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] Wheels et paragraphes intempestifs

2020-07-12 Par sujet JLuc

Le 12/07/2020 à 15:38, nicod_ a écrit :

Je me contentais de déclarer la wheel dans les globales, sans rien d'autre :
$GLOBALS['spip_wheels']['patate'] = array('patate.yaml');

Mais en regardant le code de dame_blanche, cité dans l'autre fil, j'ai testé en utilisant le même code dans le pipeline 
pre_propre et là ça ne génère plus de  en trop :


C'est peut être que propre applique "paragrapher" sur  quand il en 
reçoit une,
alors que le pipeline transforme le raccourci AVANT propre, si bien que propre n'a 
plus de  à paragrapher.

Voir aussi https://core.spip.net/issues/2416 a propos de $toujours_paragrapher
JL

___
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] UI gitea

2020-07-12 Par sujet JLuc

Le 12/07/2020 à 10:11, JLuc a écrit :

Sinon comment faire ?

C'est réglé (cf autre fil)


___
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] UI gitea

2020-07-12 Par sujet JLuc

Le 12/07/2020 à 10:09, Eric Lupinacci a écrit :

Normalement tu as un bouton Paramètres en haut à droite de la page de ton repo.
En cliquant tu arrives à une page ou à la fin tu peux supprimer le repo.


OK c'est réglé merci !
C'était un paramétrage adblock trop agressif.
Le mode "totalement épuré" ne convient pas avec gitea :-)
Je l'ai déconnecté.

JLuc

___
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] UI gitea

2020-07-12 Par sujet JLuc

Mon mail a été considéré comme spam 
Je reposte sans l'unique lien qui était vers pic.infini pour présenter une 
capture d'écran.

Bonjour

Je voudrais supprimer un repo inutile (JLuc/bigup) et créer un ticket sur un 
autre,
mais je ne trouve pas moyen de le faire.

Je n'utilise pas git.spip tous les jours et je ne sais pas bien où ça en est.
L'UI de git.spip.net traverse t elle actuellement une période d'état dégradé ?
Sinon comment faire ?

JL

___
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] UI gitea

2020-07-12 Par sujet JLuc

Bonjour

Je voudrais supprimer un repo inutile (JLuc/bigup) et créer un ticket sur un 
autre,
mais je ne trouve pas moyen de le faire.

Je n'utilise pas git.spip tous les jours et je ne sais pas bien où ça en est.
L'UI de git.spip.net traverse t elle actuellement une période d'état dégradé ?
Sinon comment faire ?

Pour info voici ce que je vois : https://pic.infini.fr/qWUSB2o6/VuDrLzUs.jpg
Les 2 premieres lignes sont générales et ne concernent pas le repo courant.
JL


___
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] Utiliser TextWheel

2020-07-11 Par sujet JLuc

Le 11/07/2020 à 20:48, Stephane Santon a écrit :

Si je désire remplacer les textes saisis
 ... 
par le HTML produit
 ... 
est-ce que c'est l'utilisation du plugin TextWheel le plus approprié ?
Suffit-il de créer un fichier
squelettes/wheels/spip/spip-plaquette.yaml ou
monplugin/wheels/spip/spip-plaquette.yaml
et le contenu qui va bien ?


C'est très simple à faire en utilisant le plugin dameblanche
qui utilise une wheel pour ça.
Il suffit d'ajouter une autre wheel copiée d'après celle proposée
dans ton dossier wheels local.

JL

___
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] avec ou sans lien

2020-07-10 Par sujet JLuc

Le 10/07/2020 à 09:23, chanka...@choc0.net a écrit :

salut JL
est-ce que cette question serait mieux dans un nouveau fil de discussion ?

À défaut d'un nouveau fil j'ai changé le sujet
(mais il y en avait 2 sujets...)


Le 10/07/2020 à 09:06, JLuc a écrit :

À part ça, sur https://contrib.spip.net/PHANTOM-HTML5UP
le premier  génère un  cliquable,
mais pas les 2 autres à droites dans le tableau.
Ça vous fait ça aussi ?
Qu'est ce qui se passe là ? 


tu parles de la première ligne de vignette sur la page sommaire ?


Je ne sais pas ce que tu appelles la page sommaire.
Je parle de la première ligne de vignettes sur la page à l'url citée
dont le texte spip est
||  
||
et dont le 1er  produit un lien ici et pas les 2 autres.

JLuc

___
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] Mise à jour squelette Html5up Spectral

2020-07-10 Par sujet JLuc

Le 10/07/2020 à 08:04, jeanmarie a écrit :

- Est-ce que le projet de partage de config/mutualisation des elements communs 
à tous les squelette html5up a avancé ?


Bof, on en est au point de dire que ça serait super d'y arriver mais que pour ça, il faudrait faire un audit de tous les 
squelettes HTML5up pour réfléchir en amont à ce qui serait mutualisable. Donc l'esprit actuel est plutôt de se reposer 
autant que possible sur des plugins externes (les plugins facultatifs de la doc) pour faciliter au mieux le passage de 
l'un a l'autre et conserver une même logique de fonctionnement (nom des variables de config...) pour en faciliter la 
maintenance. Pragmatic Style :)


Faut il retirer cette partie de la doc en décalage avec le réel et peut être 
les possibles ?

À part ça, sur https://contrib.spip.net/PHANTOM-HTML5UP
le premier  génère un  cliquable,
mais pas les 2 autres à droites dans le tableau.
Ça vous fait ça aussi ?
Qu'est ce qui se passe là ?

JL

___
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] Import de dépôts qui n'ont pas fonctionné

2020-07-09 Par sujet JLuc

Le 09/07/2020 à 13:45, jeanmarie a écrit :


Le 09/07/2020 à 13:30, JLuc a écrit :

C'est peut être utile de documenter cela ?
Dans ce cas, pourrais tu décrire la situation, le besoin et la solution retenue,
par exemple sur 
https://contrib.spip.net/FAQ-pratique-Comment-SPIPer-avec-git-spip-net ?


C'est fait...


Super :-)
JL


___
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] Import de dépôts qui n'ont pas fonctionné

2020-07-09 Par sujet JLuc

Le 09/07/2020 à 13:25, jeanmarie a écrit :


Le 09/07/2020 à 12:39, chanka...@choc0.net a écrit :

moi je ferais
git remote add lenomquetuveux 
https://git.spip.net/spip-contrib-squelettes/html5up_escape_velocity.git
git push lenomquetuveux master


C'est fait \o/ 
https://git.spip.net/spip-contrib-squelettes/html5up_escape_velocity
merci !


C'est peut être utile de documenter cela ?
Dans ce cas, pourrais tu décrire la situation, le besoin et la solution retenue,
par exemple sur 
https://contrib.spip.net/FAQ-pratique-Comment-SPIPer-avec-git-spip-net ?

JL

___
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] Documentation sur les temps de connexion

2020-07-03 Par sujet JLuc

Le 03/07/2020 à 18:48, RastaPopoulos a écrit :

Cas concret : j'ai un site avec des abonné⋅es, comptes uniquement visiteurs 
publics donc, et ça se déconnecte toujours trop vite. Pourquoi ? Que doit-on 
changer pour ça ? Plusieurs choses ? Une seule chose ?


Dans le même cas, j'ai modifié une seule chose :
define('_RENOUVELLE_ALEA', 400 * 3600); // soit env 2 semaines

Et ça marche bien

JL

___
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] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet JLuc

Le 30/06/2020 à 16:31, Eric Lupinacci a écrit :

La liste des restants est disponible ici : http://spip.pastebin.fr/63338


Parcourant la liste je vois markdown
pourtant ç'a l'air bien vivant 
https://plugins.spip.net/markdown.html?compatible_spip=3.2

JL

___
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] SPIP-Bonux

2020-06-22 Par sujet JLuc

Le 22/06/2020 à 13:11, Maïeul Rouquette a écrit :


Non ya pas eu indiqué à ma connaissance.

hier soir à 23h10 :) mais bien après tes premières questions j'en convient


Ah en effet. Merci aussi alors.
JL


___
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] SPIP-Bonux

2020-06-22 Par sujet JLuc

Le 22/06/2020 à 09:35, Cerdic a écrit :
J’ai donc envoyé un revert complet des 4 commits de JLuc que tout soit bien clair, et recommit le seul changement de 
cette salve, qui était une URL dans le PHPDoc.


Merci Cerdic !

JLuc, ça serait quand même malin de tester un peu avant d’envoyer ce genre de gros diff, et si tu n’est pas certain ET 
que tu as besoin de commit pour déployer et tester, le mieux c’est de faire une branche : comme ça en ligne tu checkout 
sur cette branche, tu teste, tu debug, et quand ça marche tu peux faire une Pull Request, ou cherry-picker pour envoyer 
sur le master, ou demander à quelqu’un de le faire.


Oui je suis en environnement de dev temporairement bancal
et visiblement je ferais mieux de m'abstenir tant que c'est pas upgradé 
consolidé.

Pour info du coup j'avais commit via l'UI gitea
et c'est donc probablement ça qui a ajouté les espaces,
alors pourtant que ça ne s'était pas produit toutes les fois précédentes où 
j'ai commit comme ça
(alors je pige pas le pourquoi).


Et donc, instant documentation :
Comme indiqué par Maieul, 


Non ya pas eu indiqué à ma connaissance.

C'est une commandes très basique finalement pour revert.
Encore faut il savoir que c'est aussi simple car c'est souvent compliqué de 
corriger un truc déjà pushé.

re-merci
JL


pour générer un commit qui revert un autre commit il faut faire
git revert xx > (avec le numéro du commit à revert )




Pour voir le diff entre 2 commits c'est
git diff abcdef..123456
(la référence du premier commit, deux petits points et la référence du second 
commit).

Et si on ajoute l’option -w ça ignore les changements qui ne sont que des 
espaces.
Dans notre cas ça donnait :

$ git diff -w e350597..1900248
diff --git a/spip_bonux_options.php b/spip_bonux_options.php
index 5d83500..b2c6b6f 100644
--- a/spip_bonux_options.php
+++ b/spip_bonux_options.php
@@ -202,7 +202,7 @@ if (!function_exists('text_truncate')) {
  * @param array $options An array of html attributes and options.
  * @return string Trimmed string.
  * @access public
-* @link http://book.cakephp.org/view/1469/Text#truncate-1625
+ * @link https://api.cakephp.org/4.0/class-Cake.Utility.Text.html#truncate
  */
  function text_truncate($text, $length = 100, $options = array()) {
  $default = array(



--
Cédric
Le 21 juin 2020 à 21:58 +0200, JLuc , a écrit :

Le 21/06/2020 à 21:21, Eric Lupinacci a écrit :> Je viens de réessayer :> 
Warning: Cannot modify header information -
headers already sent by (output started at >
/Users/eric/Sites/ZONEGIT/gitea/spip-contrib-extensions/spip-bonux/spip_bonux_options.php:1)
 in >
/Users/eric/Sites/SPIP/ecrire/inc/actions.php on line /141/> En plus 
l’indentation a changé et d’ailleurs elle est
foireuse sous phpstorm.> Donc tant qu’à faire faut revenir vraiment à la 
version précédente du fichier svp.
OK
J'ai pas eu de réponse pour réverter
alors je vais commiter une nouvelle couche

JLuc

___
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] SPIP-Bonux

2020-06-21 Par sujet JLuc
Le 21/06/2020 à 21:21, Eric Lupinacci a écrit :> Je viens de réessayer :> Warning: Cannot modify header information - 
headers already sent by (output started at > 
/Users/eric/Sites/ZONEGIT/gitea/spip-contrib-extensions/spip-bonux/spip_bonux_options.php:1) in > 
/Users/eric/Sites/SPIP/ecrire/inc/actions.php on line /141/> En plus l’indentation a changé et d’ailleurs elle est 
foireuse sous phpstorm.> Donc tant qu’à faire faut revenir vraiment à la version précédente du fichier svp.

OK
J'ai pas eu de réponse pour réverter
alors je vais commiter une nouvelle couche

JLuc

___
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] r125253 - _plugins_/spip-bonux/trunk

2020-06-20 Par sujet JLuc

Le 20/06/2020 à 17:31, nicod_ a écrit :

Tu as regardé le diff dans trac ?
Simplement, après ton commit il y a deux espaces au début de chaque ligne (même 
pas le PSR spip en plus).


Oui je sais pas comment j'ai fait ça mais j'ai très bien compris le pb.

Ce que je demandais c'est si je pouvais réparer ça
à coup de revert rebase merge push -onto ou autre giterie

JL

___
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] r125253 - _plugins_/spip-bonux/trunk

2020-06-20 Par sujet JLuc

Le 20/06/2020 à 16:25, RastaPopoulos a écrit :

Le 20/06/2020 à 15:50, nicod_ a écrit :

tu as mélangé une modification de l'indentation et tes propres modifs dans ce 
commit unique, ce qui fait que le diff est illisible, on ne peut pas lire ce 
que tu as modifié (sauf manip acrobatique).

Tutafé, et du coup, vu que c'est moi qui l'ai ajouté et que je l'utilise pas 
mal, jluc tu as fait quoi dessus donc ? :)
Comme 99% de bonux, ça devrait pouvoir être ajouté au core, dès la 3.3… ça fait 5 ans 
c'est là "pour tester" quand même…


Ah je suis désolé. Je ne sais pas bien ce qui a provoqué ça.

En fait
- Je croyais corriger un bug à l'origine du signalement fait sur contrib
- mais c'était une erreur de ma part
- et j'ai annnulé par la suite presqu'aussitôt.

Donc au total j'ai fait 3 commits qui se résument au 2eme
(du moins normalement, mais avec en prime des indentations différentes)
https://git.spip.net/spip-contrib-extensions/spip-bonux/commit/fa2020716deff18a3835d1801bc397cea2d93d7c
= actualisation du lien vers la librairie phpCake à l'origine de cette fonction.

À noter que cette fonction a évolué dans phpCake depuis le temps
alors si jamais il y a un pb dedans il est peut être réglé par la nouvelle 
version
(mais pour compat spip, il faudra garder l'ancien nommage des options).

Puis je faire qqchose pour améliorer ça ?
(il va peut être me falloir des détails)

JLuc


___
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] Ménage dans les dépots git

2020-06-18 Par sujet JLuc

Le 17/06/2020 à 23:53, Maïeul Rouquette a écrit :


Merci pour ce travail.


Oui.

Pour info, j'avais volontairement effacé jluc/bigup qui mirrorait le repo 
orignal avant qu'il ne soit rapatrié ici.

JLuc

___
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] Demande d'accès a git

2020-06-16 Par sujet JLuc

Le 16/06/2020 à 23:27, PatV via spip-dev a écrit :

Le spip-dev c'est sans doute parce que je passe par les news...


Je passe aussi par news.gmane.io,
avec thunderbird comme lecteur,
et mes mails ne semblent pas manifester ce pb.
JL

___
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] Open calais ?

2020-06-16 Par sujet JLuc

Le 16/06/2020 à 13:04, BoOz a écrit :
De mon côté j'ai fait mon propre système, si ca vous dit d'essayer 
https://github.com/BoOz/entites_nommees


Ça semble être une reconnaissance de motifs pour les noms propres encore.

Mais je suis plutôt contre le star system car on sait on nous entraîne le 
système.
C'est le génie des marges, l'expérience des inconnus et les savoir faire 
pionniers du terrain
qui m'intéressent.

Les tags sont une alternative à la simple recherche.
Ils sont intéressants quand ils sont posés avec de la sémantique
= de manière plus smart que ce que fait une recherche même avec regexp locale.

Pour cela, des réseaux de relations entre termes en précise certains
et les renforcent ou les atténuent,
au moins pour un nombre limité de tags prédéfinis signifiants dans un domaine 
donné.

Ton readme mène à la page de démo de textrazor qui est opérationnelle pour le 
français aussi
https://www.textrazor.com/demo
Ils utilisent un réseau de renforcement sous la forme de régles prolog
https://www.textrazor.com/rules
Ça semble donner des résultats bien utiles pour des textes généralistes
mais moins satisfaisants pour des textes spécialisés.
Ya un forfait gratuit pour moins de 500 de requêtes par jour.
(500 articles par jour, faut les écrire !)
Ça mériterait d'être exploré.

JL

___
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] Open calais ?

2020-06-15 Par sujet JLuc

Le 15/06/2020 à 15:01, Naema a écrit :
Merci d'avoir relancé, en effet il semble que OpenCalais ait été remplacé par une autre terminologie : PermID et 
Refinitiv (et non OpenCalais, que je ne retrouve plus) https://permid.org/
J'avais obtenu une clé API pour OpenCalais en avril 2019 mais les liens du mail ne fonctionnent plus, vérifiés à 
l'instant à l'occasion de votre message, je crois donc qu'il y a eu un changement de nom. (ne sachant comment installer 
l'API dans Spip, je m'étais arrêtée là à l'époque)
Autant que je m'en souvienne il n'y avait pas de plugin OpenCalais pour Spip et Seenthis est sous une ancienne version 
(mais robuste) de Spip.


En essayant la démo de la tag machine de refinitiv
https://permid.org/onecalaisViewer
je n'ai que de mauvais résultats où seuls apparaissent les noms propres géographiques ou de célébrités ou de grosses 
entreprises.

Je crois que ce n'est pas adapté au français.
La démo en tout cas.

Wikipedia évoque une autre ressource ciblant mieux la langue française : Wikimeta, qui utilise les ressources de DBpedia 
en tant que liens documentaires, mais les sites wikimeta et dbpedia sont HS également.


Ces technologies ne semblent pas libérées pour le grand public.

Après ces premières recherches, et pour un site fortement thématique 
(spécialisé),
je crains que des outils généralistes mal maintenus ne soient pas d'une grande 
aide
et je me dis qu'il est préférable de faire soi même sa tambouille si jamais ça 
en vaut la peine.

JLuc

___
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] Open calais ?

2020-06-15 Par sujet JLuc

Cherchant à me renseigner sur Open Calais je n'ai trouvé que des urls 
périphériques,
les liens plus "à la source" trouvés étant morts :
http://www.opencalais.com , www.opencalais.com/opencalais-api/ , 
https://twitter.com/opencalais
mais l'API semble bien en place : https://api.thomsonreuters.com/permid/calais
donc ça existe mais ça semble s'être "refermé".

Est-ce que quelque chose m'échappe ?
Seenthis s'en sert-il encore vraiment ?
Y a t il un plugin pour SPIP ou une bonne alternative aujourd'hui pour 
l'annotation sémantique des textes ?

JLuc

___
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] Créer ses propres saisies - Héritage - critère where - sécurité

2020-06-14 Par sujet JLuc

Le 14/06/2020 à 18:41, Maïeul Rouquette a écrit :

Le 14/06/2020 à 18:30, Vincent Callies a écrit :

Oui. C’est exactement  ma préoccupation/interrogation, JL.

oui mais c'est valable pour n'importe quel squelette, qu'est-ce que le fait que ce soit une saisie change la donne en 
terme de préoccupation?


Ce nest pas le fait que ce soit une saisie. L'interrogation porte sur le 
paramètre `where`.

Utiliser une balise #TEXTE dans un squelette se traduit par le passage d'une 
chaine de caractère qui est le nom du champ
et qu'il est facile de filtrer (ça doit être un nom de champ et parfois en plus 
on sait cadrer les valeurs possibles).
C'est tout ce qui passe, le reste c'est du code SPIP bien cerné.

Mais un where est un morceau de requête MYSQL qui est passé plus ou moins 
directement à l'interpréteur MYSQL.
Potentiellement il y a plein de trucs dedans.
Il faut donc avoir une vigilance particulière et la question est légitime
...même si les devs du noyau font d'ordinaire bien attention à ça
et ça m'étonnerait qu'ils aient négligé ça.

JL

___
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] Créer ses propres saisies - Héritage - critère where - sécurité

2020-06-14 Par sujet JLuc

Le 14/06/2020 à 13:25, Maïeul Rouquette a écrit :

Le 14/06/2020 à 09:12, JLuc a écrit :

La nouvelle saisie reçoit ses arguments par l'environnement, c'est à dire 
_REQUEST.

moi je vois ca
#SET{where,'iso_moi in ("FR-GUA","FR-MTQ","FR-GUF","FR-LRE","FR-MAY")'}
dans le code de Thrax.
C'est bien un truc en dur.


Oui mais il y a une nouvelle saisie qui se traduit par la création d'un nouveau 
squelette
saisies/subdivisions.html
qui sert pour le plugin Saisie à définir la #SAISIE
mais qui peut aussi potentiellement être appelé directement par 
?page=saisies/subdivisions
avec la restriction précitée :
> comme [c]e squelette d'une saisie est dans un sous dossier,
> il n'y a que les webmasters (je crois même pas les admins ?) qui peuvent y 
accéder directement.
> Ça limite le risque mais c'est pas absurde de se demander comment le where 
est sanitizé.

JL

___
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] Créer ses propres saisies - Héritage - critère where - sécurité

2020-06-14 Par sujet JLuc

Le 14/06/2020 à 09:00, Maïeul Rouquette a écrit :

il y a pas de raison que cela pose des problèmes de sécurités particuliers
1. TLe contenu de ton where est écrit en dur et ne dépend pas de l'internaute



il peut être passé dans le _REQUEST (post ou get)



pas de ce que je vois du code envoyé par Thrax


La nouvelle saisie reçoit ses arguments par l'environnement, c'est à dire 
_REQUEST.

Dans les conditions d'usage prévues par ce plugin, la noisette englobante 
décide la valeur de ces arguments,
mais des hackers n'utilisent pas le code mis à leur disposition dans les 
conditions prévues
puisque leur but n'est pas d'obtenir les fonctionnalités prévues.
Thrax envisage la possibilité qu'on appelle la noisette directement sans passer 
par la noisette qui l'inclut.

Comme le squelette d'une saisie est dans un sous dossier,
il n'y a que les webmasters (je crois même pas les admins ?) qui peuvent y 
accéder directement.
Ça limite le risque mais c'est pas absurde de se demander comment le where est 
sanitizé.

JL


___
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] porte_plume_intertitres : PR qui veut pas

2020-06-12 Par sujet JLuc

Le 12/06/2020 à 09:23, jeanmarie a écrit :

> j'ai mis à jour la partie PR du mémo Git/SVN : lite1.infini.fr/p/git2svn_spip

> que fait-on de contrib.spip.net/Git (je ne savais pas que ça existait :/ )

Il y a aussi contrib.spip.net/FAQ-pratique-Comment-SPIPer-avec-git-spip-net
qui apporte des réponses de base (et donc importantes) qui ne figurent pas 
ailleurs
mais qui présente les mêmes zones aveugles notamment sur "comment faire une PR".

Cette question est par contre détaillée par
contrib.spip.net/Proposer-un-patch-via-git-spip-net-pour-le-noyau-ou-la
avec malheureusement différentes versions et pas de consensus synthétique 
simplifié,
faute d'expérience concrète de la part du rédacteur principal qui ne peut donc 
pas trancher.

Une contribution expérimentée serait bienvenue

JLuc
(sans les http:// pour mieux passer le filtre antispam ?)

___
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] porte_plume_intertitres : PR qui veut pas

2020-06-12 Par sujet JLuc

Le 12/06/2020 à 09:23, jeanmarie a écrit :

> j'ai mis à jour la partie PR du mémo Git/SVN : 
https://lite1.infini.fr/p/git2svn_spip


que fait-on de https://contrib.spip.net/Git (je ne savais pas que ça existait 
:/ )

Il y a aussi 
https://contrib.spip.net/FAQ-pratique-Comment-SPIPer-avec-git-spip-net
qui apporte des réponses de base (et donc importantes) qui ne figurent pas 
ailleurs
mais qui présente les mêmes zones aveugles notamment sur "comment faire une PR".

Cette question est par contre détaillée par
https://contrib.spip.net/Proposer-un-patch-via-git-spip-net-pour-le-noyau-ou-la
avec malheureusement différentes versions et pas de consensus synthétique 
simplifié,
faute d'expérience concrète de la part du rédacteur principal qui ne peut donc 
pas trancher.

Une contribution expérimentée serait bienvenue :-)


JL

___
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] Écriture inclusive

2020-06-07 Par sujet JLuc

Le 05/06/2020 à 14:43, JLuc a écrit :

Est il possible de savoir en l'état actuel des technologie, comment le point médian est il rendu par les lecteurs 
d'écrans ? 


N'ayant pas reçu de réponse experte, j'ai interrogé le net et la réponse réelle se trouva sur le blog de la fondatrice 
et rédactrice d'un magazine féministe : http://lunatopia.fr/blog/inclusivite-accessibilite


Voici son compte rendu :

« J'ai donc testé cinq phrases :

Iels sont enchantéEs.
Iels sont enchanté-e-s.
Iels sont enchanté.e.s.
Iels sont enchanté(e)s.
Iels sont enchanté·e·s.

La première version est prononcée comme le serait "enchantées" sans majuscule.

Dans la deuxième version, le mot enchanté-e-s est incompréhensible.

Dans les trois dernières versions, le "e" est prononcé distinctement, elles nous conviennent donc toutes les trois d'un 
point de vue accessibilité.


Cependant,  la graphie "é(e)s" est critiquée par certains qui considèrent qu'elle "met les femmes entre parenthèses", 
qu'elle implique une hiérarchie.


Les points médians ont l'avantage d'être neutres typographiquement.

Nous avons donc choisis la graphie "é·e·s"
»

Cela m'encourage à continuer à utiliser le point médian.

JLuc

rePS : au cas où certains l'ignorent, le point médian ⋅ est très facile à 
utiliser sous Linux,
puisqu'il est illico dispo sous le . grâce au AltGr


En quoi et selon quels critères le point médian est-il mal-accessible ?

Ces critères ne sont ils aussi en partie au moins culturels ? Et donc, comme ceux de l'académie française, susceptibles 
d'évoluer, au prix du même effort ou de la même démarche volontaire d'un bienvoyant pour passer du français de Victor 
Hugo à une autre forme de français inclusif ?



JLuc,

___
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] Écriture inclusive

2020-06-05 Par sujet JLuc

Le 05/06/2020 à 14:01, nicod_ a écrit :

Mais comme le dit très bien la conclusion de l'article du Lutin du web (qui est 
une femme) :

Finalement, nous avons donc :
- un besoin qui est d’inclure les femmes et personnes non-binaires dans nos 
discours et, notamment ici, dans nos écrits ;
- et un problème pour certaines personnes handicapées qui est posé par une des techniques répondant à ce besoin 
d’écriture inclusive.

et le commentaire de Nicolas Hofmann, expert en accessibilité et franchement 
pas masculiniste :

Si cette écriture dite inclusive est autant exclusive, c’est quand même un 
comble ^^
J’y vois une analogie avec le web : il est accessible de base, à nous de ne pas le rendre inaccessible. L’écriture 
peut être inclusive de base.


Est il possible de savoir en l'état actuel des technologie, comment le point médian est il rendu par les lecteurs 
d'écrans ? En quoi et selon quels critères le point médian est-il mal-accessible ?


Ces critères ne sont ils aussi en partie au moins culturels ? Et donc, comme ceux de l'académie française, susceptibles 
d'évoluer, au prix du même effort ou de la même démarche volontaire d'un bienvoyant pour passer du français de Victor 
Hugo à une autre forme de français inclusif ?


PS : au cas où certains l'ignorent, le point médian ⋅ est très facile à 
utiliser sous Linux,
puisqu'il est illico dispo sous le . grâce au AltGr

JLuc,

___
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] Sur les starting-blocks depuis des mois....

2020-06-03 Par sujet JLuc

Pour mémo ici pour ceux qui sont pas sur la liste user, Josiane y témoigne à 
nouveau :

«
Pour ceux qui ont perdu des logos a la migration 3.3
J'ai constaté, lors de mes tests en local que cela venait pour mes sites de

define('_IMG_MAX_HEIGHT',1200); // largeur en pixels
define('_IMG_MAX_WIDTH', 1024);  // hauteur en pixels
define('_IMG_MAX_SIZE',  650);   // taille en kilo-octets

dans le fichier mes_options.php

j'ai supprimé ces lignes avant la migration et les logos sont restés présent.
»

Elle avait écrit ceci :
«
la migration vers 3.3 repecte cette limitation  SUR LES IMAGES EXISTANTES et redimensionne l'image qui a une dimension 
superieure  ?


On perd les logos  qui ne respecte pas ces limitations.( vue sur rubrique)
»

Et si je comprend bien elle a indiqué avoir créé un ticket.
JL

___
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] Problème d'une recherche lorsqu'il existe plusieurs boucle sur le même type d'objet

2020-05-29 Par sujet JLuc

Ah ben je reproduis le phénomène sur 2 sites où j'ai testé... comme s'il y 
avait {doublons} sur les boucles 1 et 3

Le 28/05/2020 à 09:21, Cerdic a écrit :

Il va falloir que tu donnes plus d’infos : version exacte de SPIP, de PHP, 
quelle type de base ?…


SPIP 3.3.0-dev [24422]
PHP Version 7.2.26
MYSQL 5.7.23-23-log Percona

Composed-By: SPIP 3.3.0-dev @ www.spip.net + 
spip(3.3.0-dev),aide(1.1.0),archiviste(0.3.0),compagnon(1.7.0),dump(1.9.3),images(2.2.1),forum(1.13.0),jqueryui(1.12.1),mediabox(1.2.0),mots(2.11.1),organiseur(1.3.5),petitions(1.7.1),plan(2.3.1),porte_plume(1.20.0),revisions(1.10.3),safehtml(1.6.1),sites(2.0.2),squelettes_par_rubrique(1.3.0),stats(1.3.3),urls(2.3.2),vertebres(1.4.0),notation(2.4.5),memoization(2.1.9),accelerer_jobs(0.2.2),rechremp(1.4.0),macrosession(0.13.0),xray(0.25.0),declarerparent(1.3.5),switchcase(0.4.0),nospam(2.1.6),creer_sprites(2.1.2),crayons(2.0.9),alerte_urgence(2.2.0),facteur(3.7.2),iterateurs(1.0.6),queue(0.6.8),jquery(3.4.1),minidoc(1.0.3),ordoc(1.1.2),mejs(4.2.7),breves(1.5.2),compresseur(1.14.1),medias(2.25.3),svp(2.0.10),yaml(2.0.11),centre_image(0.10.7),verifier(1.9.6),saisies(4.0.0),duplicator(2.0.8),bigup(1.0.2),tw(1.6.5),htmlpurifier(5.0.0.5)


Avec var_mode=debug je vois que le code MYSQL généré est exactement le même pour pre_1 et pre_3, de même que les codes 
php générés (à part le préfixe du nom de la fonction, qui dépend du nom de la boucle).


JL

___
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] Lien entre les articles du Wiki et les articles de doc

2020-05-29 Par sujet JLuc

Le 28/05/2020 à 15:50, Maïeul Rouquette a écrit :

reprenant tete reposé cette discussion, je me dis que la prochaine spip-party pourrait être l'occasion d'une session 
"documentation wiki vers contrib"


Bonne idée :-)
Si vous avez apprécié la Drôme l'automne dernier, j'ai trouvé un autre chouette 
gîte avec piscine cette fois...
Je me renseigne.

Pour le travail sur le wiki, irl en party ou avant, j'ai préparé un jeu de 
motclés pour repérer d'abord
et caractériser les articles : 
https://contrib.spip.net/ecrire/?exec=groupe_mots_groupe=33
Création à valider, corriger, compléter...

Disclaimer : Les motclés sont roots et ne valent pas un flux de publication dédié aux articles du wiki pour cette 
fonction spécifique de "cueillette et sortie du wiki", mais (comme le wiki) ils sont pratiques et suffisent pour ce boulot.


JL

___
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] Installation de bigup par SVP en 3.2

2020-05-27 Par sujet JLuc

Le 27/05/2020 à 11:33, Matthieu Marcillaud a écrit :

Le 27/05/2020 à 11:20, JLuc a écrit :


Peut être faut il plutôt convenir d'un ordre alphabétique simple,
qui regroupera les github, les gitlab et les git.spip ?


Oui, par ordre alpha, mais sur l’URL complète. C’est bien ce que tu proposais ?


Dans cette dernière proposition oui
(pas sur le premier dossier, car l'organisation dépend des forges)
JL

___
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] Installation de bigup par SVP en 3.2

2020-05-27 Par sujet JLuc

Le 27/05/2020 à 10:11, JLuc a écrit :

 > 
https://git.spip.net/spip-contrib-outils/archivelists/src/branch/master/archivelist-externals.txt



pour info ya quelques temps j'y ai ajouté un dépot gitlab


À l'époque les repos étaient classés par ordre alphabétique,
c'est à dire, vu qu'il n'y avait que des github
par ordre alphabétique du répertoire de plus haut niveau.

J'avais glissé le mien dans cet ordre alphabétique du répertoire de plus haut 
niveau,
et donc sans tenir compte du NDD
car je trouvais que c'était plus sémantique ainsi.

Maintenant je vois qu'il y a des repos github avec /otetard à la fin,
plus le git.spip de bigup qui vient d'être ajouté à la fin aussi
et qui ne s'inscrivent dans aucun ordre logique si ce n'est chronologique.

Peut être faut il plutôt convenir d'un ordre alphabétique simple,
qui regroupera les github, les gitlab et les git.spip ?

JL

___
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] Installation de bigup par SVP en 3.2

2020-05-27 Par sujet JLuc

> 
https://git.spip.net/spip-contrib-outils/archivelists/src/branch/master/archivelist-externals.txt

pour info ya quelques temps j'y ai ajouté un dépot gitlab

et donc c'était le premier dépot non github

et ça marche : il est présenté sur plugins.spip et par svp !

JL

Le 27/05/2020 à 09:51, Cerdic a écrit :

Il faut lire mon mail au complet, qui se terminait notamment par la phrase

 > comme ça il sera aussi présent dans le depot spip-zone

Il n’y a plus de depot externals, les plugins concernés sont intégrés dans le 
depot spip-zone.
Cf par exemple : 
https://files.spip.org/spip-zone/externals/tarteaucitron-3eb34-v0.3.2.zip

Feu le dépôt externals était un pis-aller parce qu’on était pas capable de tout faire au même endroit en mixant 
différentes sources.


--
Cédric
Le 26 mai 2020 à 21:43 +0200, RealET , a écrit :

Cerdic a écrit le 24/05/2020 à 11:26 :

Le mieux c’est de l’ajouter là
https://git.spip.net/spip-contrib-outils/archivelists/src/branch/master/archivelist-externals.txt
(avec l’url git.spip.net ou github, comme tu veux)

Je veux bien.
Mais externals n'est plus listé dans
https://plugins.spip.net/spip.php?page=depots

Est-ce qu'il continue quand même à être généré ?

Ça reste bancal...

--
RealET


___
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] Grille boostrap 4 / SpipR

2020-05-24 Par sujet JLuc

Le 22/05/2020 à 21:45, Stephane Santon a écrit :

Je les ai reporté sur une nouvelle page du wiki 
https://contrib.spip.net/Bootstrap4-5279

L'information était plus ou moins présente ici : 
https://contrib.spip.net/BootStrap-pour-SPIP
Mais comme la doc principale de SpipR est sur https://spipr.nursit.com/ , je 
cherchais sur nursit en vain.



Je pense que l'on pourrait reprendre et mettre à jour tout l'article
https://contrib.spip.net/BootStrap-pour-SPIP
pour bootstrap 4. (déjà mettre à jour le passage de LESS à SCSS)


Je t'ai ajouté dans les rédacteurs de cet article, aux côtés de Cerdic qui n'a 
dit mot.

Je crois que ainsi tu peux donc améliorer l'article. Peux tu confirmer ?

Si tu as un quelconque doute sur les modifications que tu apportes,
stp demande ici ou par un commentaire sous l'article
et stp aussi signale les modifications douteuses ou simplement osées que  tu as 
fait :-)

Bonne re-rédaction !
JLuc

___
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] Tri par défaut sur les boucles

2020-05-23 Par sujet JLuc

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

Le tri par dé  {par num titre, titre} de
https://programmer.spip.net/Appliquer-un-tri-par-defaut-sur

est-il implémenté dans Spip 3.2 par défaut sur définition d'une constante ?


Non c'est juste un exemple de possibilité parmi des milliers d'autres possibles.


Ou bien faut-il réécrire tout le code de cet article pour l'intégrer à mon site 
?


Pas le réécrire mais le recopier et l'adapter, avec toutes les variations 
souhaitées ensuite.

JL


___
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] Grille boostrap 4 / SpipR

2020-05-22 Par sujet JLuc

Le 20/05/2020 à 14:16, Cerdic a écrit :

Non le chemin qu’il faut prendre c’est css/_hashgrid.scss


Ces questions/réponses me semblent bien cernées et utiles pour qui utilise 
bootstrap4.

Je les ai reporté sur une nouvelle page du wiki 
https://contrib.spip.net/Bootstrap4-5279
Ici le contexte m'est apparu assez simple et ton expression claire :
je pense donc que cette doc est correcte.

Ça n'est pas suffisant pour un "article" sur contrib,
donc ça semble bien à sa place dans le wiki.

Mais cette page pourrait collecter d'autres savoirs sur bootstrap4
que toi ou d'autres utilisateurs apporteraient au fil de leurs découvertes
et lorsqu'il y aura... mettons 5 points abordés comme celui-ci,
ça pourrait faire un article qui se tiendrait bien et qui pourrait sortir du 
wiki.

Donc bienvenue aux partages !

JL


Le 20 mai 2020 à 14:05 +0200, Stephane Santon , a écrit 
:

Bonjour,

Le 20/05/2020 à 09:37, Cerdic a écrit :

C’est le plugin BootStrap qui l’insère, elle s’affiche avec la touche G
et G+F pour la passer en foreground, elle ne s’insère que pour les
admins connectés, comme les boutons d'admin


Super ! Merci :-)


Il y a une feuille de style qui s’appelle hashgrid et que tu peux
personaliser si ta grille est spécifique.


Je surcharge bien par un fichier bootstrap2spip/css/_hashgrid.scss dans
mon plugin ?
Je n'arrive pas à voir les effets de la surcharge...
(si je mets un fichier _hashgrid.Scss vide, la grille est toujours là)

Merci



--
Stéphane
17 Charente-Maritime
___
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] Lien entre les articles du Wiki et les articles de doc

2020-05-21 Par sujet JLuc

Le 20/05/2020 à 14:52, Eric Lupinacci a écrit :

Le 20 mai 2020 à 10:06, JLuc  a écrit :
**Et pour cela il faut arrêter de le dénigrer**
**et le valoriser comme espace de coopération**

Je ne dénigre pas je constate.


Je dis pas ça spécialement pour toi mais les seules expressions des membres de la core team a propos du wiki c'est des 
plaintes (ce qui se comprend vu que ces experts spip n'ont que peu besoin de doc à titre personnel).

Heureusement on lit aussi régulièrement que des spipeurs ont trouvé leur compte 
dans cette doc alternative.


et favoriser les rencontres sur ces docs,
entre besoins-initiateurs-de-pages et sachants-finalisateurs-de-pages.
Pistes : des docathons ? des pages highlightées avec appel à finalisation ?


> Qui empêche les gens de créer des groupes de travail, de poser des questions à d’autres pour essayer de compléter les 
articles du carnet ? Qui ? [] pourquoi attendre pour organiser ?


Si cette discussion pouvait déboucher sur ce genre de chantier ce serait une 
belle issue.

Pour accoucher une page de qualité du wiki, il faut
- que le sujet abordé recueille l'intérêt et comble un manque
- cadrer le contenu abordé
- améliorer la structure de la présentation (si besoin)
- valider les connaissances partagées, corriger les erreurs techniques, 
apporter les connaissances manquantes
- élargir la perspective technique pour situer cette page dans le contexte 
technique plus global de SPIP

Il faut donc des compétences variées.
Ça suppose des échanges, des moyens d'informations, un processus de progression,
depuis le choix de la page jusqu'à sa proposition à la publication hors wiki.


Il faudrait surtout que leur auteurs aient envie de la finir…
Peut-être aussi un peu de courage et de temps à donner...

Tout le monde en a plein la bouche de la collaboration en oubliant quand même 
que la base c’est une équipe tendue vers un même objectif.
Ce n’est pas des individus qui déposent quand ils le souhaitent, ce qu’ils 
souhaitent où il le souhaitent.
Pour moi c’est une différence fondamentale et je ne crois pas qu’un jour on se 
retourne sur ce point.


Ya en effet une difficulté que le carnet n'a pas dépassé.
conjuguer l'effet "zone" avec une "collaboration",
pour que "quand on veut ce qu'on veut" bénéficie aussi de l'effet "équipe".

Il y a le loomio pour les groupes de travail, mais je trouve que ça ne correspond pas à l'esprit "agora" qu'est la zone 
et contrib. Et puis à force, s'isoler en petit groupe conduit à l'épuisement.


Plutôt que des groupes de travail sur leur outil dédié,
j'imaginerais plutôt des temps d'attention largement partagés,
focalisés sur des pages précises ou des besoins précis.
Ça pourrait commencer par un mail sur cette liste.


J’ai passé des mois sur Contrib.
J’ai eu l’aide de Maieul.
On est loin d’avoir fini mais ça n’intéresse personne de finir le boulot c’est 
tellement plus simple de continuer le carnet.
Alors bon courage pour la suite mais moi Contrib c’est du passé, je vous le 
laisse.


Houmpf c'est dur.


:-(



JL



++
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




___
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] Lien entre les articles du Wiki et les articles de doc

2020-05-20 Par sujet JLuc

Le 19/05/2020 à 18:28, Eric Lupinacci a écrit :

Je suis absolument en ligne avec Maieul et je pense que si toi et d’autres 
tenants du wiki à outrance vous passiez un peu de temps à maintenir l’éditorial 
de ce site (au sens large) vous changeriez peut-être d’avis.


Je comprends que tu parles du site contrib dans son ensemble, là,
mais ce n'est pas le sujet, ou sinon quel est le rapport ?

Chacun a ses priorités, sa sensibilité, et il ne faut pas s'attendre à ce que 
ça soit universellement partagé
(sinon on aboutit aux regrettables orthodoxies dogmatiques).

Ta priorité va à "maintenir l'éditorial". Soit. Je respecte et c'est utile.
Concernant le code de spip, ma sensibilité semble m'amener à vouloir 
documenter-éclairer les parties obscures
et à recueillir les bribes de savoirs lorsqu'ils sont exprimés sous une forme 
brute et éphémère,
afin de les mettre en forme et partager plus largement.
J'y parviens plus ou moins bien, et parfois pas.


Il y a une facilité à l’utilisation du wiki qui malheureusement confine à 
éterniser le temporaire, à disperser l’information, à la rendre presque 
invisible, donc inaccessible, donc inutile in fine.


Oui il y a beaucoup de wiki-tentatives de documentation qui n'aboutissent pas 
totalement.

Mais plutôt que dénigrer ce bac à sable, il faudrait voir comment aider ces 
contributions à gagner en qualité.

Car, comme je l'écrivais chacune de ces contributions a été faite à un moment 
parce qu'il y avait un ou des besoins :
  besoin de doc (par lacune de la doc non wiki)
  et besoin de consigner durablement une expérience ou un élément de savoir.


Quand de plus certaines personnes s'érigent en gardiennes intransigeantes de 
l'orthodoxie de la documentation,
et refusent toute entrave à leur propre conception de ce que doit être une doc 
(cf autre thread récent),
il est clair que les pages du wiki ne sont pas prêtes d'en sortir : elles 
dérangeraient trop !


Tu exagères.
Comme je te dis mets les mains dans laye cambouis de Contrib comme le fait 
Maieul et après on en discute.


Je suis admin de contrib et je régulièrement je relis et commente les articles 
et améliore l'expression ou la mise en page.

Je suis également admin de programmer.spip et j'ai passé un temps à trier les nombreux tickets déposés (qui concernent 
le rédactionnel de programmer.spip, pas le code).

Au bout d'un moment, il s'est passé la même chose qu'avec le wiki de contrib :
je n'ai pas les savoirs suffisants pour faire avancer les tickets, trancher "valable" ou "pas 
valable" ou "ya mieux",
ou améliorer.

Au final les tickets-doc qui restent dans programmer.spip sont comme ces pages 
du wiki de contrib.spip :
  l'expression de besoins ou d'éléments de savoirs
  qui ne rencontrent pas l'intérêt de ceux qui pourraient répondre et les faire 
avancer.

> Aider c’est aussi participer à une logique qui n’est pas personnelle et qui peut obliger parfois à se plier à des 
règles pour le bien de tous.


Chaque espace a ses règles, et le wiki est un espace avec des règles bien 
particulières,
puisque c'est le seul espace totalement ouvert et pleinement coopératif.
Précieux !

La logique du wiki de contrib, c'est d'être un espace de contribution, de collaboration éditoriale, de partage de 
travaux en cours et de maturation.


Alors Ok on peut y faire le ménage, virer quelques pages visiblement stériles,
mais la question essentielle, c'est "comment faire en sorte que plus de docs 
finalisées sortent du wiki ?".

**Et pour cela il faut arrêter de le dénigrer**
**et le valoriser comme espace de coopération**
et favoriser les rencontres sur ces docs,
entre besoins-initiateurs-de-pages et sachants-finalisateurs-de-pages.

Pistes : des docathons ? des pages highlightées avec appel à finalisation ?


Mais pour qu'une page sorte du wiki, il faudrait
- que leurs auteurs accèdent à la connaissance complète et sans entrave de ce 
qu'ils documentent
- complètent leur documentation d'une manière acceptable pour être rendue 
visible au grand jour
- ou bien que des mieux-sachants acceptent de considérer les interrogations qui 
se posent, et de corriger les errements
tant dans la forme que dans le contenu.



Il faudrait surtout que leur auteurs aient envie de la finir…
Peut-être aussi un peu de courage et de temps à donner...


Il est certain que l'envie, le courage et le temps permettent de terrasser bien 
des dragons.
Mais confier cette charge aux auteurs seuls c'est accorder peu d'intérêt au 
pouvoir de la collaboration.
Chacune de ces pages est un appel à coopération.

JL

___
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] Lien entre les articles du Wiki et les articles de doc

2020-05-19 Par sujet JLuc

Le 19/05/2020 à 12:29, Maïeul Rouquette a écrit :

Non, si c'est dans le wiki c'est temporaire.
Si cela devient utile, alors on reecrit l'article principale pour intégrer.


Je ne suis pas d'accord avec cette compréhension du wiki, et de fait il y a plein d'articles dans le wiki qui y restent 
longtemps et n'en sortent jamais.


Lorsque je crée un article quelque part,
c'est parce qu'il y a un savoir ou une expérience à partager.
Le texte créé est un témoignage ou un élément de savoir dont je pressens qu'il 
peut être utile,
pour moi ou pour d'autres, tout de suite ou plus tard.

Si je crée cet article dans le wiki, c'est parce que le savoir que j'ai à partager à ce sujet est parcellaire, 
insuffisant ou incertain, et que je ne peux pas préciser plus, faute de savoir,

et parce que j'aimerais des précisions, et que j'espère pouvoir compléter 
ensuite,
et pourquoi pas aussi j'espère que quelqu'un d'autre de mieux sachant que moi 
complétera ensuite.
Cette dernière possibilité ne se réalise qu'un nombre fini de fois par rapport 
aux besoins (quasi) infinis
et donc il y a une grande majorité de pages du wiki qui ne sortent jamais d'un 
état non abouti.

La documentation se heurte en effet à une difficulté congénitale :
c'est que les personnes qui sont le mieux en capacité de la créer, sont aussi 
celles qui en ont le moins besoin
- du moins sur ce sujet -
Les conséquences sont lourdes, et ceci quel que soit l'importance affirmée haut 
et fort du rôle de la doc.

Quand de plus certaines personnes s'érigent en gardiennes intransigeantes de 
l'orthodoxie de la documentation,
et refusent toute entrave à leur propre conception de ce que doit être une doc 
(cf autre thread récent),
il est clair que les pages du wiki ne sont pas prêtes d'en sortir : elles 
dérangeraient trop !

Pour un grand nombre de page, ce n'est que justice, car ces pages sont des bribes, des balbutiements, des tâtonnements, 
des notules ou de grands chaos informes.


Parfois tout de même, c'est dommage, car ok le contenu n'est pas au point,
mais la page témoigne d'un besoin réel qui n'est pas satisfait par la doc 
"officielle".

Mais pour qu'une page sorte du wiki, il faudrait
- que leurs auteurs accèdent à la connaissance complète et sans entrave de ce 
qu'ils documentent
- complètent leur documentation d'une manière acceptable pour être rendue 
visible au grand jour
- ou bien que des mieux-sachants acceptent de considérer les interrogations qui 
se posent, et de corriger les errements
tant dans la forme que dans le contenu.

Il semble que ces conditions ne soient pas satisfaites dans l'état actuel de la répartition des savoirs et des 
disponibilités.


JL


___
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] r124584 - _plugins_/saisies/trunk

2020-05-08 Par sujet JLuc

Le 08/05/2020 à 17:51, spip-zone-com...@rezo.net a écrit :

Author: RastaPopoulos Date: 2020-05-08 15:51:42 + (Fri, 08 May 2020) New 
Revision: 124584
Modified:
_plugins_/saisies/trunk/saisies_pipelines.php
Petit ajout sympa permettant de remplir les champs avec la config quand on 
detecte que c'est un form configurer_XXX. (issue9 maieul) Si on necessite la 
bonne version de saisies, on n'a donc plus besoin de remplir soi-meme avec des 
lire_config dans le defaut, ca simplifiera 99% des cas.


Super !

Mais il me semble qu'il faut === et non ==
dans strpos($flux['args']['form'], 'configurer_') == 0

JL


Details: https://zone.spip.org/trac/spip-zone/changeset/124584




___
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] Formulaire de configuration d'un plugin : Enregistrer ?

2020-05-06 Par sujet JLuc

Le 05/05/2020 à 23:43, Stephane Santon a écrit :

Ça marche bien mieux comme ça forcément... :-D
Mais sur les 6-7 articles de https://www.spip.net et https://contrib.spip.net que j'ai scrupuleusement parcourus, rien 
ne m'a fait penser à ça !


Ya un exemple dans la page de doc complémentaire du wiki :
https://contrib.spip.net/Doc-Saisies-complementaire#autocvt

Certaines pages du wiki sont des trésors.
JL



Donc c'était bien enregistré, mais pas rappelé au rechargement du formulaire...

Eh bien merci merci merci


Le 05/05/2020 à 23:28, Maïeul Rouquette a écrit :

Voilà ce que j'ai personnelement

/**
 * Un simple formulaire de config,
 * on a juste à declarer les saisies
**/
function formulaires_configurer_plasci_saisies_dist(){
include_spip('inc/config');
$saisies = array(
    array(
    'saisie' => 'textarea',
    'options' => array(
    'nom' => 'connaissance_activite',
    'label' => _T('plasci:connaissance_activite_label'),
    'explication' => 
_T('saisies:option_datas_sous_groupe_explication'),
    'defaut' => lire_config('plasci/connaissance_activite'),
    'rows' => 10
    )
    )
);
return $saisies;
}


ca marche tout seul, et ca me suffit.

Donc franchement je saisi pas où le problème.





___
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] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-05-05 Par sujet JLuc

Je n'avais pas fini mon mail. Voici :

Le 30/04/2020 à 23:12, RastaPopoulos a écrit :

C'est assez simple pourtant :
- ya déjà une doc existante qui contient des *exemples concrets* pas du tout 
abstraits ou que sais-je que tu t'imagines tout seul
Ce que j'écris je l'écris tout seul avec mon clavier, et je l'imagine tout seul, comme toi quand tu te sers d'un clavier 
aussi.



- la doc proposé par Jean-Marie est un simple exemple concret

Je dirai mieux : c'est un exemple concret et simple.


- donc si on l'intègre c'est en améliorant l'existant, ya pas à lister 40 
exemples à la fois pour dire 40 fois la même chose juste avec d'autres noms de 
champs…
- là ya déjà 3 exemples, perso je trouve ça déjà trop compliqué (des ajouts sur 
des ajouts), donc on peut même simplifier l'article existant, améliorer c'est 
pas que rajouter hein, en mettant moins d'exemples (même revenir à un seul mais 
plus complet ?)


Cette manière très structurée de présenter les choses donne l'impression d'une grande clarté et l'exposé est de ce fait 
assez convaincant.


Mais plus complet ne veut pas dire mieux si ça devient moins accessible.

Il y a plein de manière d'accéder à l'information et de se l'approprier.

Des articles que tu as rédigé me sont totalement hérmétiques alors qu'ils ont 
l'air très clairs et bien structurés.
Je pense par exemple à la doc du plugin "http" sur l'API REST : alors que j'ai déjà codé et utilisé nombre d'APIs, je 
n'arrive pas du tout à rentrer dans ton article http://contrib.spip.net/4466


Un référentiel complet ne remplace pas un tutoriel simple dans lequel on rentre sans effort et dont on fait rapidement 
le tour.



On parle pas de PDF qu'on peut pas modifier là… on parle d'un site en SPIP dans 
lequel on peut continuer d'éditer et améliorer les articles existants. Le but 
c'est pas d'accumuler des couches et des couches similaires, on ajoute un 
article s'il dit vraiment un nouveau truc différent à priori.


On parle pas non plus du mode d'emploi technique d'un moteur de machine à laver 
construit par une multinationale,
ou une super application genre stopcovid codée par la crème des startup (lol) et pour laquelle les critères de qualités 
AFNOR xxx s'appliquent.


Les couches ici ne sont pas similaires,
les articles sont très différents,
de même que les spipeurs ne sont pas similaires.

SPIP c'est aussi une communauté d'utilisateur, et contrib.spip.net, comme son nom l'y invite, est un lieu privilégié 
pour l'expression des talents multiples et variés des spipeurs. Pouvoir intégrer ces divers talents au mieux est une 
grande force pour un logiciel libre, et il faut aussi prendre en compte dans l'évaluation de ce qui est le mieux.


JLuc


___
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] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-05-05 Par sujet JLuc

Le 30/04/2020 à 23:12, RastaPopoulos a écrit :

C'est assez simple pourtant :
- ya déjà une doc existante qui contient des *exemples concrets* pas du tout 
abstraits ou que sais-je que tu t'imagines tout seul

Ce que j'écris je l'écris tout seul avec mon clavier, et je l'imagine tout 
seul, comme toi quand tu te sers d'un.


- la doc proposé par Jean-Marie est un simple exemple concret

Je dirai même mieux : c'est un exemple concret et simple.


- donc si on l'intègre c'est en améliorant l'existant, ya pas à lister 40 
exemples à la fois pour dire 40 fois la même chose juste avec d'autres noms de 
champs…
- là ya déjà 3 exemples, perso je trouve ça déjà trop compliqué (des ajouts sur 
des ajouts), donc on peut même simplifier l'article existant, améliorer c'est 
pas que rajouter hein, en mettant moins d'exemples (même revenir à un seul mais 
plus complet ?)


Cette manière très structurée de présenter les choses donne l'impression d'une grande clarté et l'exposé est de ce fait 
assez convaincant.


Mais plus complet ne veut pas dire mieux si ça devient moins accessible.
Il y a plein de manière d'accéder à l'information.
Des articles que tu as rédigé me sont totalement hérmétiques alors qu'ils ont 
l'air très clairs et bien structurés.
Par exemple :

On parle pas de PDF qu'on peut pas modifier là… on parle d'un site en SPIP dans 
lequel on peut continuer d'éditer et améliorer les articles existants. Le but 
c'est pas d'accumuler des couches et des couches similaires, on ajoute un 
article s'il dit vraiment un nouveau truc différent à priori.



___
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] Paramétrer des paramètres d'INCLURE

2020-05-01 Par sujet JLuc

Le 30/04/2020 à 22:47, Stephane Santon a écrit :

J'aimerais passer à un INCLURE un lot de paramètres qui vient d'un formulaire 
(de configuration).
Y a-t-il moyen d'avoir l'effet de cette syntaxe (qui ne fonctionne pas) :
#SET{crit,'id_article=5,id_rubrique=1'}



Le formulaire renvoyant a priori toujours les mêmes variables
tu peux appeler INCLURE avec tous ces paramètres 1 par 1 :
{ ... id_article=5,id_rubrique=1... }
donc quel est le problème ?

Peut être que ça aiderait à te répondre si tu donnais plus d'éléments du 
contexte.
(pas trop non plus !).

JL

___
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] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-04-30 Par sujet JLuc

Le 30/04/2020 à 21:33, Maïeul Rouquette a écrit :

Le 30/04/2020 à 20:34, RastaPopoulos a écrit :

Le 30/04/2020 à 20:14, JLuc a écrit :

Peut être ça doublonne certaines ou toutes les informations techniques, mais ça 
a l'air beaucoup plus simple.
Et cette simplicité disparaîtrait si on ajoutait encore à la doc déjà présente.


Informations techniques ? Euh le lien avec ancre que j'ai pointé c'est rigoureusement pile la même chose : trois 
exemples concrets de comment déclarer des champs en PHP et comment lancer la fonction d'upgrade. On peut difficilement 
faire plus la même chose c'est la fonction XXX_declarer_champs_extras() avec des exemples de champs dedans, puis la 
fonction XXX_upgrade() avec le lancement des fonctions…


Ya déjà 3 exemples différents dans l'article… je vois mal l'intérêt d'en 
rajouter un 4ème pour dire encore pareil.
- Soit faut mettre à jour l'article existant pour corriger/améliorer avec tel 
ou tel mini point qui manquerait.
- Soit faut carrément tout virer de l'article existant, et mettre tous les exemples dans un article dédié (mais 3 max 
c'est déjà largement suffisant pour tout montrer à priori)


ce que je vois comme intéret de l'article de Jean-Marie est qu'il est hyper condensé. Il s'agit plus d'un memento que 
d'un tuto en fait.


Mais est-ce la peine de le publier sur contrib, je sais pas. c'est la première 
fois que le cas du memento sur pose.


C'est une contribution et c'est un élément de documentation, donc elle a sa 
place sur contrib.

Que les codeurts se prennent a tête avec des critères tellement exigeants 
qu'ils en deviennent ésotériques
-- au point de se dégoûter eux mêmes l'un l'autre et d'arrêter de contribuer 
parfois --
je peux le comprendre si c'est pour aboutir à un code irréprochable.

Mais si les critères de contribution devenaient également trop ésotériques pour 
contrib.spip
ça va restreindre la participation à SPIP aux seuls détenteurs d'une prétendue 
orthodoxie spipement correcte

et ça va serait assez sinistre.

JL

___
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] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-04-30 Par sujet JLuc

Le 30/04/2020 à 19:55, RastaPopoulos a écrit :

Bé ya déjà tout ici dans ce chapitre non ?
https://contrib.spip.net/Champs-Extras-3-API-et-creations#Creer-un-plugin-en-utilisant-les-API-de-Champs-Extras

S'il manque quelque chose, je dirais plus d'ajouter ce qui manque à cet endroit 
plutôt que de refaire un autre article complet qui va doublonner 95% de la même 
chose.


Peut être ça doublonne certaines ou toutes les informations techniques, mais ça 
a l'air beaucoup plus simple.
Et cette simplicité disparaîtrait si on ajoutait encore à la doc déjà présente.

JLuc




___
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] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-04-30 Par sujet JLuc

Le 30/04/2020 à 16:42, jeanmarie a écrit :
je me suis fait une note (à partir des infos trouvées sur plusieurs articles contrib) pour créer des champs extras 
depuis un plugin perso avec Saisies :

https://notes.cousumain.info/Creer-des-champs-extras-depuis-un-plugin-perso-avec-l-aide-de-Saisies


C'est un sujet intéressant et qui mérite des explications.

Est-ce que je le mets quelque part sur contrib ? Si oui, dans la rubrique Les champs extra ? Dans Carnet Wiki (pas sûr 
que ça soit l'endroit idéal pour le retrouver) ?


Oui, sur contrib dans champs extra.

Peut être pourrais tu introduire l'exemple que tu donnes
en expliquant ce qu'il fait et quels champs extra sont gérés par exemple,
et en donnant une capture d'écran du résultat.

JL

___
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] https://git.spip.net/explore/organizations

2020-04-27 Par sujet JLuc

Le 27/04/2020 à 16:44, teamspipfact...@gmail.com a écrit :

du coup aprés éclairage , j'ai lu 
https://files.spip.org/FAQ-pratique-Comment-SPIPer-avec-git-spip-net


Cette doc se veut rassembler les infos utiles en pratique.
N'ayant pas installé le système, je l'ai établie à partir de mon expérience 
seulement
mais mon expérience ne couvre pas toutes les situations possibles
et il y a des incertitudes voire des inexactitudes concernant ce que j'ai pas 
personnellement expérimenté lol.


Warning: Permanently added 'git.spip.net,185.215.171.33' (ECDSA) to the list of 
known hosts.
g...@git.spip.net's password:

du coup j'ai encore loupé un truc ?
dois je m’inscrire sur


J'ai donc l'impression que pour utiliser le protocole ssh comme tu le fais là 
pour cloner
il faut t'inscrire ET déposer une clé ssh publique, comme pour commiter.

Peut être n'est ce pas nécessaire, par contre, avec le protocole https.

Peux tu me dire selon ce que tu testes et tes résultats ?

JL



Faut il s’inscrire pour pouvoir commiter?

Oui, il faut s’inscrire sur git.spip.net et accepter la [charte de la zone 
pour pouvoir commiter -
https://zone.spip.net/trac/spip-zone/wiki/CharteDeFonctionnement]. 
Consultez aussi la charte d’accueil de SPIP




sachant que je ne vais pas commiter mais simplement récupéré les master des 
plugins

merci pour votre patience car je suis une bille ...

--
spipfactory.fr

Perdu dans la Galaxie SPIP ? :https://boussole.spip.net/
---
Tout SPIPeur, qui fait quelquechose,
a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément 
le contraire,
et surtout la grande armée des gens, beaucoup plus sévéres, qui ne fait rien.
Merci a ceux qui font.





___
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] Problème enregistrement clé SSH sur git.spip

2020-04-25 Par sujet JLuc

Le 25/04/2020 à 10:19, Maïeul Rouquette a écrit :

Le 25/04/2020 à 09:52, Eric Lupinacci a écrit :

Je pense que c’est un peu normal qu’il n’accepte plus une clé qu’il considère 
avoir déjà été utilisée.


Pourtant à ce que je sache, une clé n'est pas conçue comme "jetable".

>> Plutôt que de passer des heures à se demander pourquoi ou si c’est un bug, 
je serais toi, j’en recréerais une et je
>> l’associerais à ton compte gitea et basta.

Certes, mais abandonner la comprenette ne présage pas du grand bonheur pour la 
suite !

Enfin ok, j'ai créé une nouvelle clé SSH, l'ai déclarée à mon agent ssh et à 
git.spip
(sans supprimer localement mon ancienne clé).

Ensuite pour info : je n'ai pas pu pusher depuis mon ancien repo :
j'en déduis que chaque repo est associé qqpart à la clé avec laquelle il a été 
créé.

J'ai donc du à nouveau git cloner et refaire le commit depuis ce nouveau repo
et là le push est passé.

Merci

JL

___
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] Problème enregistrement clé SSH sur git.spip

2020-04-25 Par sujet JLuc

Le 25/04/2020 à 09:51, eric a écrit :

Le samedi 25 avril 2020 à 09:07 +0200, JLuc a écrit :

Pour commiter sur git.spip depuis la ligne de commande
pouvez vous me confirmer qu'il faut avoir enregistré une clé SSH dans
les paramètres perso de gitea ?




Je viens de tester avec pseudo/mdp et mail.mdp : pas de soucis pour le
push/poussé.


Peux tu détailler comment tu utilises tes pseudo  et mdp ?

C'est un repo perso, alors son accés est il protégé de la même manière que les 
répos communautaires ?

JL



https://git.spip.net/eldk/test

Je n'ai fait aucune modification de mon profil du côté de git.spip.net
: valeurs de profil par défaut : pas de clef ssh, ni authentification 2
facteurs.

Cordialement,

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] Problème enregistrement clé SSH sur git.spip

2020-04-25 Par sujet JLuc

Pour commiter sur git.spip depuis la ligne de commande
pouvez vous me confirmer qu'il faut avoir enregistré une clé SSH dans les 
paramètres perso de gitea ?

Actuellement, je n'ai aucune clé enregistrée et je n'arrive pas à commiter.
Mais quand j'ajoute ma clé publique, gitea indique
"Cette clef SSH a déjà été ajoutée au serveur."
ce qui n'est pas faux puisque je l'avais ajoutée il y a longtemps,
mais elle a été supprimée depuis et n'est plus enregistrée actuellement.

C'est un problème gitea et camille peut régler ça ?
Il faut que je signale un bug sur le bugtracker de gitea ?
Il faut que je crée une nouvelle clé pour contourner ce bug ?
Ou il y a qqchose de préférable, qui m'échappe ?

JL


___
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] Pusher un tag

2020-04-21 Par sujet JLuc

Le 16/04/2020 à 23:08, Maïeul Rouquette a écrit :

Le 16/04/2020 à 22:40, Eric Lupinacci a écrit :
Je pense que git push pousse par défaut uniquement ton master. Or la tu veux pousser un tag. Donc il faut pousser tous 
les tags en faisant git push --tags



oui, et je conseillerai de faire dans l'ordre
git push
git push --tags

et pas l'inverse (je crois que j'ai eu des problèmes de synchros svn dans 
l'autre sens

Pour info, je reporte les informations pratiques utiles de base sur
https://contrib.spip.net/FAQ-pratique-Comment-SPIPer-avec-git-spip-net

JL

___
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] r124262 - in _plugins_/scssphp/trunk

2020-04-20 Par sujet JLuc

Le 20/04/2020 à 13:07, Maïeul Rouquette a écrit :

Mise a jour de la lib ScssPHP avec notamment de belles optimisations de rapidite
Details: https://zone.spip.org/trac/spip-zone/changeset/124262

C'est normal tout ces antislashs ?


c'est le but du commit. cf https://github.com/scssphp/scssphp/issues/96
JL


___
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] Pusher un tag

2020-04-20 Par sujet JLuc

Le 20/04/2020 à 11:20, Maïeul Rouquette a écrit :
a priori tu n'a pas à supprimer le tags, on garde les tags historiques. 


Du coup dans 2 ou 10 ans on se retrouvera comme avec formidable et saisies 
aujourd'hui :
avec plein plein de tags, la plupart étant inutilisés.
Quand même on garde tout ?
JL

___
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] Pusher un tag

2020-04-17 Par sujet JLuc

Le 17/04/2020 à 12:39, nicod_ a écrit :
merci pour ces précisions.
(j'avais effectivement suivi ce que dans un précédent mail tu indiquais faire : un simple 
"git push").
JL


Le 16/04/2020 à 21:53, JLuc a écrit :

Bonjour,

suite à un petit fix sur facteur, j'ai créé hier localement un tag :
git tag -a v4.0.4 -m "Les sujets des mails peuvent désormais contenir des '?' même 
avec l'option 'convertir en iso'"
que j'ai ensuite pushé
git push
mais aprés 24h+ il n'est pas arrivé sur git.spip : 
https://git.spip.net/spip-contrib-extensions/facteur#


Chez moi un git push envoie le tag aussi, en vérifiant ma config je me rends compte que ça doit être à cause de ce 
paramètre dans ~/.gitconfig :


[push]
 default = simple
 followTags = true


En fait, j'ai repris une bonne partie de la config proposée par Delicious Insight, ainsi que leur prompt (un peu 
adapté), super utile :

https://delicious-insights.com/fr/articles/apprendre-git/
(dans Installation et Configuration, "configuration partagée")




___
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] Pusher un tag

2020-04-17 Par sujet JLuc

Le 16/04/2020 à 23:08, Maïeul Rouquette et _Eric ont écrit :

git push
git push --tags


OK
Malheureusement ça erreur quand je push --tags.
C'est la première fois que je pushe sur git.spip depuis un repo local et non 
via l'API gitea
(avec "git push" ça ne faisait rien mais il n'y avait pas d'erreur car a part 
le tag il n'y a rien à pusher).

J'ai imaginé que la clé ssh que j'avais enregistré il y a plus d'un n'était pas 
la bonne.

Mais impossible d'enregistrer sur https://git.spip.net/user/settings/keys
le contenu de ma clé publique actuelle (~/.ssh/jluc_id_rsa.pub)
de la forme « ssh-rsa B3NzaC1yc2EA... amlvHQQ== j...@no-log.org »

J'ai alors supprimé la clé enregistrée il y a un an, mais toujours pareil.

Le message est "Cette clef SSH a déjà été ajoutée au serveur."
sauf qu'actuellement je n'ai plus aucune clé enregistrée.
Faut il simplement attendre que gitea oublie ma vieille clé ?

JL




___
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] Pusher un tag

2020-04-16 Par sujet JLuc

Bonjour,

suite à un petit fix sur facteur, j'ai créé hier localement un tag :
git tag -a v4.0.4 -m "Les sujets des mails peuvent désormais contenir des '?' même 
avec l'option 'convertir en iso'"
que j'ai ensuite pushé
git push
mais aprés 24h+ il n'est pas arrivé sur git.spip : 
https://git.spip.net/spip-contrib-extensions/facteur#

que faire ?
JL

___
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] [SPIP Zone] Un modèle pour mettre en forme le contenu des newsletters

2020-04-15 Par sujet JLuc

Le 15/04/2020 à 17:00, Jean Marie Grall a écrit :

Du coup, je crée un nouveau dépôt dans 
https://git.spip.net/spip-contrib-extensions ?


Oui ! c'est la nouvelle zone.

JL

___
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 : deux prefix différents, donc deux plugins différents

2020-04-15 Par sujet JLuc

Le 15/04/2020 à 14:16, Jean Marie Grall a écrit :

Le 15/04/2020 à 14:04, Maïeul Rouquette a écrit :
Si on supprime les tags des anciennes versions, cela veut dire qu'on cesse de la supporter/distribuer officiellement 
et cela aurait du sens à ce moment là de dépublier l'article sur contrib. 

On ne peut pas simplement laisser le zip de la dernière version pour conserver 
la doc en ligne ?


En effet si le système de gestion avec débardeur et git tag n'est pas adapté à 
des situations marginales,
ça ne devrait empêcher de faire autrement.

Ça peut être utile d'avoir ce zip en dehors de tout systeme de tag et mise à 
jour.
Le zip n'est alors pas un rouage de la machinerie générale de release et mise à 
disposition,
mais un document associé à un article, jouant le rôle d'une annexe dans une 
documentation historique.

JL

___
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] oups ? vs ’

2020-04-15 Par sujet JLuc

Le 15/04/2020 à 00:47, Charles Razack a écrit :

Bizarrement dans l'explorateur de fichiers de gitea le problème n'est
pas présent :
https://git.spip.net/spip-contrib-extensions/facteur/src/branch/master/inc/Facteur/FacteurMail.php#L107
geany, gedit et vscode donnent aussi le bon charset sans problème d'accent.


De même que le diff svn : 
https://zone.spip.org/trac/spip-zone/changeset/124189/spip-zone

JL


Fausse alerte juste sur l'affichage du diff dans gitea ?



J'ai donc corrigé via l'éditeur interactif de gitea...
et ça a donné des saletés sur ce caractère
mais aussi sur d'autres caractères accentués des commentaires
https://git.spip.net/spip-contrib-extensions/facteur/commit/503ca152f1b3b55ffc576a1efba084602aa8c36d


___
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] oups ? vs ’

2020-04-14 Par sujet JLuc

Voulant corriger un problème de charset dans la v4 (test) de facteur,
j'ai peut être introduit des problèmes bien pires de charset.

Il fallait simplement corriger un ? en ’
pour régler https://git.spip.net/spip-contrib-extensions/facteur/issues/3
J'ai donc corrigé via l'éditeur interactif de gitea...
et ça a donné des saletés sur ce caractère
mais aussi sur d'autres caractères accentués des commentaires
https://git.spip.net/spip-contrib-extensions/facteur/commit/503ca152f1b3b55ffc576a1efba084602aa8c36d

Oups.

J'ai alors cloné localement le repo pour mieux y voir et corriger la correction,
mais tout à l'air bon dans la version locale du fichier après mon fix :
geany détecte un fichier utf8 et il n'y a aucun pataquès cacaoteux à la place 
des ’ dans le code
ou des ê dans les commentaires.

Du coup qu'est-ce donc qui ne va pas ?
l'UI gitea s'égare dans les charset ? ou le fichier est marabouté ?
Je sèche là.

JL

___
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] Recherche dans SVP...

2020-04-10 Par sujet JLuc

Le 10/04/2020 à 09:45, Eric Lupinacci a écrit :

Non je ne pense pas que ce soit spécifique.

Suspense... Qu'est ce qui te fait penser ça ?


Par contre faudrait comparer les versions de SPIP.

Demo.spip est en SPIP 3.3.0-dev SVN [24556]
Sur un de mes sites en SPIP 3.3.0-dev [24422] c'est pareil, la recherche de 
plugins marche comme il faut.

JL


Le 10 avr. 2020 à 09:32, JLuc  a écrit :

Le 09/04/2020 à 21:53, nicod_ a écrit :

je suis perplexe : je cherchais à installer photoswipe par SVP.
Je cherche "photo", je trouve "Outdoor" et "Metadonnées photo"
Je cherche "swipe", je ne trouve rien.
Avec "photoswipe", il apparait bien.
C'est une recherche par mot exact ?


Sur demo.spip.net, ça se passe mieux :
"photo" renvoie 5 plugins, dont photoswipe.
"swipe" renvoie 2 plugins : photoswipe et swiper.

Ça semble un problème spécifique à ton site ?


JLuc

___
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] Recherche dans SVP...

2020-04-10 Par sujet JLuc

Le 09/04/2020 à 21:53, nicod_ a écrit :

je suis perplexe : je cherchais à installer photoswipe par SVP.

Je cherche "photo", je trouve "Outdoor" et "Metadonnées photo"
Je cherche "swipe", je ne trouve rien.
Avec "photoswipe", il apparait bien.

C'est une recherche par mot exact ?


Sur demo.spip.net, ça se passe mieux :
"photo" renvoie 5 plugins, dont photoswipe.
"swipe" renvoie 2 plugins : photoswipe et swiper.

Ça semble un problème spécifique à ton site ?


JLuc

___
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] moicubitus et les zips et le wiki et ...

2020-04-09 Par sujet JLuc

Le 09/04/2020 à 14:38, Maïeul Rouquette a écrit :

Le 09/04/2020 à 13:58, Eric Lupinacci a écrit :

Je ne suis pas sur qu'il faille se polariser sur ce sujet.
La refonte de Contrib qui va se poursuivre par l'espace public et l'intégration 
de Plugins SPIP doit régler ce sujet :


Pas de pb. La requete n'a rien d'urgent mais dans cette période transitoire il n'est pas évident (pour le moins) de dire 
ce qui est pertinent et à l'ordre du jour dans les pb constatés, ou ce qui ne l'est pas.


JL

___
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] moicubitus et les zips et le wiki et ...

2020-04-09 Par sujet JLuc

Petit problème sur l'article « La mutualisation facile : modifications 
manuelles »
https://contrib.spip.net/ecrire/?exec=article_article=2192
où un utilisateur moicubitus ajoute depuis peu des zips 1.4.5 et 0.10.4
sans retirer leur version précédente.

PS :
Ce 1er article est sur le wiki, c'est une "Documentation provisoire du Plugin « 
mutualisation »
décrit [finalement] dans la Ferme à SPIP"
Ce 2eme article "https://contrib.spip.net/Ferme-a-SPIP; propose lui aussi ces 
zips,
mais en un seul exemplaire pas mis à jour récemment.

Il est certainement possible de virer ponctiuellement les différents zips de la 
version wiki
mais peut être y a t il quand même un problème plus général à régler...

JL


___
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] bug autorité

2020-04-05 Par sujet JLuc

Le 05/04/2020 à 10:25, Bruno Bergot a écrit :

Le bug a été introduit par le commit suivant :
https://git.spip.net/spip-contrib-extensions/autorite/commit/1a3cc250c9786ee46e31235045dfaeeab9612ae8
Cela vient du fait que l'autorisation fait un echo 
'val='.$GLOBALS['autorite']['redacteurs_voir_auteurs'].'!';
Jean-Luc pourra certainement ce qu'il souhaitait faire avec ça, mais je ne pense pas qu'il souhaitait publier ce bout de 
code en l'étant :p


En effet c'est un [rz]este de trace pour mise au point.
Je peux encore corriger via svn commit ?

JL

___
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] Archivelists

2020-04-04 Par sujet JLuc

Le 04/04/2020 à 12:23, Cerdic a écrit :
suite à la mise en place du debardeur, les fichiers archivelists*.txt ainsi que le fichier traductions.txt de salvatore 
ont été supprimés du repository SVN et sont maintenant gérés sur le projet git

https://git.spip.net/spip-contrib-outils/archivelists

A noter que pour le debardeur seuls les projets développés hors git.spip.net 
doivent être ajoutés dans le fichier
https://git.spip.net/spip-contrib-outils/archivelists/src/branch/master/archivelist-externals.txt

Tous les projets de git.spip.net sont automatiquement pris en compte sans 
aucune déclaration

Dans le répertoire legacy/ https://git.spip.net/spip-contrib-outils/archivelists/src/branch/master/legacy on retrouve 
les fichiers archivelist qui étaient sur le svn.


Seuls servent encore le fichier principal et le fichier grenier.
Idéalement on ne devrait plus rien y ajouter et ne faire que supprimer des lignes au fur et à mesure que l’on pose des 
tags sur les projets git.


Serait il possible d'ajouter ces explications dans un readme dans les dossiers 
archivelist svn et git ?

PS : c'est cool que ça avance
JLuc

___
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] Tous en débardeur !

2020-03-31 Par sujet JLuc

Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :

gogogogo


certes


Et pour celles et ceux qui ont oublié de tagguer correctement leur
projet. On a un outil qui permet de détecter tous les changements de
version écrits dans paquet et plugin.xml et d'en faire de beaux tags
git.


Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
et à ma connaissance ça n'était pas incorrect.

Qu'est ce que c'est donc que taguer correctement un projet ?


JL

___
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] API Objet et id_parent

2020-03-31 Par sujet JLuc

Le 31/03/2020 à 15:38, Eric Lupinacci a insisté
sur la distinction entre la notion de conteneur et la notion de hiérarchie.

Ça me rappelle effectivement de vagues  souvenirs des ambiguités dans la notion de 
"parent";
et par ailleurs des difficultés irréductibles à intégrer dans quels sens 
marchent les liens d'une table objet_liens
et aussi la notion de portfolio pas mauvaise en elle-même mais totalement 
pourrite par l'incohérence de l'UI.

+1 Assainissement et renforcement du noyau
+1 Être compréhensible et pas couper les cheveux en 42 pour des cas rares
+1 Des plugins pour aller plus loin
+1 Pas faire des rubriques, des forums et des groupes de motclés des cas 
particuliers

Et donc
+4 un noyau sain et fort mais pas totalement polyvalent,
et déléguer à un plugin les raffinements et perfections rarement utiles
Reste à définir lesquelles !

JL



___
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] [écran de sécurité] Bloquer les appels avec paramètre base64_XXX

2020-03-31 Par sujet JLuc

Le 31/03/2020 à 15:49, Jean Marie Grall a écrit :

Tu peux tuer les requêtes qui contiennent la chaîne par le htaccess
avec (pas testé) quelque chose comme ça :

RewriteCond %{QUERY_STRING} image\/php;base64
RewriteRule .* - [F]

je vois pas quels mauvais effets seconds il peut y avoir...


Je vais tester ça, oui pas bête, peut être avec base64_decode pour limiter les effets de bord car il y a des plugins qui 
utilisent base64, mais je ne sais pas s'ils passent par des urls...

Il faut tester quelque chose qui se trouve dans l'url non décodée.

JLuc

___
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] code.spip : recherche sensible à la casse

2020-03-31 Par sujet JLuc

Le 31/03/2020 à 10:31, Matthieu Marcillaud a écrit :
Alors justement y a eu une discussion IRC hier à propos de ça. C’est peut être pour ça que tu réagis. 


Non c'est juste suite à la recherche citée plus haut, échouée ce matin


Et aussi parce que ça cherche le mot exact si on cherche "balise GET" ça ne  
trouvera pas.
Comme je disais ...
Donc faudrait déclarer un :icontains() insensible à jQuery (en faisant des strtolower de part et d’autre), exploser $q 
Ça me parait un peu relou (et en plus ça va faire ramer la recherche encore plus)


Gérer les espaces et la non-sensibilité à la casse sont 2 choses différente.

Dans SPIP les recherches séparent les différents mots et c'est très smart.
Mais pour le code, ça me semble moins nécessaire.
Si les espaces sont pas gérés smarts, le site peut éventuellement l'indiquer
et l'utilisateur en tiendra compte sans trop de regrets à mon avis.

Gérer la non sensibilité à la casse me semble plus utile
(et ç'a l'air beaucoup plus simple en terme de code aussi.)

JL

PS pour b_b : j'ai causé là et pas sur core parce que... euh,
ça permet parfois d'avoir une réponse vivante
et sinon oui je reporterais dans un ticket si je crois toujours que ça mérite 
la durée.

___
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] code.spip : recherche sensible à la casse

2020-03-31 Par sujet JLuc

Sur code.spip.net je vois que la recherche est sensible à la casse :

https://code.spip.net/spip.php?page=recherche=balise_get
ne donne aucun résultat

il faut
https://code.spip.net/spip.php?page=recherche=balise_GET

Ce serait mieux si c'était pas aussi sensible...

...

___
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] [écran de sécurité] Bloquer les appels avec paramètre base64_XXX

2020-03-30 Par sujet JLuc

Le 30/03/2020 à 15:18, Jean Marie Grall a écrit :
Si le blocage ne peut se faire via l'écran de sécu car pas pertinent/possible/souhaitable (biffer les mentions 
inutiles), est-ce que vous voyez une autre solution ? Si les attaques viennent du même pays, les IP ne sont bien sûr 
jamais les mêmes, donc la solution du blocage des IP n'est pas possible. Une solution serait de diminuer la durée du 
cache pour ne pas que ces fichiers restent trainer trop longtemps, mais comment être sûr qu'ils soient bien supprimer ?


Pour demander le renforcement de l'écran de sécu, tu dois demander sur la liste 
spip-dev
ou bien faire un ticket sur https://core.spip.net/projects/spip/issues

Aussi, je m'étonne que seulement 2 de mes sites (de la même structure qui plus est) soient impactés. b_b a fait le tour 
des siens et n'a pas trouvé de fichiers similaires. Si l'envie vous prend de chercher dans vos caches, voilà la commande  > : rgrep "base64_decode" dossier_site/tmp/cache/


Je 'ai pas trouvé non plus sur les miens (cherché via xray).

Tu peux tuer les requêtes qui contiennent la chaîne par le htaccess
avec (pas testé) quelque chose comme ça :

RewriteCond %{QUERY_STRING} image\/php;base64
RewriteRule .* - [F]

je vois pas quels mauvais effets seconds il peut y avoir...
JL



                 jeanmarie


Le 10/03/2020 à 15:48, Jean Marie Grall a écrit :

Salut,

sur les conseils (avisés) de b_b, je vous fais part d'un problème rencontré sur 
un hébergement mutualisé OVH.

Ça fait 2 fois que je me fais désactiver un hébergement par les robots d'OVH pour suspicion de piratage : des fichiers 
de cache sont en cause car ils contiennent des codes moisis.


Après avoir creusé bien profond avec ledit b_b, il s'avère que ces codes correspondent aux paramètres passés en 
arguments des URL appelées lors de tentatives de piratage mais ces paramètre ne sont pas interprétés par SPIP car ils 
concernent d'autres CMS. Et comme ces fichiers ne sont pas des fichiers PHP, ils ne peuvent pas être interprétés par 
PHP en dehors des squelettes où il sont appelés. Mais quand même, le fait est qu'il y a des fichiers avec du 
base64_decode/encode stockés sur l'hébergement.


Dans les logs, on trouve des appels type http://spip.pastebin.fr/61331 ce qui génère des fichiers de cache type 
http://spip.pastebin.fr/61332 (voir L53)

Les paramètres moisis étant passés à l'environnement, on les retrouve, comme 
tout paramètre, dans le cache. Normal.

Après échange bien profond aussi avec le support tech, il s'avère que, même s'ils ne sont pas interprétés, ces codes 
sont interdits sur leurs mutus pour éviter tout problème, donc tant qu'il y aura des tentatives d'attaque, je me ferai 
fermer mon hébergement.


Donc, ma question est : est-ce que l'écran de sécurité ne pourrait pas bloquer ces appels illégitimes (et 
potentiellement dangereux) avec base64_decode/encode dedans ? Sinon, est-ce que vous voyez une autre solution ?


Merci pour vos retours,

                    jean marie





___
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 aux logos

2020-03-27 Par sujet JLuc

Le 27/03/2020 à 00:23, nicod_ a écrit :

Le 26/03/2020 à 21:14, JLuc a écrit :

OK merci.
J'ai complété https://programmer.spip.net/API-des-logos


Je cite :
« Depuis SPIP 3.3, les fichiers téléchargés en tant que logo sont gérés comme des documents avec un mode spécifique 
’logoon’ ou ’logooff’ et sont accessibles dans la médiathèque. »


Non, justement, ils sont référencés comme documents dans la table 
spip_documents mais ne sont pas dans la médiathèque.


Ok j'ai corrigé mais j'ai gardé "gérés" :

« Depuis SPIP 3.3, les fichiers téléchargés en tant que logo sont gérés comme des documents dans la table 
spip_documents, avec un mode spécifique ’logoon’ ou ’logooff’. »


Ceci dit, à terme, la médiathèque ne devrait elle pas aussi présenter les logos 
?

JLuc

___
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 aux logos

2020-03-26 Par sujet JLuc

Le 26/03/2020 à 18:47, RastaPopoulos a écrit :

Le 26/03/2020 à 16:24, JLuc a écrit :

Alors ce n'est plus chercher_log() ?


chercher_logo() ça cherche uniquement les "vrais" logos anciens modèles (qui 
doivent changer), quand on a Rôles de documents par exemple (mais ça peut être d'autres 
plugins comme logo_auto aussi ou encore dans Sélections éditoriales) et bien ça ne 
renvoie pas le logo réellement utilisé.

c'est quete_logo_objet() qui fait ça bien et propre et générique, et lui-même 
appelle chercher_logo() aussi


OK merci.
J'ai complété https://programmer.spip.net/API-des-logos

JL

___
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 aux logos

2020-03-26 Par sujet JLuc

Le 26/03/2020 à 15:40, RastaPopoulos a écrit :

Le 26/03/2020 à 15:00, JLuc a écrit :

Apparemment, logo_auto n'utilise pas l'API des logos mais interroge directement 
la BDD à coups de sql_fetsel

Bé pour faire ce qu'il veut lui (trouver d'autres types de logo) mais non justement il 
s'inscrit dans le pipeline "quete_logo_objet" = il utilise l'API
qui est dans la fonction du même nom, dans public/quete.php
Et c'est quete_logo_objet() qu'il faut utiliser pour vraiment avoir le logo 
*d'où qu'il vienne* (les anciens logos ou tout autre source avec le pipeline)


Alors ce n'est plus chercher_log() ?

JL

___
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 aux logos

2020-03-26 Par sujet JLuc

Le 26/03/2020 à 11:17, RastaPopoulos a écrit :

et par ailleurs même avant, yavait une fonction pour trouver un logo d'un objet car 
suivant le raccourci de l'objet (parfois le nom entier, parfois juste "art", ça 
dépend des déclarations) et suivant l'extension (ça peut être jpg, png, gif…), donc faut 
surtout pas chercher un fichier soi-même, mais utiliser l'API (cf le plugin logo_auto)


Apparemment, logo_auto n'utilise pas l'API des logos mais interroge directement 
la BDD à coups de sql_fetsel

Quand à l'API des logos je suppose que c'est 
https://programmer.spip.net/API-des-logos
J'ai donc légèrement actualisé le début.
Mais peut être doit-on-devra-t-on préciser ou compléter encore ?

JL


___
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 aux logos

2020-03-26 Par sujet JLuc

Le 26/03/2020 à 11:17, JLuc a écrit :

Le 26/03/2020 à 10:48, Bruno Bergot a écrit :

j'ai besoin d'accéder depuis une application non spip aux logos des articles 
SPIP à partir de leur id_article
j'étais persuadé que les fichiers logos étaient renommés arton2020 à leur upload
mais visiblement non, depuis quelques temps ils gardent leur nom d'origine 
autant que possible.



Ça n'est plus le cas en 3.3 depuis que les logos sont des documents.


OK
Je devrais pouvoir m'en sortir à l'aide de spip_documents_lien et 
spip_documents.
Je vois dans la bdd que dans spip_documents, le champ 'mode' d'un document logo 
vaut 'logoon'


En fait vu le contexte particulier du besoin je fais plutôt une mini api 
passant par spip :

dans .htaccess, une redirection
RewriteRule ^logo([1-9]+)$  
https://www.site.info/spip.php?page=vers_logo_article=$1 [NC,R=301,QSA]

et un vers_logo genre :

[(#LOGO_ARTICLE|image_reduire{#ENV{taille,200}})]


JL

___
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 aux logos

2020-03-26 Par sujet JLuc

Le 26/03/2020 à 10:48, Bruno Bergot a écrit :

j'ai besoin d'accéder depuis une application non spip aux logos des articles 
SPIP à partir de leur id_article
j'étais persuadé que les fichiers logos étaient renommés arton2020 à leur upload
mais visiblement non, depuis quelques temps ils gardent leur nom d'origine 
autant que possible.



Ça n'est plus le cas en 3.3 depuis que les logos sont des documents.


OK
Je devrais pouvoir m'en sortir à l'aide de spip_documents_lien et 
spip_documents.
Je vois dans la bdd que dans spip_documents, le champ 'mode' d'un document logo 
vaut 'logoon'

Au passage je vois aussi que le champ 'date_publication' des documents
semble n'être plus initialisé et vaut "1970-01-01 01:00:00"
Inversement je vois que pour les plus anciens documents (jusqu'en 2016)
leur 'date_publication' vaut "2038-01-01 00:00:00".
Le fameux bug de l'an 2038 ?
Entre les plus anciens et les plus récents, la 'date_publication' semble 
significative
et identique à la 'date'

JL

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


  1   2   3   4   5   6   7   8   9   10   >