• Google pousse le bouchon de plus en plus trop loin avec Chrome - Opting your Website out of Google’s FLoC Network - Paramdeo Singh
    https://paramdeo.com/blog/opting-your-website-out-of-googles-floc-network

    En gros, Google déporte son traçage publicitaire DANS Chrome avec la complicité des serveurs de sites web... Bien sûr il est urgent que les humains qui comprennent la vie privée cessent d’utiliser Chrome...

    The primary way an end-user can avoid being FLoC’d is to simply not use Chrome, and instead choose a privacy-respecting browser such as Mozilla Firefox .

    But website owners can also ensure that their web servers are not participating in this massive network by opting-out of FLoC.

    To do so, the following custom HTTP response header needs to be added:

    Permissions-Policy: interest-cohort=()

    Mais du coup, intervention d’utilité publique à faire sur nos serveurs... En attendant que cette boite cesse ses pratiques de monopoliste gagnant, ou qu’on la force à le faire...

    Via l’indispensable @sebsauvage

  • Mise à jour de maintenance :  sortie de SPIP 3.2.11

    Si vous suivez l’actualité de git.spip.net, vous avez certainement constaté une grande activité à l’approche de la sortie de SPIP 3.3. Comme discuté sur la liste spip-dev cf https://www.mail-archive.com/spip-dev@rezo.net/msg71320.html cette version nécessitera PHP 7.3 au minimum, en accord avec notre nouveau cycle de release.

    Toutefois, afin de chouchouter les personnes souhaitant rester sur la branche 3.2, nous avons décidé de sortir une version de support étendu (ou LTS) qui améliore la compatibilité jusqu’à PHP 7.4 dans cette branche.

    SPIP 3.2.11 est donc compatible avec les versions de PHP 5.4 à 7.4.

    La version 3.2.10 fut écourtée par la découverte d’une absence de report de quelques modifications intéressantes.

    Lire l’annonce complète : https://blog.spip.net/Mise-a-jour-de-maintenance-sortie-de-SPIP-3-2-11.html

    L’équipe

  • C’est la semaine des livraisons #shameless_autopromo… on vient donc de mettre en ligne, avec Emmanuel, le site du Frac Paca :
    https://www.fracpaca.org

    Évidemment c’est du #SPIP. Graphiquement c’est lié à la charte de l’institution, que nous avons évidemment adaptée à un site Web.

    Dans les trucs originaux :

    1. Le bandeau supérieur prend différentes formes selon la taille de l’écran :

    Ça se fait entièrement en CSS évidemment.

    2. Le menu hamburger est plus classique, mais à nouveau tout se gère en CSS (animations, accordéons…) ?

    3. Mes longforms, pour les expositions. Mais évidemment avec un traitement graphique beaucoup plus minimaliste que pour Fabre :
    https://www.fracpaca.org/Des-marches-demarches-remarche

    4. Un mini-agenda en page d’accueil, avec les prochains événements. L’aspect original, c’est que c’est responsive de façon un peu rigolote, puisque c’est un slider avec un nombre variable de cases, et que c’est réglé entièrement en CSS (si je te le dis : c’est plutôt astucieux…)

    5. Une carte des déplacements de la collection en région. Pour l’affichage, c’est du classique : Leaflet avec des clusters. L’intérêt ici c’est que ça va chercher les œuvres dans une base de donnée spécialisée (Navigart), pour les afficher sur le site. Aspect SPIP-c’est-bon-mangez-en : l’interrogation et le traitement de l’API distante se fait directement dans une boucle DATA dans le squelette, sans rien faire en PHP.

    6. Afficher automatiquement un portfolio des œuvres d’une exposition :

    Même principe, interrogation et affichage d’infos tirées de Navigart directement dans un boucle DATA. Et pour l’affichage des lignes façon Google Image, c’est mon bon vieux script tel que tu peux le récupérer dans mon plugin medias_responsive_mod… (modèle ligne.html et script portfolio_ligne.js).

    7. Une page d’agenda par semaine :
    https://www.fracpaca.org/?page=tout_agenda&id_rubrique=1&date_p=2020-07-23

    Pour le mini-calendrier en javascript, j’ai joué avec Pignose Calendar :
    https://www.pigno.se/barn/PIGNOSE-Calendar

    8. Pour les plugins importants ici :
    – plugin agenda
    – sélections éditoriales
    – plugin GIS (mais l’affichage des cartes côté public, je le refais moi-même, comme ça je vois directement ce que je fais).
    Et sinon, ma trousse à outil habituelle :
    – image_reponsive
    – centre image
    – css imbriqués
    – insertion avancée d’images

    • Pour info, nos échanges (oct 18) :

      > https://github.com/CliffCloud/Leaflet.Sleep

      – sur ordi : le déclenchement au hover est sensible et peut donc se faire même si on est en train de scroller et qu’on s’arrête juste pour regarder la carte.
      – sur tel (Android + FF et Chrome) : Ne fonctionne pas sur mon tel : j’ai bien le bouton « Clic or hover... » mais il ne disparait pas au clic et la carte se déplace dessous.

      > https://github.com/elmarquis/Leaflet.GestureHandling

      J’ai retrouvé mon retour de l’époque : https://www.mail-archive.com/spip-zone@rezo.net/msg45809.html

      C’est mieux aujourd’hui :
      – sur ordi : le 1er ctrl+scroll ne déclenche plus le zoom de FF mais ne zoome pas la carte pour autant (c’est mieux qu’avant). Le 2e ctrl+scroll déclenche le zoom carte.
      – sur tel (Android + FF et Chrome) : c’est ok sauf que le zoom à 2 doigts déclenche parfois (pas souvent mais je n’arrive tjs pas à reproduire) le zoom du navigateur

      Donc je dirais que le 2nd (Leaflet.GestureHandling ) est mieux...

    • La carte est activée dans tous les cas, mais elle est sous un <label > qui recouvre toute sa surface, et qui est semi-transparent histoire de renforcer l’impression que la carte est inactive. Toucher ce label déclenche un <input checkbox> qui est positionné immédiatement avant. Et une fois cet input décoché par le label, le label lui-même disparait, par un simple CSS.

      Sinon, la carte est en fin de page, à la fois parce que c’est logique dans la hiérarchie de l’information, mais aussi parce que ça évite que l’usager soit bloqué dans son scroll. Et aussi : la hauteur de la carte est proportionnelle à la hauteur de l’écran (60vh), ce qui fait que dans tous les cas (même sur smartphone), l’usager pourra toujours trouver moyen de scroller en attrapant une zone de l’écran en dehors de la carte.

  • Hello @SPIP. Après avoir un peu galéré avec Git, j’arrive maintenant à mettre à jour mes plugins sur git.spip.net.

    Mais : comment je fais pour que mes mises à jour soient prises en compte dans le téléchargement automatique des plugins ?

    Par exemple, image_responsive a été mise à jour hier :
    https://git.spip.net/spip-contrib-extensions/image_responsive

    Mais sur plugins.spip.net ça m’indique toujours une antique version « mise à jour le 20 février » :
    https://plugins.spip.net/image_responsive.html

    Et évidemment, la nouvelle version n’est pas proposée non plus dans les mises à jour automatiques de mes sites (/ecrire).

    Y’a une étape qui a dû m’échapper (surtout que j’ai fait pas mal de mises à jour ces derniers temps, c’est ballot).

  • Format de temps relatif en français
    https://contrib.spip.net/format-de-temps-relatif

    Une fonction pour afficher les dates relative au format « humain » dans SPIP : [(#DATE|age_ilya_progressif)]

    La fonction que j’utilise actuellement
    Elle renvoie « il y a 3 minutes » ou « il y a 40 minutes » ou « il y a 2h30 » ou « ce matin » ou « ce midi » ou « hier » ou « avant hier » ou « 26 mars » si on passe ’affdate_court’ en 2e argument.

    merci @jluc

    #SPIP #date_relative #affdate #age_ilya_progressif #date

  • Bon, j’ai donc Orient XXI qui passe son temps à planter sur Gandi, alors que, je pense, je n’étais pas intervenu sur la machine pour modifier mes scripts.

    Le support technique me signale donc avoir trouvé les indications suivantes dans les logs :

    [Thu Dec 19 14:36:03.230138 2019] [core:warn] [pid 160:tid 140191760656256] AH00045: child process 640 still did not exit, sending a SIGTERM
    [Thu Dec 19 14:36:03.230427 2019] [core:warn] [pid 160:tid 140191760656256] AH00045: child process 344 still did not exit, sending a SIGTERM
    [Thu Dec 19 14:36:05.232513 2019] [core:warn] [pid 160:tid 140191760656256] AH00045: child process 640 still did not exit, sending a SIGTERM
    [Thu Dec 19 14:36:05.232561 2019] [core:warn] [pid 160:tid 140191760656256] AH00045: child process 344 still did not exit, sending a SIGTERM
    [Thu Dec 19 14:36:07.234640 2019] [core:warn] [pid 160:tid 140191760656256] AH00045: child process 640 still did not exit, sending a SIGTERM
    [Thu Dec 19 14:36:07.234676 2019] [core:warn] [pid 160:tid 140191760656256] AH00045: child process 344 still did not exit, sending a SIGTERM
    [Thu Dec 19 14:36:10.238583 2019] [mpm_event:notice] [pid 160:tid 140191760656256] AH00491: caught SIGTERM, shutting down


    [19-Dec-2019 14:35:38] WARNING: [pool www] child 425, script '/srv/data/web/vhosts/orientxxi.info/htdocs/spip.php' (request: "GET /spip.php") execution timed out (1340.090631 sec), terminating
    [19-Dec-2019 14:35:38] WARNING: [pool www] child 422, script '/srv/data/web/vhosts/orientxxi.info/htdocs/spip.php' (request: "GET /spip.php") execution timed out (1340.137020 sec), terminating
    [19-Dec-2019 14:35:38] WARNING: [pool www] child 419, script '/srv/data/web/vhosts/orientxxi.info/htdocs/spip.php' (request: "GET /spip.php") execution timed out (1340.133535 sec), terminating
    [19-Dec-2019 14:35:38] WARNING: [pool www] child 416, script '/srv/data/web/vhosts/orientxxi.info/htdocs/spip.php' (request: "GET /spip.php") execution timed out (1340.142522 sec), terminating
    [19-Dec-2019 14:35:38] WARNING: [pool www] child 414, script '/srv/data/web/vhosts/orientxxi.info/htdocs/spip.php' (request: "GET /spip.php") execution timed out (1340.092782 sec), terminating
    [19-Dec-2019 14:35:38] WARNING: [pool www] child 412, script '/srv/data/web/vhosts/orientxxi.info/htdocs/spip.php' (request: "GET /spip.php") execution timed out (1340.140127 sec), terminating
    [19-Dec-2019 14:35:38] WARNING: [pool www] child 411, script '/srv/data/web/vhosts/orientxxi.info/htdocs/spip.php' (request: "GET /spip.php") execution timed out (1340.091671 sec), terminating
    [19-Dec-2019 14:35:38] WARNING: [pool www] child 232, script '/srv/data/web/vhosts/orientxxi.info/htdocs/spip.php' (request: "GET /spip.php") execution timed out (1340.091723 sec), terminating

    Est-ce que quelqu’un sait où il faut que j’aille voir ensuite dans les logs pour essayer de savoir à qui correspondent process ?

    • De ce que je vois c’est un serveur apache, et donc déjà question : le log que tu montres est le /var/log/apache2/apache2.log ou un log spécifique au virtual host ?

      T’as accès à la config ? si oui : une fois le log identifié, il faudrait peut-être augmenter le niveau de trace de ce log temporairement (à surveiller car ça peut générer pas mal de données...)

      Là je vois pas trop d’info permettant de savoir ce que sont ces process, mais probablement des workers apache. Pourquoi ça part en timeout, ben faut augmenter le niveau de trace des logs pour essayer de le savoir...

      Juste pour vérifier : t’as pas une partition qui taperait dans un quota, ou une base de données ?

    • C’est un Simple hosting de chez Gandi. Je ne suis pas certain de pouvoir augmenter le niveau de trace (où est-ce que je pourrais configurer ça ?).

      Sinon, c’est juste un SPIP.

      Le type du support me suggère de désactiver les plugins pour voir lequel fait planter. Ah ah, je te dis pas à quoi ressemblerait Orient XXI si je désactivais les plugins :-))

      Surtout que les planages ne sont pas systématiques. J’aimerais déjà savoir s’il y a une page spécifique qui fait planter le truc (je suppose que c’est ce que le niveau de trace est censé me dire ?).

      Arnaud

    • Argh... Tu vas pas avoir accès à la config et donc tu ne pourras pas modifier le niveau de trace... c’est dans la config de ton virtual host, mais laisse tomber, je viens de regarder l’offre technique du Simple Hosting de gandi, tu peux pas modifier ça.

      Et re-argh, évidemment c’est pas du systématique... Donc a priori ça devrait éliminer un problème de quota, mais je dis bien a priori. Donc tout de même par acquis de conscience je vérifierais ça : via un accès ssh (si tu as...) envoyer une commande « quota » pour voir si ça crie... Et aussi, est-ce que ta base spip est limitée en volume, et est ce que ça taperait pas dans la limite (genre sur une page particulière on essaie d’écrire dans la base et nada...). J’y crois peu mais sait-on jamais.

      Bah oui, je comprends bien que désactiver les plugins ça ne te tente guère, mais bon... faudra quand même essayer à un moment ou à un autre j’en ai peur...

      Eric

    • bash: quota: command not found

      En fait, ce que je crains, ce sont les traitements d’images. J’en fais beaucoup, et j’en fais encore plus avec mon plugin image_responsive. Du coup, en général je commence à voir les images très (trop) grosses et les dernières images uploadées par l’équipe, pour voir si y’a pas quelque chose par là.

      Mais ce que je ne comprends pas, c’est pourquoi j’ai des scripts qui ne s’arrêtent jamais, alors qu’il doit bien y avoir la time_limit de PHP qui devrait interdire d’en arriver à un SIGTERM, non ?

    • On ne sait jamais :
      – installer cache cool (je sais pas : éviter les demandes de recalcule répétées sur une page un peu lourde)
      – faire le ménage dans les tables SPIP (referers, visites_articles, versions, versions_fragments…)

    • Pas de quota ? Comment ils font chez gandi pour borner ton espace disque ???

      pour le php time_limit : oui mais si ça bloque sur une E/S je ne suis pas certain que le time_limit serve à grand chose.

      Là désolé mais en l’état et sans rien connaître d’autre de ton site je ne sais plus trop quoi te dire...

    • Bonsoir, je m’apprêtais à vous envoyer un mail concernant OrientXXi. Simple internaute, je pouvais naviguer sans pb aux alentours de 20h ce jour, et (après une pause) vers 22h15 c’est en « 503 backend failed ». Serait-ce dû à une anomalie en cours d’investigation liée (possiblement) à la nouvelle version de spip 3.2.7 (https://www.mail-archive.com/spip@rezo.net/msg78533.html) ou... sinon pour info je suis tombée à un moment sur la page 404 où figure l’ancienne arborescence de Orient XXi, et ai navigué dans le site à partir de là (depuis les liens de la page 404) si ca peut aider à identifier...

    • Comme ça plante encore, je continue :
      – désactivé Cache Cool, du coup
      – désactivé l’abonnement au flux RSS Seenthis d’Orient XXI (si problème d’entrée-sortie, ça c’est en une…)
      – désactivé le plug Mémoisation
      – désactivé la fonction de détection de langue paragraphe par paragraphe.
      – désactivé la génération d’images WebP par le plugin d’Image responsive
      – réduit considérablement le nombre de tailles d’images générées dans l’interface.
      – bloqué 5 IP « suspectes » qui provoquaient environ 30% des hits sur le serveur.

  • Bug dans le plugin #SPIP mailsubscriber : l’ajout de l’inscription à la newsletter dans les formulaires d’inscription et de forum ne fonctionne pas en version 3.1.

    D’après ce que je vois, la fonction mailsubscribers_formulaire_fond cherche la position de </ul> dans le formulaire reçu. Mais depuis SPIP 3.1, les <ul> des formulaires sont remplacés par de <div>. (Et du coup, outre la détection à cet endroit, il faut modifier le squelette inc-optin-subscribe.)

    J’ai patché ma version à la main, mais évidemment ça ne tourne pas qu’à partir de SPIP 3.1 du SPIP 3.0. Je ne sais pas comment patcher pour assurer la compatibilité de 3.0.)

  • [spip-dev] Les #SVG sont des images comme les autres

    Hello,

    On est en 2019, la version trunk de SPIP supporte maintenant totalement les SVG
    comme des images.
    https://caniuse.com/#feat=svg-img

    Cela veut dire :

    • qu’on peut les uploader comme des images dans les documents joints
    • qu’on peut les uploader comme logo d’objet
    • que les aperçus de SVG s’affichent bien partout dans l’espace privé
    • que les filtres |image_xxx utilisés partout dans les squelettes pourront
    s’appliquer dessus sans rien casser
    • soit en appliquant la même transformation que pour un bitmap si le filtre
    |image_xx supporte expressément les SVG
    • soit en ne faisant rien si le filtre n’a pas été modifié pour supporter
    les SVG

    Le support des filtres images devrait permettre d’utiliser des images SVG
    directement, sans aucune modification des squelettes ni de code, sauf peut être dans certain cas de filtres images perso un peu velus qui modifient notamment les dimensions de l’image

    https://www.mail-archive.com/spip-dev@rezo.net/msg67228.html

    #spip_blog

  • Migrer un site SPIP en HTML5

    Ce tutoriel est valable aussi bien pour la création d’un nouveau site SPIP vierge que pour la migration d’un site SPIP existant.

    C’est bien plus simple qu’il n’y paraît. Si vous partez d’un code propre (valide W3C) et où les styles s’appuient bien sur des sélecteurs CSS plutôt que sur des éléments HTML, cela prend moins d’une heure, sans incidence sur le site existant.

    https://contrib.spip.net/Migrer-un-site-SPIP-en-HTML5

    #spip_blog

    • Apparemment, Vimeo a des coups de mou. Des fois j’ai des messages de son nginx.

      Mais le rejet des vidéos par SPIP est systématique. En fait, en local, ça passe. Mais sur un serveur Web en ligne, je me fais jeter (copie d’écran ci-dessus).

      J’ai joué avec ecrire/inc/distant.php, et j’ai trouvé qu’en modifiant à partir de la ligne 440 ainsi, ça refonctionne :

              // si on a pas deja recuperer le contenu par une methode detournee
              if (!$result['length']) {
                      $res = recuperer_body($handle, $options['taille_max'], $gz ? $gz : $copy);
                      fclose($handle);
                      if ($copy) {
                              $result['length'] = $res;
                              $result['file'] = $copy;
                      } elseif ($res) {
                              $result['status'] = 200;
                              if (!$result['headers']) $result['headers'] .= "Content-Type: text/html";
                              $result['page'] = &$res;
                              $result['length'] = strlen($result['page']);
                      }
              }

      C’est-à-dire que si j’ai $res (recuperer_body a répondu avec du contenu), je force status et headers dans la réponse.

      Mais j’ignore si c’est la bonne méthode (pour le status, ça me semble logique ; pour headers déjà nettement moins). J’ai expédié un mail à spip-dev, si quelqu’un de plus calé que moi veut valider ou invalider mon hack, ce serait bien.

  • Salut #Spip,

    Comme je suppose que c’est déjà documenté quelque part, peux-tu me dire si on peut développer et installer ses plugins sur Git plutôt que sur SVN, et dans ce cas comment on fait ? Je ne trouve pas trace d’un spip-zone sur Git, et quand je trouve un plugin sur Git je n’ai pas l’impression qu’il est accessible ensuite avec l’installation automatique…

    Et surtout s’il y a une page quelque part qui explique déjà tout ça ?

    • Il y a deux voies différentes :
      – celleux qui développent sous Git puis reversent dans le SVN de spip-zone en gardant l’historique, avec git-svn
      – celleux qui développement uniquement sous Git, que ce soit Gihub ou bien mieux encore l’hébergement Git fournit par la communauté : https://git.spip.net.

      À l’intérieur du deuxième choix, il y a deux variantes aussi :
      – Git externe comme Github, puis déclaration d’un externals dans spip-zone, afin que le plugin soit présent dans le SVN et soit compris dans les dépôts officiels (et donc plugins.spip etc) :
      https://zone.spip.org/trac/spip-zone/browser/_externals_
      – Avoir un plugin SVN spip-zone bien ordonné (branches, trunk etc) qui le rend compatible avec la synchronisation Git. Dans ce cas, le plugin peut être disponible sur git.spip.net, et le but est alors qu’il est possible d’y contribuer aussi bien par SVN que par Git, avec synchronisation auto. Là c’est @azerttyu qui s’en occupent et qui pourra en dire plus.

      À priori, je pense que c’est la meilleure solution car cela permet à d’autres de participer, de contribuer, quelque soit ses compétences, et on reste dans le cadre d’un dépôt communautaire démocratique, où on a tous les mêmes droits (modulo le fait de se parler, de discuter).

      Après on peut être un individualiste patenté et préférer tout développer dans son dépôt seul et avoir le contrôle total et n’accepter les contributions extérieures que par patchs en les validant un par un soi-même. Mais ça ne colle plus à ce que je trouvais intéressant dans l’approche collectiviste et démocratique du code sur spip-zone.

    • 1. Refonte du raccourci <img>

      Fondamentalement, c’est une modification complète du fonctionnement du raccourci <img> : l’image est affichée « en grand », et jamais sous forme de vignette. Elle peut être évidemment placée au centre, à gauche ou à droite, mais l’utilisation première est d’afficher l’image sur toute la colonne de texte disponible.

      Une idée vraiment importante est de se débarrasser totalement de la différence entre les images du portfolio et les images hors du portfolio : les images s’affichent de la même façon dans tous les cas, et jamais sous forme de vignette.

      2. Si on a mis un titre, un descriptif et/ou des crédits, ils s’affichent avec <img>. C’est dans la continuation de la logique précédente : si on met un titre, c’est qu’on veut un titre. Donc <img> affiche toujours le titre (quand il est renseigné).

      3. C’est responsive, évidemment.

    • Outre le fait que personne ne comprend vraiment la logique <img>, <doc> ou <emb>, la question qui prime est le fait que les usages qui ont justifié ces différents raccourcis ont disparu.

      – Quand on a conçu SPIP en 2000, la bande passante utilisée par les images restait une question importante : on affichait les images en petit dans les articles, et on proposait de cliquer dessus pour que l’utilisateur puisse les charger uniquement s’il en a envie. Clairement, plus personne ne fait ça… On veut des images en grand et puis c’est tout. C’est aussi pour cela qu’on affiche le type et le poids du fichier dans <doc> (pour que l’utilisateur ait une idée de ce qui l’attend s’il clique sur ce terrifiant fichier de… 160ko) ; mais aujourd’hui, en dehors de fichiers spécifiques, genre gros PDF ou fichier d’image monstrueux, ça n’a pas de sens de continuer à le faire pour des images…

      Bref, le coup d’insérer des petites vignettes cliquables au lieu de grandes images, ça ne se fait plus du tout.

      À l’inverse, insérer de belles grandes images qui occupe toute la largeur de la colonne, c’est la norme désormais.

      – Une habitude (étrange…) qu’on avait était d’insérer des petites images sans légende à l’intérieur des textes. Bon, ça non plus, ça ne se fait plus : quand on met une image, si on a une légende, hé ben on affiche la légende, ça ne coûte pas plus cher…

      – Un usage que j’ai supprimé de mes sites : la différence entre portfolio et hors portfolio. Si une image est associée à un article, c’est qu’on veut l’afficher dans tous les cas (si on veut conserver des images dans le site, mais sans les associer à un article, on a maintenant la médiathèque). Donc une image s’affiche toujours de la même façon avec le raccourci <img>, et si elle n’est pas affichée dans l’article, on la mettra dans le portfolio en dessous, sans se demander si elle est dans le « portfolio » (au sens technique SPIP) de l’article, parce que c’est une notion incompréhensible pour les usagers.

      Je ne l’ai pas encore fait dans ce plugin, mais je pense qu’il faudrait complètement réserver l’utilisation de <doc> à des présentations de documents à télécharger, genre grosses images ou fichiers PDF, et ne plus du tout l’utiliser pour insérer des images dans le texte. Du coup, sur mes sites, j’utilise désormais uniquement <img> pour insérer des images, et plus jamais <emb> ni <doc>.

    • 4. Balisage moderne avec <figure> et <figcaption>.

      5. Une image est cliquable (pour afficher le grand format) automatiquement si elle fait plus de 800 pixels dans une de ses dimensions. Pas de considération de la notion SPIP de « portfolio » ici (voir ci-dessus : c’est une notion qu’on devrait totalement abandonner je pense) : si une image est assez grande, elle est cliquable et puis c’est tout…

      On conserve la possibilité de faire un lien hypertexte « à la main » sur une image, même si je pense que l’usage a également plus ou moins disparu de nos jours (quand on clique sur une image, on s’attend plutôt à la voir en grand, pas à changer de page).

    • 6. Possibilité de forcer la largeur d’une image « à la main » :

      <img23|right|largeur=300>

      Noter que techniquement, dans ce cas on aura grâce au plugin image_responsive une gestion plus avancée du balisage, mieux adaptée au chargement anticipé des images, puisque ça va utiliser le srcset avec les valeurs 1x et 2x (pour le retina).

      7. Une subtilité javascript épatante ici : les images flottantes à droite ou à gauche, c’est très joli sur un grand écran, mais sur un téléphone ça détruit généralement complètement la maquette, parce qu’on met une image « flottante » de 250 pixels dans une colonne de 320 pixels, et qu’il reste du coup 70 pixels pour afficher le texte, et généralement c’est une catastrophe.

      Le plugin inclue donc un mécanisme #javascript qui vérifie la largeur des images flottantes et de la colonne de texte pour supprimer le float quand l’image devient proportionnellement trop large par rapport à sa colonne d’affichage (plus de 60% de la colonne de texte). Dans ce cas l’image est « forcée » en présentation centrée, avec sa légende, et on récupère un affichage optimal même sur petit écran.

      À l’inverse, on peut aussi se prévoir des styles pour les écran très larges (ça c’est pas directement dans le plugin, mais le balisage le permet facilement) :

    • 8. Option de présentation : rond : ça force l’image à s’afficher dans un cercle. Oui, tout rond. Même si l’image est un JPG, ça se fait en CSS, donc ça évite de recourir à un PNG dix fois plus gros.

      <img13|center|rond>

      Ça peut valoir le coup de l’associer à l’option largeur si on veut faire flotter une grande image à droite ou à gauche :

      <img13|left|rond|largeur=200>

      9. Trop mignon avec un navigateur récent : une image arrondie (avec rond) flottante forcera un habillage irrégulier par le texte : c’est-à-dire que le texte habillera le cercle de façon… circulaire, et non en rectangle. Ça se fait directement en CSS avec shape-outside. C’est automatique quand on utilise ˋrond`, pas besoin d’option supplémentaire.

      10. Extrêmement puissant : on peut demander un habillage irrégulier automatiquement sur les images JPG dotées d’un fond uni grâce à l’option shape. Attention, ça n’utilisera pas ma vieille technique de « tranches » (de image_ragged), mais sur la base d’un polygon calculé avec une nouvelle fonction : `image_detourer_polygon. Ça c’est carrément spectaculaire.

    • 11. Une petite animation rigolote : l’option flip permet de faire tourner l’image sur elle-même lorsqu’elle apparaît dans le viewport (en fonction du scroll, donc). Ça donne l’impression d’une pièce de monnaie qui tourne sur elle-même avant de s’arrêter pour s’arrêter :

      <img13|center|flip>

      ça devient encore plus fun si on force l’affichage dans un rond :
      <img13|center|rond|flip>

      ou carrément dans un rond flottant avec le détourage automatique :

      <img13|left|rond|flip|largeur=200>
    • 12. Et enfin l’animation la plus puissante : le zoom sur un détail de l’image (déterminé avec le plugin centre_image) :

      <img13|center|kenburns=1.6>

      Je pense qu’il faudrait renommer l’option simplement zoom, parce que personne n’arrive jamais à mémoriser ça…

      C’est une animation volontairement lente, mais alors : extrêmement spectaculaire… Et pour le coup, ça a généralement un véritable intérêt éditorial.

    • 13. Et enfin, la possibilité d’afficher plusieurs images sur une même ligne, avec adaptation aux différentes tailles d’écran, avec un nouveau raccourci : <ligne> :

      <ligne13>
      <ligne14>
      <ligne15>

      Ça c’est vraiment impressionnant… (en revanche, je n’utilises pas le même code HTML que pour les <img>, alors que je pense que je devrait le faire, pour profiter des raccourcis décrits précédemment).

      Noter qu’ici encore, s’il y a des titres, descriptifs et/ou crédits, ça s’affiche. Sinon, non.

      C’est à la fois très puissant, et assez déstabilisant, parce que la composition est automatique et… responsive. Du coup l’affichage dépend énormément des proportions des images et de la taille de l’écran. Du coup il faut réussir à se faire à l’idée que l’affichage sera variable, semi-automatique, et ne pas chercher à avoir des positionnements absolus qu’on décrète soi-même (ce qui est le « problème » de la mise en page responsive : il faut accepter que ça se recompose).

    • Bon, je dois m’absenter pour la journée, je compléterai avec des copies d’écran plus tard. Mais déjà, j’invite les Spipeurs•ses à jouer avec, parce que c’est un outil que j’installe sur tous mes sites, et qui change radicalement leur fonctionnement. Je suis très très très très preneur de retours à ce sujet.

    • Pas testé, mais sur le principe ça rejoint en partie le plugin Medoc de @tetue, en ajoutant le côté responsive.
      Mais il y a beaucoup de gadgets visuels : ça mériterait deux plugins distincts (un plugin = une fonction).

      Après, la « doc » et la discussion sur seenthis n’engagent pas vraiment la discussions avec la communauté #SPIP.

    • Ma remarque sur le lieu approprié pour le discussion est un peu sèche et pourrait être mal interprétée : pas d’arrière pensée de ma part, juste une remarque pratique sur le fait que tu « invites les Spipeurs•ses à jouer avec ».

    • @nicod_ : yep, attention à ne pas confondre évol d’affichage des modèles et débug ergo.

      1) Medoc n’est qu’un patch (grossier) qui corrige un bug ergo (hyper chiant quand on y confronté, totalement imperceptible pour les autres)
      2) et (plein) d’autres plugins proposent des variantes d’affichage des modèles, responsive ou pas, toussa, toussa…

      En tant que patch correctif, Medoc s’utilise avec n’importe lequel de ces autres plugins (dont il doit rester distinct).
      Il n’aura plus de raison d’être lorsque le « mode » (« image » ou « document ») aura disparu de la table spip_documents ainsi que ses implications (différence entre portfolio et hors portfolio)… chose que je suis infichue de savoir faire, d’où cet affreux petit sparadrap appelé Medoc ;)

      @arno : je suis ravie à l’idée d’essayer ton plugin prochainement :)

    • Merveilleux ! Super boulot, merci de le partager !
      Une remarque sur la notion d’image insérée sans légende, c’est en fait essentiel pour l’accessibilité de pouvoir définir un titre inséré dans le alt de l’image, mais qu’on ne tient pas à afficher en dessous de l’image en légende.

      Actuellement
      <img> insère l’image avec le titre en alt
      <doc> insère l’image avec le titre en légende en dessous

      Donc, dans la logique de ce que tu as fait, un paramètre |legend ou |nolegend serait pertinent, non ?

    • @tetue me suis mal exprimé, et trop vite.

      Je parlais de

      Fondamentalement, c’est une modification complète du fonctionnement du raccourci <img>

      qui est le côté très intéressant du plugin de @arno, et qui rejoint ta réflexion sur medoc.

      Avec l’ajout du paramétrage de largeur et le côté responsive, ça en fait un travail intéressant qui peut alimenter la réflexion sur la refonte de la gestion des docs dans SPIP (d’où ma remarque également sur le lieu pour en discuter).

    • Merci @arno , ce plugin a l’air très bien, et rempli de bonnes idées.

      Une remarque sur <ligneXX> : je vois* que cela crée autant de <ul> que de <ligne>. Est-ce qu’une syntaxe tel que <ligne|XX,YY,ZZ> ne serait pas plus appropriée, ce qui permettrait de n’avoir qu’un conteneur pour les 3 documents ?

      Le terme « ligne » en lui-même aussi est un peu flou, mais je n’ai pas d’idée là comme ça à part avoir une autre notion tel que <images|ligne|XX,YY,ZZ> , <images|cases|XX,YY,ZZ> peut être… ce qui deviendrait un « modèle d’affichage d’une liste de documents sélectionnés »

      * note : le modèle est ainsi fait, mais un pipeline enlève ensuite les ul en trop sur ces lignes…

    • Ah ou… si autant de balises <ligneXX> que de documents à afficher est conservé (plutôt que d’1 pour n documents), pourquoi ne pas utiliser plutôt <imgXX|ligne> ou <docXX|ligne> finalement directement ? ça paraîtrait bien également non ?

    • Sur <ligne>

      D’abord, je voudrais refaire le code de ce modèle pour qu’il utilise le même code que <img> pour l’affichage de l’image et des intitulés ; pour l’instant ce n’est ni le même code ni la même logique de fonctionnement, ce qui pose différentes difficultés :

      – les images de <ligne> s’affichent en background, ce qui fait qu’elles ne sont généralement pas imprimées et/ou difficiles à sauvegarder dans un PDF ; et autres petites difficultés d’utilisation quand les images sont des background…

      – le fait d’avoir deux codes à maintenir, c’est un peu chiant (c’est pas dramatique, parce que j’utilise énormément ce plugin, mais c’est chiant)…

      – j’aimerais bien avoir les mêmes fonctionnalités (notamment le zoom kenburns dans l’image) y compris sur les images en ligne…

      Du coup, utiliser carrément le même modèle avec <imgXX|ligne>, ça semble une bonne piste (surtout que ligne remplace exactement center, left et right dans leur logique de positionnement).

      Difficulté : je pense que certaines fonctionnalités n’ont rien à faire dans ligne (notamment forcer la largeur), et donc ça va commencer à faire du code un peu complexe.

      En revanche, je ne pense pas intéressant de fusionner la déclaration de plusieurs images dans le même modèle :
      – d’abord parce que c’est chiant à manipuler (quand on fait des articles, on déplace beaucoup les images, surtout qu’avec ligne ça demande des réglages parce que certaines associations fonctionnent moins bien que d’autres), et du coup le copier-coller d’une ligne pour une image, c’est plus pratique que d’aller éditer le modèle avec plusieurs images,
      – parce que je voudrais pouvoir passer des fonctionnalités différenciées sur chaque image (comme l’effet de zoom).

    • J’oubliais une option :

      14. Ça prend en compte l’option large :

      <imgXX|center|large>

      qui se contente d’insérer une classe .large. Ça ne sert pas à grand chose pour l’instant, mais c’est extrêmement utile dans un autre de mes plugins (pas diffusé pour l’instant), et chacun pourra de toute façon bidouiller ses feuilles de style soi-même : ça permet d’afficher cette image plus large que la colonne de texte.

    • Hello, :-)
      Je viens de faire un test de ton plug pour voir, j’ai un bug avec un SPIP 3.1.4-dev [23345] (php5.6.25), j’ai deux images dans la médiathèque que j’ajoute à un article, je mets donc <img2|left> <img1|left> avec du texte avant chaque image, si je clique sur l’onglet « voir » du porte plume, les images apparaissent et disparaissent d’un coup, quand à l’onglet « plein écran » du porte plume, je ne vois même pas les images, à savoir qu’il n’y a que ton plug et « image_responsive » dans les plugs. A savoir, il faut que je fasse plus de test, mais la première fois, comme il s’agissait d’un spip tout neuf, j’ai activé ton plug avant d’aller dans /ecrire/ ?exec=configurer_avancees et que le résultat, c’est que cette page plante (page blanche) avec juste le logo « infini » et l’url qui s’écrit /ecrire/ ?exec=configurer_avancees&action=tester_taille&i=1&arg=6000-6000 j’ai aussi pas mal de notice dans l’article, mais ça c’est pas grave, cela vient sans doute que dans mes_options, je demande à les voirs

    • Je pense avoir compris le problème, par contre, je ne sais si c’est un bug de spip ou du plug :-(
      Pour info, pour voir le problème, il est important qu’après l’installation d’un spip neuf, de ne pas faire le choix d’un type d’url dans /ecrire/ ?exec=configurer_urls , donc le laissé comme il est nativement, puis d’aller dans ecrire/ ?exec=depots pour faire l’ajout du dépôt de la zone, enfin, installer le plugin « medias_responsive_mod » en manuel dans le dossier « plugin » et laissé spip installer la dépendance « Filtre image_responsive », télécharger un jpeg dans la médiathèque, activer le plugin « medias_responsive_mod » et faire un article.
      Avec ou sans htaccess, il y n’y a pas de changement de mon côté

    • Salut @arno

      un souci rencontré avec image_responsive (je n’ai pas trouvé le seen dédié, donc je me permet de poster ici) :

      Sur un SPIP 3.0.3 avec uniquement ce plugin installé, j’ai cette erreur dans la console de Firefox :

      Et quand je regarde ce fichier dans local/cache-js, j’ai (ça donne un a circonflexe majuscule dans le source Firefox)

      Si je désactive la compression js dans l’espace privé, plus de problème.

      La ligne en question se trouve dans https://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive/javascript/image_responsive.js#L311

      En regardant de plus près, il semble y avoir également un souci là https://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive/javascript/image_responsive.js#L388 (carré de couleur rouge matérialisant une erreur ?)

      (Le fil sur spip_zone : https://www.mail-archive.com/spip-zone@rezo.net/msg43360.html )

    • Salut,

      Sur le point n°5 :

      Une image est cliquable (pour afficher le grand format) automatiquement si elle fait plus de 800 pixels dans une de ses dimensions.

      Ligne 37 du modèle img.html, il y a un test sur la taille pour utilise soit un <span>, soit un <a> mais, dans les 2 cas, il y a un href="#FICHIER" ce qui, dans le cas du span, crée une erreur de validation.
      Idem pour le type="#MIME_TYPE" (et pour les class et data-photo ?)

      cf : https://zone.spip.org/trac/spip-zone/browser/_plugins_/medias_responsive_mod/squelettes/modeles/img.html#L37

      Il ne faudrait pas tester si on a un lien ou un span avant de les insérer ?

  • Salut,

    un petit mail sans question, juste pour dire que je viens de passer plus de 30 sites (90 plugins en tout) de SPIP 3.0 à 3.1, de PHP 5.4 à 7.0 et de passer le tout en https en 2j et sans retoucher une ligne de code.

    SPIP <3

    Bravo et merci à ceux qui ont fait que tout ça se passe aussi bien...

    (parce que c’est bien de dire aussi quand ça marche tout seul)

    Bonne journée,

    jean marie

    https://www.mail-archive.com/spip@rezo.net/msg69603.html

    ↑ Désolé pour le lien mail-archive, RIP Gmane :\

    Merci @jeanmarie et #spip_blog

  • <nettime> Human at the Wheel - Jordan Crandall
    https://www.mail-archive.com/nettime-l@mail.kein.org/msg03678.html

    A flurry of videos made by Tesla drivers has appeared on YouTube, demonstrating the car’s new Autopilot features. We see the road through the POV of the (male) driver-author, who narrates the scene in voiceover — interpreting what the software is doing. Each clip culminates in a “close call,” with the implication that the software is to blame ("Tesla Autopilot tried to kill me!" reads one headline). In nearly every video, the driver is misusing the technology — a possibility the company had not apparently considered. Aghast at the behavior of these drivers, Elon Musk announced that new constraints will be added to the software “to minimize the possibility of people doing crazy things with it.”

    #autopilote #voiture_autopilotée #mésusage #robotisation

  • Qui nous protégera des logiciels tricheurs ?
    http://www.internetactu.net/2015/09/29/qui-nous-protegera-des-logiciels-tricheurs

    Il aura donc suffi d’un petit logiciel perdu dans les centaines de milliers de lignes de code qui font désormais fonctionner nos voitures pour faire vaciller un géant mondial de la construction automobile. Quelques lignes de codes capables de modifier le calculateur moteur, permettant de réduire les émissions de gaz polluant d’un véhicule, uniquement lorsque celui-ci est soumis aux conditions…

    #algorithmie #bidouillabilité #confiance #empowerment #open_source

    • https://www.mail-archive.com/nettime-l@mail.kein.org/msg03529.html

      Consumers have been at the mercy of technology vendors for a long time. The novelty here is that it is the government that found itself in the subordinate role.

      The lowdown is that the technology one doesn’t fully understand and have full transparency into ("user") can and will screw you, and no amount of regulations can change that. Anything with software is especially insidious in this sense, as for most users it is impossible to fully grasp it.

      The upside is that this enables multiple centers of power (from startups to VW), so in a way we are entering the age of pre-feudal fiefdoms. Whether the government model will prevail or not depends on how much power the illiterates have. I wouldn’t hold my breath.

  • <nettime> Hacked Team
    https://www.mail-archive.com/nettime-l@mail.kein.org/msg03339.html

    Today an article gives a glimpes on the scope of this racket http://motherboard.vice.com/read/meet-the-companies-that-helped-hacking-team-sell-tools-to-repressi but still omits the venture capitals in the list.

    My point is that we should be now really careful before going berserk and blaming a rather small team of software developers for all this. Because their business would have never had such a big success without the profit-driven capital that really made it happen and shop around.

    This affair is really about the military-industrial complex showing itself in the cyber-war era: this is how the monster that Eisenhower spotted back acts today on software matters.

    #capital-risque #silicon_army #hacking-team

  • Ce « Big Brother » dissimulé au cœur du renseignement

    https://www.mail-archive.com/frnog@frnog.org/msg32690.html

    C’est un sigle impersonnel, « PNCD », mais il cache un secret sur lequel la République a réussi, depuis 2007, à maintenir un silence absolu. Derrière ces quatre lettres se dissimule la Plateforme nationale de cryptage et de décryptement, un système complexe et occulte de recueil massif et de stockage de données personnelles étrangères et françaises dans lequel les services de renseignement français puisent à leur guise et sans aucun contrôle autre que leur propre hiérarchie.

    Le Monde avait révélé, en 2013, l’existence de ce dispositif et s’était
    vu opposer par les autorités un démenti formel. Au terme de deux ans
    d’enquête, il est désormais possible de décrire dans le détail
    l’architecture interne de ce véritable « Big Brother » à la française
    classé « secret-défense ». Les gouvernements successifs ont validé son
    fonctionnement et soutenu son développement. Au nom de la raison d’Etat, des parlementaires nient toujours son existence. Le mode de financement de la PNCD est très discrètement dilué au cœur du budget de l’Etat et les fonds alloués à ce programme n’ont cessé de croître.

    La mutualisation de cet outil, présenté comme une pierre angulaire du monde du renseignement en France, est jugée si essentielle par l’Etat à la bonne marche des services français qu’elle est totalement absente du projet de loi sur le renseignement présenté, lundi 13 avril, en séance publique à l’Assemblée nationale, dans le but de donner un cadre légal à l’activité des services. La PNCD semble avoir pris une place exorbitante au sein de l’organisation du renseignement en France et couvre des champs juridiques si différents qu’aucun cadre ne paraît, à lui seul, pouvoir le mettre en conformité avec la loi.