#seenthis : amélioré la gestion (au niveau du code) des sites que l’on suit. Les calculs sont (beaucoup) moins lourds, j’évite de faire sauter le serveur, et la page « Sites » passe en #microcache (je ne sais pas pourquoi elle ne l’était pas encore).
euh... comment on fait, pour suivre des sites ?
Si tu as du bol, tu tombes sur un truc référencé deux fois, qui a donc un petit triangle, tu cliques sur le petit triangle et là, tu navigues dans le chemin de fer pour aller à la page que tu veux (la racine du site certainement), et hop, tu cliques sur « Suivre ce site », comme tu le ferais pour un auteur.
Sinon, si tu es un pervers, tu références deux fois de suite la même page, comme ça dans le deuxième message tu as le petit triangle que tu peux cliquer dessus. Mais ça, c’est vraiment pervers.
Mais le plus simple : tu vas sur ta page « Sites », et dans le champ de recherche tu tapes l’URL que tu veux (l’autre interface de recherche, qui n’est pas très explicite d’ailleurs). Comme ça tu verras si le site en question est déjà dans la base, et tu pourras donc le suivre.
ah ! le petit triangle, c’est une idée géniale !
#seenthis : j’ai fait d’importantes modifications sur les page de récapitulatif d’une URL :
http://seenthis.net/sites/4907
– Techniquement, le gros de la page passe en #microcache, ce type de page ne me coûte donc plus trop de ressources.
– J’ai ajouté, comme pour la page d’un thème, la possibilité de n’afficher que ses propres messages ou ceux de son réseau.
– Dans la page de recherche, en colonne de droite (sous les éventuels auteurs trouvés), ça affiche des URL, comme ça on peut directement chercher une URL. Pas dément, mais c’est en attendant mieux.
(L’idée, à terme, c’est qu’on puisse aussi s’« abonner » à une URL, comme on le fait pour un mot clé, de façon à suivre tous les messages qui concernent un site.)
Cool, une sorte de google reader social, comme avant la mise à jour de Google reader
sur l’exemple ça saute drôlement (lire péniblement) quand on essaie de se promener dans l’arborescence
Euh... mais comment on y arrive, sur ces pages, il y avait un petit triangle à côté des URL auparavant, mais là plus rien...
#seenthis_todo : il faut que je modifie (radicalement) la gestion des effacements de #microcache quand on modifie son profil (couleur, logo, nom...). Là, ça plante au bout de 30 secondes, et rien n’est réellement mis à jour.
Je viens de poster un nouveau #plugin #SPIP sur #spip-zone : Microcache
http://zone.spip.org/trac/spip-zone/browser/_plugins_/plugins_seenthis/microcache
– à la base, c’est la fonction de @fil pour ►http://rezo.net,
– mais comme le nom du #microcache est facilement accessible, elle est complétée par une fonction de suppression du cache.
Sur Seenthis, c’est le système qui me permet de travailler avec des squelettes SPIP, tout en ayant à la fois :
– un système de cache statique et persistant,
– des mises à jour en temps réel (il me suffit d’effacer les fichiers microcache qui vont bien quand on poste un message).
Ah oui, ça s’utilise ainsi :
[(#ID_AUTEUR|microcache{inc/truc_auteur})]
où inc/truc_auteur.html est un squelette tout à fait classique. La valeur de l’#ID_AUTEUR est à récupérer, dans ce squelette, avec la variable #ENV{id}.
Pour effacer ce microcache, a priori ça se fait directement dans du PHP (à la validation d’un formulaire, certainement) :
effacer_microcache($id_auteur, « inc/truc_auteur ») ;
Si tu regardes le fichier /inc, tu verras qu’il y a déjà une fonction :
_esi_microcache()
qui fait exactement cela.
Mais je n’arrive pas à faire fonctionner les fonctions ESI.
Sinon, ça serait intéressant :
– puisqu’il s’agit d’un plugin, il sera sans doute possible de détecter la présence du code <esi : dans le source, et d’ajouter un header destiné à Varnish pour que celui-ci parse cette page spécifiquement ;
– ensuite, dans supprimer_microcache, être capable de forcer la purge pour cette adresse.
Et, au final, faire que ça tourne directement sur la fonction microcache, sans modification, uniquement sur une variable de configuration (pour que les mêmes squelettes fonctionnent avec ou sans ESI Varnish).
#Seenthis : Un petit peu de microcache dans les backend RSS. Je pourrais les passer entièrement en #microcache, tant qu’à faire, mais je suis fainéant.
Il n’y a plus une seule #BOUCLE #SPIP dans la page d’affichage d’un message. Tout est passé en #microcache.
Les listes de billets des pages #auteurs et #thèmes passent en #microcache. J’espère ne pas avoir introduit de bug...
Sur la page « Accueil », j’ai réintégré la liste des derniers messages postés. Faites un hard reload pour avoir les derniers scripts et CSS qui gèrent ça.
Comme ce bloc pas encore en #microcache, il a un délai #SPIP de 5 minutes. Quand on poste un message, on ne le voit donc pas apparaître illico.
petite erreur d’ergo dans ce bloc : les infos intéressantes sont écrites en gris pâle, les pas intéressantes en gros
J’ai modifié. Mais c’est pas évident : qu’est-ce qui est intéressant ? « Machin aime votre statut », me dit généralement le réseau social, et ça ne m’avance pas beaucoup.
Dans une version précédente, j’affichais le lien, le destinataire, les tags. Mais ça ne donnait pas beaucoup plus de lisibilité au bazar. Du coup, là, je mets le début du texte, c’est encore ce qui me semble fournir le plus d’infos.
@seenthis bug, avec Chrome, sur ma page Pierre Lazuly, je peux commenter sous le commentaire d’Agnès (premier item), mais pas sous les deux autres posts (par exemple je n’arrive pas à répondre au dernier commentaire d’Erwan sous mon deuxième post).
Et aussi : j’espère que ce message, commençant par un @seenthis, ne va pas passer dans mon flux RSS puis sur Facebook et Twitter ;-)
Idem avec Firefox 4.0b7. A noter que suite à ce post, le deuxième est devenu le troisième. Je peux commenter celui-là, ou le suivant, mais pas les deux derniers.
Je vois que ce post est dans mon flux RSS, donc il va passer sur Facebook et Twitter. Ceci dit, sur Twitter, s’il le poste « @seenthis blabla », ça va être rigolo car il va le prendre pour un utilisateur à lui.
J’ai déjà eu un bug similaire, mais pas vraiment réussi à l’indentifier. En forçant le recalcul, ça remet comme il faut (mais comme c’est moi qui peut le faire, c’est pas une bonne idée).
Il est bien passé. Sur Facebook ça ne ressemble à rien. Sur Twitter c’est comme si je l’avais écrit à Seenthis. Normalement, ceux qui me suivent sur Twitter ne doivent pas l’avoir vu ?
...et l’utilisateur Seenthis de Twitter doit bien se demander ce que je lui raconte.
Là c’est bon, je peux à nouveau tout commenter dans ma page Pierre Lazuly.
OK, dans le formulaire, je testais le statut de l’auteur. Ce qui est idiot, puisque de toute façon le formulaire est en #microcache. Surtout, si le pavé est calculé par un visiteur « public », hop : pas de formulaire pour quiconque.
Quelqu’un me suivant mais ne suivant pas Seenthis, aurait-il vu sur sa page d’accueil ce message adressé à Seenthis ? (est-ce différent de Twitter qui te montre les mails de bidule @ machin que si tu suis machin et bidule ?).
Sur Seenthis, tout est public, puisqu’il s’agit de partager de l’info. L’aspect « réseau social » est là pour favoriser la conversation publique. J’ai abordé ces questions sous le tag #public_conversations. Voir notamment cet article :
►http://scobleizer.com/2009/08/11/the-problem-with-facebook-for-public-conversations
#seenthis_done : La liste des messages pour un #tag sont :
– entièrement en microcache pour la première page,
– en inclusion normame pour les paginations suivantes.
Les fils de messages passent en #microcache.
– Alors évidemment, toutes les pages vont beaucoup plus vite (et charge serveur chute).
– Mais on ne peut plus modifier le contenu d’un fil de messages (ajout d’une réponse, suppression d’un message...).
– #seenthis_todo : c’est évidemment l’occasion de mettre en utilisation la fonction d’effacement des microcache...
À nouveau : l’idée étant qu’à terme, idéalement, il n’y ait plus de requêtes SQL à chaque hit. Mais qu’on conserve tout de même le principe de mise à jour en temps réel.
Le microcache est bien remis à jour lors des suppressions de messages. Il reste à traiter l’envoi d’une réponse.
#seenthis_done : le microcache se met à jour quand on poste une réponse ; dans ce cas, le $id_parent est directement balancé à la fonction, qui évite donc de faire une requête supplémentaire.
Le problèmpe que je me pose en ce moment : comment rendre toutes les pages statiques (avec du microcache) ?
La seule page qui me bloque, c’est la page #people, parce qu’elle contient non seulement les messages de la personne concernée, mais aussi les messages que l’utilisateur connecté qui visite la page lui a envoyés.
Il y a aussi le problème de la pagination, mais je dois pouvoir m’en sortir ainsi : microcache pour la première page, et pas microcache pour les écrans suivants.
L’aspect important du #microcache, ici, c’est que je fabrique des fichiers #microcache à durée de vie potentiellement infinie, et que j’efface volontairement ceux dont je sais qu’ils sont modifiés par l’action effectuée par un usager (poster/supprimer un nouveau message comportant des tags et des people, s’abonner à un tag...).
Je viens de passer le test de la présence (ou non) du lien « Supprimer » au survol des messages entièrement en #javascript. De cette façon il n’y a plus aucun élément dynamique dans l’affichage d’un message, et j’ai donc passé l’appel d’un message en #microcache.
Le principe est grosso modo le même que dans l’affichage de l’âge d’un message : je stocke les infos dont j’ai besoin (id_auteur du message, id_auteur du parent) dans le #rel du lien hypertexte, puis c’est javascript qui se débrouille au survol de chaque message pour savoir s’il doit afficher le lien « Supprimer ».
Astuce : pour simplifier le javascript, le #regexp est directement encodé dans le #rel. Du genre ^(1|2)$. Je récupère donc la valeur du #rel, et je l’applique directement en regexp à l’identifiant de l’auteur connecté.
Le message parent utilise désormais le même type de #microcache que les messages enfants. Ça va énormément simplifier la gestion.
Ça oblige à redimensionner l’icone 32x32 dans la CSS (puisque c’est désormais une image 48x48). Il va falloir faire des essais de rendu. Si c’est moche sous #IE, il faudra peut-être simplifier l’interface (et n’utiliser que des 32x32).
De plus, quand je fais des calculs sur le logo d’un auteur, je ne me contente pas du calcul automatique de #GD : j’extrais le nom du fichier et je force les dimensions « à la main ». Ça évite le bug qui intervient quand GD rate la réduction de l’image (aggravé par le #microcache qui fait que la version aux mauvaises dimensions reste affichée ad vitam æternam).
Content : le calcul de l’âge d’un message se fait désormais par #javascript. Le message, lui, ne stocke que sa date de publication, avec sa date #unix_time dans le #rel du lien.
Ce qui est amusant, du coup, c’est que les dates se rafraîchissent toutes les secondes. Quand on vient de poster un message, sa date change en permanence pendant la première minute.
Il y a un petit truc marrant qui calcule la différence par rapport au chargement du javascript. En effet, je ne peux travailler que par rapport aux temps du serveur, et non du client. Je ne peux donc pas me baser sur l’heure du client, mais uniquement sur la différence de temps entre le chargement du script et le moment actuel, que j’ajoute à l’âge serveur du message.
L’idée, évidemment, c’est qu’à terme il ne reste plus aucun élément dynamique dans le corps d’un message, pour pouvoir le passer intégralement en #microcache.
Pour le calcul du « supprimer », je vais mettre l’auteur du message (et du message parent) dans le rel, et comparer via javascript avec l’auteur connecté.
Ayé ! Premier élément en #microcache ! Chaque réponse individuelle est un microcache. Il va falloir vérifier les éléments dynamiques.
Bon ben c’est tip-top : les éléments dynamiques fonctionnent nickel :
– la date des messages se rafraîchit bien,
– le fait de pouvoir poster ou non, de pouvoir supprimer ou non, dépend bien de l’auteur connecté (ou non).
Quel andouille : c’est justement pas le microcache qu’il faut utiliser pour cela. Le microcache transforme un include en truc statique de chez statique.
Là où je pense gagner beaucoup : tous les appels de logos d’auteurs passent en micro-cache. Comme, sur une page, ce sont théoriquement toujours les mêmes icones qui reviennent, ça devrait être particulièrement efficace.
OK, la grosse modif qui me manquait : le « repliage » des premières réponses quand il y a plus de 3 réponses, avec l’apparition d’une mention « Afficher les x messages », se fait désormais entièrement en #jQuery. C’est indispensable pour que le système de blocages (un auteur bloque l’affichage de certains intervenants) soit compatible avec les #microcache.
Par ailleurs, passé l’affichage de l’âge du message directement en PHP dans le squelette, toujours pour la compatibilité #microcache. Et corrigé le bug de #SPIP qui faisait qu’un message de 25 heures était signalé « il y a deux jours » (et tout à l’avenant). Et tant qu’à faire « il y a un jour » est remplacé par « hier ».
Ajouté le #cache{0} dans #inc_afficher_message : c’est lui qui faisait que le recalcul des pages n’était pas totalement fonctionnel.
Sachant qu’à terme (quand toutes les fonctionnalités seront en place), tout ça passera en #microcache.
J’ai mis en place le lien #delete. Il permet, logiquement, de supprimer un message.
Ce qu’on peut supprimer :
– les messages dont on est l’auteur,
– les messages qui répondent à un message dont on est l’auteur (principe blog : on doit pouvoir contrôler les messages répondant à ses billets, et donc ce qui apparaît sur sa page publique).
L’affichage (ou non) du bouton #delete est en #PHP dans le squelette lui-même. De cette façon, un même fichier de #microcache devrait fonctionner indifférement selon l’auteur connecté.
