Je pense que le problème a été résolu par des modifications de Claudex. Si ce n'est pas le cas, n'hésite pas à laisser un commentaire pour que je réouvre cette entrée de suivi et y jette un œil.
À l'usage, renvoyer les dépêches dans l'espace de rédaction a l'air de bien convenir et il n'y a plus vraiment d'intérêt à rajouter un nouveau système en plus de celui-là.
Les parts de IE6 et IE7 sont devenues tellement négligeables sur le site que je doute fort que quiconque propose un correctif. Je ferme donc cette entrée.
Je ferme cette entrée. On n'utilise quasiment plus l'espace insécable fine (le caractère qui posait problème) maintenant que des espaces insécables normales sont insérées automatiquement.
En fait, il n'y a pas besoin de les inclure séparément. Elles peuvent être dans le même fichier et utiliser @media pour s'activer dans le bon contexte.
Bon, je n'ai pas trouvé comment faire ça avec sass. Il bloque sur les extensions des noms de fichiers. Du coup, j'ai fait un petit script. Il faut mettre à jour son dépôt git et lancer cette commande :
On peut remplacer application.css.scss par contrib/<nom>.css.scss pour compiler une feuille de style alternative plutôt que la version officielle de RonRonnement.
Pour compiler les feuilles de style de LinuxFr.org, je fais appel à l'asset pipeline de Rails qui derrière fait appel à sass. Mais il n'utilise pas directement sass en ligne, donc je ne peux pas te donner la ligne de commande magique pour faire ça. Il utilise sass comme une bibliothèque et fait deux ou trois choses en plus, comme ajouter les bons chemins pour la compilation des assets ou faire certains pré-traitement.
Ceci étant dit, je ne pense pas faire de trucs qui empêcheraient la compilation des feuilles de style avec sass en ligne de commande. Je vais regarder ça.
Oui, c'est effectivement intéressant. Par contre, on a une durée de cache qui n'est que de 10 minutes, pas de 60 jours car certaines images sont dynamiques et regénérées régulièrement. Passé ce délai, le mécanisme du Last-Modified / If-Modified-Since permet de ne pas renvoyer l'image si elle n'a pas été modifiée.
On en risque pas de le perdre vu qu'il n'est déjà pas utilisé.
Pour profiter du cache du navigateur, il faudrait que les URL utilisées soient exactement les mêmes sur LinuxFr.org que sur d'autres sites. Or, nous passons dans les URL gravatar, l'adresse de l'avatar par défaut. Du coup, les URL utilisées pour charger les gravatars sont différentes sur les autres sites et on ne profite pas du cache du navigateur quand on arrive sur LinuxFr.org depuis un autre site avec des gravatars.
Redis est capable de réécrire ses journaux en tâche de fond pour les compacter. Ça se fait sur une copie et, quand c'est prêt, redis intervertit les 2 journaux et roulez jeunesse !
quid de Gravatar ? C'est la seule chose qui ne va pas rester en cache du coup, mais c'est sans doute fait exprès alors…
Je vais peut-être utiliser img pour les avatars. C'est juste pour le moment, je n'ai pas tellement réfléchi à comment le faire, si c'est vraiment pertinent out non, etc. Mais j'aime bien l'idée :)
Si une image change sur le serveur ensuite, est-ce qu'elle sera re-cachée, ou bien c'est la version au moment de la rédaction qui sera privilégiée ?
Actuellement, c'est la version au moment du premier affichage qui est privilégiée, mais ça devrait évoluer rapidement. Dès que je trouve un peu de temps, je vais faire en sorte que l'on aille chercher les mises à jour de l'image.
Effectivement, je ne connaissais pas Thumbor, mais ça a l'air d'être très sympa et ça aurait pu nous servir (il aurait juste fallu le modifier un peu pour les questions de modération).
Déjà en base64 on diminue pas mal la longueur (et ça me semble compatible avec le format des URL)
Un des caractères utilisés en base64 est le slash (/). Si plusieurs slashs se retrouvent collés dans l'URL, certains navigateurs les compactent en un seul slash.
Le problème avec l'hexa c'est qu'on peut vite faire exploser la longueur de l'URL
On pouvait déjà le faire avant. Les gens qui postent des images le font pour qu'elles soient vues, donc je doute qu'ils aillent chercher des URL si compliquées. Au pire, c'est juste que l'image ne va pas s'afficher, rien de bien méchant.
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Icône de notifications de réponses. Évalué à 3 (+0/-0).
Cf http://linuxfr.org/suivi/affichage-des-commentaires-dans-la-boite-utilisateur
[^] # Re: ?
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Formulaires écrits en blanc sur blanc. Évalué à 3 (+0/-0).
Je pense que le problème a été résolu par des modifications de Claudex. Si ce n'est pas le cas, n'hésite pas à laisser un commentaire pour que je réouvre cette entrée de suivi et y jette un œil.
# Bof
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Réorganiser la page de rédaction. Évalué à 3 (+0/-0).
Bon, visiblement, ça n'a pas l'air de gêner grand monde. Du coup, je ferme cette entrée.
# Je ferme
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi 755, dépêches en attente. Évalué à 3 (+0/-0).
À l'usage, renvoyer les dépêches dans l'espace de rédaction a l'air de bien convenir et il n'y a plus vraiment d'intérêt à rajouter un nouveau système en plus de celui-là.
# Je ferme
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi CSS de linuxfr.org mal prises en charge par IE 7. Évalué à 3 (+0/-0).
Les parts de IE6 et IE7 sont devenues tellement négligeables sur le site que je doute fort que quiconque propose un correctif. Je ferme donc cette entrée.
# Je ferme
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Affichage des caractères spéciaux (sous Win32). Évalué à 3 (+0/-0).
Je ferme cette entrée. On n'utilise quasiment plus l'espace insécable fine (le caractère qui posait problème) maintenant que des espaces insécables normales sont insérées automatiquement.
[^] # Re: Autre entrée sur le même sujet
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi URL spéciale petits écran. Évalué à 3 (+0/-0).
Et http://linuxfr.org/suivi/version-mobile
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Version Mobile. Évalué à 3 (+0/-0).
Je fusionne cette entrée de suivi avec http://linuxfr.org/suivi/url-sp%C3%A9ciale-petits-%C3%A9cran.
# Pas besoin
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Feuilles de style mobile et impression. Évalué à 3 (+0/-0).
En fait, il n'y a pas besoin de les inclure séparément. Elles peuvent être dans le même fichier et utiliser
@media
pour s'activer dans le bon contexte.[^] # Re: Un début de réponse
Posté par Bruno Michel (site web personnel) . En réponse au message Comment utilisé sass pour linuxfr ?. Évalué à 5. Dernière modification le 15 juillet 2012 à 17:47.
Bon, je n'ai pas trouvé comment faire ça avec sass. Il bloque sur les extensions des noms de fichiers. Du coup, j'ai fait un petit script. Il faut mettre à jour son dépôt git et lancer cette commande :
On peut remplacer
application.css.scss
parcontrib/<nom>.css.scss
pour compiler une feuille de style alternative plutôt que la version officielle de RonRonnement.Cf https://github.com/nono/linuxfr.org/commit/9ea3395783f5c1438037f69cea83f911bab0783e
# Un début de réponse
Posté par Bruno Michel (site web personnel) . En réponse au message Comment utilisé sass pour linuxfr ?. Évalué à 3.
Pour compiler les feuilles de style de LinuxFr.org, je fais appel à l'asset pipeline de Rails qui derrière fait appel à sass. Mais il n'utilise pas directement sass en ligne, donc je ne peux pas te donner la ligne de commande magique pour faire ça. Il utilise sass comme une bibliothèque et fait deux ou trois choses en plus, comme ajouter les bons chemins pour la compilation des assets ou faire certains pré-traitement.
Ceci étant dit, je ne pense pas faire de trucs qui empêcheraient la compilation des feuilles de style avec sass en ligne de commande. Je vais regarder ça.
[^] # Re: origine
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 3.
Oui, c'est effectivement intéressant. Par contre, on a une durée de cache qui n'est que de 10 minutes, pas de 60 jours car certaines images sont dynamiques et regénérées régulièrement. Passé ce délai, le mécanisme du
Last-Modified
/If-Modified-Since
permet de ne pas renvoyer l'image si elle n'a pas été modifiée.Cf https://github.com/nono/img-LinuxFr.org/commit/5f777854626b04620a7ee5dbacbf1832b178a9b5
[^] # Re: Pour les images qui sont actualisées à intervalles réguliers
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 5.
Et un truc de moins sur ma TODOlist. Cf https://github.com/nono/img-LinuxFr.org/commit/54018f4085dd14cdd09bbfff874c8863549175b9
[^] # Re: origine
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 9.
Bonne idée, c'est implémenté. Cf https://github.com/nono/img-LinuxFr.org/commit/9e5d88eff1e64ba93a5c7b9b8b5512b02f102b0c et https://github.com/nono/linuxfr.org/commit/f78fe68529ef6fc253bf4be6fb5ee83022b9ada4
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Améliorer img. Évalué à 3 (+0/-0).
Cf https://github.com/nono/img-LinuxFr.org/commit/5f777854626b04620a7ee5dbacbf1832b178a9b5 et https://github.com/nono/img-LinuxFr.org/commit/54018f4085dd14cdd09bbfff874c8863549175b9
[^] # Re: Une population qui vieillit
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 10.
Oui, d'ailleurs, nous aimerions bien avoir un graphiste ou recevoir régulièrement des contributions graphiques. Quelques idées :
[^] # Re: origine
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 10.
C'est fait. Cf https://github.com/nono/linuxfr.org/commit/5b06195cc876d9badd5c48dd085aa786a211cda4
[^] # Re: origine
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 4.
On en risque pas de le perdre vu qu'il n'est déjà pas utilisé.
Pour profiter du cache du navigateur, il faudrait que les URL utilisées soient exactement les mêmes sur LinuxFr.org que sur d'autres sites. Or, nous passons dans les URL gravatar, l'adresse de l'avatar par défaut. Du coup, les URL utilisées pour charger les gravatars sont différentes sur les autres sites et on ne profite pas du cache du navigateur quand on arrive sur LinuxFr.org depuis un autre site avec des gravatars.
[^] # Re: redis vs signature
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 3.
Redis est capable de réécrire ses journaux en tâche de fond pour les compacter. Ça se fait sur une copie et, quand c'est prêt, redis intervertit les 2 journaux et roulez jeunesse !
[^] # Re: Bonne idée
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 5.
Je viens de faire le test et chez moi, ça marche. Est-ce que d'autres personnes ont rencontré le problème ? Si oui, avec quelle(s) image(s) ?
[^] # Re: Pour les images qui sont actualisées à intervalles réguliers
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 4.
C'est sur ma TODOlist. Cf https://linuxfr.org/news/un-nouveau-reverse-proxy-cache-pour-les-images-externes-sur-linuxfr-org#comment-1368029
[^] # Re: origine
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 4.
Je vais peut-être utiliser img pour les avatars. C'est juste pour le moment, je n'ai pas tellement réfléchi à comment le faire, si c'est vraiment pertinent out non, etc. Mais j'aime bien l'idée :)
Actuellement, c'est la version au moment du premier affichage qui est privilégiée, mais ça devrait évoluer rapidement. Dès que je trouve un peu de temps, je vais faire en sorte que l'on aille chercher les mises à jour de l'image.
[^] # Re: Très similaire à Thumbor
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 3.
Effectivement, je ne connaissais pas Thumbor, mais ça a l'air d'être très sympa et ça aurait pu nous servir (il aurait juste fallu le modifier un peu pour les questions de modération).
[^] # Re: Un essaie
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 4.
Bien vu, j'ai corrigé.
[^] # Re: origine
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 7.
Un des caractères utilisés en base64 est le slash (
/
). Si plusieurs slashs se retrouvent collés dans l'URL, certains navigateurs les compactent en un seul slash.On pouvait déjà le faire avant. Les gens qui postent des images le font pour qu'elles soient vues, donc je doute qu'ils aillent chercher des URL si compliquées. Au pire, c'est juste que l'image ne va pas s'afficher, rien de bien méchant.