Hop, pour info, en SPIP 3.2 tu peux indiquer qu’un plugin nécessite une librairie php dans le paquet.xm
, exemple <necessite nom="php:mbstring" />
; cf commit ▻https://core.spip.net/projects/spip/repository/revisions/23396
En ajoutant ça dans ▻https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/plugins_seenthis/lien_court/trunk/paquet.xml cela permettrait d’avertir les gens qui installent le plugin ;)
Problème sur tous mes sites #SPIP : impossible de « référencer » une vidéo Viméo depuis quelques jours. Quand on essaie de joindre l’URL d’une page Vidéo, ça répond systématiquement « fichier distant n’a pas pu être trouvé ».
Qu’est-ce qu’il se passe ?
tu as donné les droits publics ?
sur un navigateur, si j’entre
▻https://vimeo.com/304775757
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.
Pour info, problème réglé cf :)
donc je confirme la source du bug qui vient bien du passage de Vimeo à TLS 1.2 :
selon que j’ai le patch
▻https://core.spip.net/projects/spip/repository/revisions/24018 le bug se
produit ou non
▻https://www.mail-archive.com/spip-dev@rezo.net/msg66660.html
Plugin mémoization
La mémoïzation est « une technique consistant à réduire le temps d’exécution d’une fonction en mémorisant ses résultats d’une fois sur l’autre ». C’est aussi le nom d’un plugin SPIP qui a recours aux caches memcache(d), APC, xcache, eaccelerator ou redis, pour accélérer les accés aux caches SPIP. Il propose aussi une option de base, filecache, pour les hébergements sans cache mémoire.
La librairie utilisée pour ce plugin peut également être utilisée de manière autonome sur mesure dans le code d’un plugin, ou même par toute application indépendante de SPIP. Pour cela, voyez l’article « Memoization, la librairie ».
▻https://contrib.spip.net/Plugin-memoization
▻https://contrib.spip.net/Memoization
Quand on n’a que filecache, est-ce qu’il y a un intérêt à l’utiliser ? Le plus grand nombre de dossiers augmente les perfs ?
Non, car si mes souvenirs sont bons, la méthode filecache de memoization a été intégré au core depuis un bon moment, cf : ▻https://core.spip.net/projects/spip/repository/revisions/21067
D’ac.
Ça vaudrait peut-être le coup de le préciser dans la doc ?
C’est à partir de SPIP 3.1 ?
Pour la doc fais toi plaisir, elle est toute fraîche sur contrib.
D’après le source, oui c’est bien à partir de SPIP 3.1 : ▻https://core.spip.net/projects/spip/repository/entry/branches/spip-3.0/ecrire/public/cacher.php#L15
C’est fait...
Merci aux contributeurs pour la doc !
Dis @SPIP, on me demande de répondre à des critères de sécurité « ANSSI », est-ce que tu peux me renseigner sur ces trois points ?
– R19 - Les identifiants de session sont aléatoires et d’une entropie d’au moins 128 bits.
– R21 - Les attributs HTTPOnly et, dans le cas d’un site en HTTPS, Secure sont associés à l’identifiant de session.
– R29- Définition d’une politique de journalisation précisant notamment les modalités et les durées de conservation des différents journaux ainsi que les méthodes d’analyse et de corrélation des données produites.
On me les a collés dans un appel d’offre, mais la source est ici :
▻https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Securite_Web_NoteTech.pdf
Pour R21, je vois que le httponly est passé par spip_setcookie()
pour le cookie spip_session.
@arno oui pour le cookie :
▻https://core.spip.net/projects/spip/repository/revisions/19183
▻https://core.spip.net/projects/spip/repository/revisions/20501
Reste une amélioration en attente ici : ▻https://core.spip.net/issues/3821
Depuis plusieurs jours les rebonds #seenthis > #twitter > #facebook provoquent un message d’erreur 503 un peu parasitant. Je sais pas trop à qui signaler ça alors je pose ça là : ▻https://www.facebook.com/val.k.errances/posts/10209028108089019
cc @seenthis @seenthisuser
J’avais déjà remarqué que les hashtags ne passaient pas, ce qui était un peu dommage...
SeenThis > Twitter en IFTTT et twitter > facebook depuis longtemps via leur appli, tout ça marchait bien jusqu’à il y a quelques jours seulement, erreur 503... quelqu’un d’autre m’a dit que ça venait de facebook mais il semble le faire que là dessus, le raccourci seenthis généré par twitter
ok je crois que c’est ▻https://core.spip.net/projects/spip/repository/revisions/22899 qui bloque souvent le robot facebook, et celui-ci n’arrive donc plus à faire les prévisualisations de pages… je désactive en local et j’en parle aux ami·e·s de #SPIP
Salut @fil et @seenthis et les @seenthisuser’s !
j’ai (encore) un souci parce que VRAIMENT je voudrai faire de seenthis mon unique rebond depuis mes photos sur flickr vers les reseaux sociaux dont je cherche à m’éloigner un peu. Sauf que à chaque fois le rebond vire les #hashtags, ce qui est très très embêtant :/ Est-ce que vous avez un conseil pour que je contourne cette tracasserie ?
Merci @Fil ! J’utilise ITTT pour passer de SeenThis à twitter et c’est sur cette partie que les hashtags disparaissent :
même lorsque je publie directement sur SeenThis comme pour
►http://seenthis.net/messages/479203
les hashtags ne passent pas :
▻https://twitter.com/ValKphotos/status/719900889620836352 .
Le flux que j’utilise :
▻http://seenthis.net/people/val_k/feed_tw
Heu non non @Fil je parle des tags que je mets DANS les 140 premiers glyphes, en bonne formatée des réseaux sociaux que je suis devenue. Là en l’occurrence dans l’exemple donné c’est même le tout premier mot : #NuitDebout qui se transforme en un NuitDebout sur twitter (et par conséquent sur mon facebook ensuite... )
Pour #spip je voudrais proposer la modification d’un commentaire :
▻https://core.spip.net/projects/spip/repository/entry/branches/spip-3.1/ecrire/inc_version.php#L282
// ▻http://code.spip.net/@Tuto-Se-servir-des-points-d-entree
qui renvoie une erreur 404 par
// ▻http://code.spip.net/fr/archives/plugins-7/article/les-points-d-entree-pipelines
ou par
Et voilà : ▻https://core.spip.net/projects/spip/repository/revisions/22850
Merci pour le signalement :)
Ça vient vite quand on n’y pense pas…
Bug de l’an 2038.
▻https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038
Le problème concerne des logiciels qui utilisent la représentation POSIX du temps, dans laquelle le temps est représenté comme un nombre de secondes écoulées depuis le 1er janvier 1970 à minuit. Ce nombre maximum sera atteint le 19 janvier 2038, à 3h14
Il n’existe pas de correctif simple et unique pour ce problème.
Android
La version actuelle d’Android (Marshmallow 6.0) à base de noyau Linux 3.10 n’incorpore aucune correction .
aura-t-on encore de quoi produire des ordinateurs en 2038 ? pas sûr. Mais par contre cela peut arriver deja maintenant. cf ▻https://core.spip.net/projects/spip/repository/revisions/16014 (voir aussi ▻http://seenthis.net/messages/69980)
J’avais un collègue qui me disait « je ne corrige les bugs que quand ils arrivent ». Mis à part que j’avais envie de le baffer, je trouve qu’il y a pas mal de dev qui ne sont pas proactifs, et bien au delà d’être partisan du moindre effort.
Les bonnes pratiques sont pourtant le garde fou à la réinvention de la roue (qui semble être le sport favori de toute la profession).
Le but de mon post était plus de faire prendre conscience d’un problème Grand Public dont la résolution est pour l’instant à la charge d’experts (ou au moins de personnes rigoureuses, svp).
J’ai un gros soucis avec #SPIP-3.1 : il ajoute un timestamp aux fichiers, que ce soient les CSS et les Javascript, mais aussi les images passées par les filtres.
C’est certes épatant pour être certain de bien utiliser la dernière version de chaque fichier, mais en revanche, ça me plante complètement l’aspiration des sites en local (parce qu’en local, le fichier monimage.jpg?1436899191
, ça ne marche pas du tout).
Est-ce qu’il y a un moyen prévu (genre une variable) pour pouvoir désactiver cet automatisme ?
J’ai l’impression d’avoir plus de timestamps avec le 3.1, par exemple sur des images passées par image_reduire, qui n’en avaient pas en 3.0.
Ce que je veux, c’est aspirer le site en local, pour en avoir une copie totalement statique. Avec les timestamp, ça ne fonctionne pas.
Pour l’instant, ce que je fais, c’est d’avoir un #FILTRE{mini_html}
dans tous mes squelettes, qui me sert déjà à faire différentes bidouilles (essentiellement, supprimer les tabulations et les espaces surnuméraires dans le code source), et donc là-dedans j’ajoute la suppression des timestamp un peu à la hache (chaque fois que je trouve (jpg|gif|png)\?[0-9]+[\'\"]
, je vire le timestamp).
C’est dans image_graver()
visiblement et il n’y a pas d’option pour le virer (option à ajouter, problablement). Cela dit il n’y a pas de raison fondamentale que les timestamp fassent foirer ta copie locale. Peut-être le fait qu’ils sont avec un ?xxx
et ne finissent donc plus par .jpg
— mais ça aussi ça pourrait se changer.
@b_b, oui j’ai vu |supprimer_timestamp
, mais ça m’oblige à reprendre tous mes squelettes, alors que l’idée est plus dans le sens de ce que remarque @fil. Ou, plus largement, dans le sens de ce qu’ai fait pour image_responsive
:
►http://seenthis.net/messages/374212
Là quand j’ajoute :
define("_SPIP_LIER_RESSOURCES", true);
mes_options
, le même site se met à me fabriquer des squelettes plus verbeux contenant les liens <link href…>
pour permettre l’aspiration du site et des ressources.Là c’est pareil, idéalement on définirait une variable dans mes_options
, et hop terminés les vilains timestamps le temps de faire l’aspiration.
@speciale : le but du timestamp est juste d’éviter que, quand tu fais les mises à jour de ton site (soit en div, soit pendant que tu mets en ligne des articles) tu sois gêné par le cache de ton navigateur. Un logo arton1.jpg
, remplacé par une nouvelle version, est toujours le logo arton1.jpg
; le timestamp ajoute la date de mise en ligne du fichier, et donc ton navigateur ne réutilisera pas la vieille image. Donc c’est bien dans le src
de l’image que ça doit se trouver, pas dans un data-
, qui n’invaliderait pas le cache.
@arno puisque tu as un #FILTRE{truc}
dans tes squelettes, tu peux y ajouter le filtre supprimer_timestamp non ?
@b_b : oui c’est ce que j’ai fait (expliqué plus haut), mais pas directement supprimer_timestamp, qui prend un URL en entrée, et pas l’ensemble de la page.
Mais à nouveau, ça oblige à modifier ses squelettes si on n’a pas l’habitude comme moi de mettre un #FILTRE{mini_html}
absolument partout…
Le problème se pose aussi sur les js et css compactés et agrégés par SPIP qui ont aussi ce timestamp, mais sur lesquels il n’est pas possible de passer le filtre de suppression de ce timestamp.
Sauf erreur de ma part, le nom des fichiers créés dans local/ dépend déjà de la date des fichiers. Le timestamp est alors inutile et contre productif.
Et si le nom du fichier ne dépend pas pas de la date, il suffirait de la rajouter dans le calcul du nom, non ?
Salut @arno*. Il est bien possible que ▻https://zone.spip.org/trac/spip-zone/changeset/104022 t’intéresse comme réponse à ton problème, d’autant plus que ça se greffe sur #FILTRE{mini_html}