Adrien Dorsaz a écrit 887 commentaires

Ok, il semble que tu connaisses déjà des différences. Du coup, tu pourrais préciser la question ?

Là elle est très large, c'est pour ça que je t'ai donné le lien de la FAQ de Matrix 😉

Non, ça n'est pas pareil.

Hello,

J'ai proposé le patch ici pour régler ce problème: https://github.com/linuxfrorg/linuxfr.org/pull/259

Le seul soucis, c'est que pour pouvoir utilisé la propriété table-layout des tableaux, je suis obligé de définir la taille width: 100%. Je pense que c'est pas si mal, mais ça va changer un peu le rendu des tableaux qui sont dans des contenus (les statistiques ne sont pas affectées :)).

Pour voir les cas que j'ai testé, c'est à la fin de cet article et dans le premier commentaire.

Hello,

Si je ne m'abuse, actuellement, toutes les tribunes (/board, celle de modération, celle des rédacteurs, celles pour chaque dépêche) est limité à 100 messages:

# encoding: utf-8

# It's the famous board, from DaCode (then templeet)
#
class Board
  include ActiveModel::Model
  include Canable::Ables

  NB_MSG_PER_CHAN = 100

### Constructors and attributes ###

  attr_accessor :id, :user_name, :user_url, :user_agent, :object_type, :object_id, :message, :created_at

Rendre le contenu illimité et sauvé en tout temps, ça me semble un peu exagéré, car chaque dépêche a sa propre tribune et car elles ne sont pas vidées à la publication d'une dépêche (la modération a toujours accès à cette tribune).

Personnellement, je comprends que la tribune dans une dépêche comme un lieu de discussion rapide et informelle pour les personnes qui sont en train de collaborer ensemble. De ce point de vue, je ne vois pas l'intérêt de conserver un nombre illimité de messages.

Par contre, on pourrait imaginer augmenter la limite à quelque chose de plus adapté ?

Sinon, pour les messages et prises de décisions les plus importantes pour la collaboration en rédaction, autant écrire leur résumé directement dans la dépêche: ça permet de s'assurer que tout participant à la dépêche voie ce texte puisqu'il est dans le corps de la dépêche.

Finalement, je serais donc plutôt pour augmenter la limite un peu, mais ne pas la supprimer pour éviter de surcharger les disques dures de LinuxFr (et le service Redis). A voir si Bruno est aussi de cet avis.

Pour cette série, je viens de proposer un PR qui remanie pas mal le layout pour le passer à nouveau à 2 colonnes:

Après plusieurs essais de design avec @mjourdan pour la réorganisation de l'espace de rédaction (voir les discussions dans le PR #242), le résultat est le suivant:

• Le layout est de nouveau sur 2 colonnes
• La colonne de droite est un panneau qui prend tout l'espace vertical et qui peut être caché.
• Quand le panneau de droite (#toolpanel) est affiché, la zone de rédaction est légèrement réduite
• La barre d'outil a été ajoutée dans ce layout (#toolbar) et, contrairement aux autres pages, elle ne contient que 2 bouttons sur la droite: un pour afficher/cacher le panneau de droite et un second pour afficher / cacher un sommaire
• Pour gérer le fait d'afficher / cacher des portions de la page, un nouvel outil JavaScript popup a été crée.
  • Ce système est réutilisable pour d'autres parties de l'espace de rédaction. Par contre, je le déconseillerai sur le reste du site, car ça rend JS indispensable (ce qui est déjà le cas pour l'espace de rédaction)
  • Lors d'un clique:
  • Le JavaScript lit l'attribut data-popup-id de l'objet cliqué.
  • Cet identifiant doit correspondre à un id d'un élément de la page. Le JS retrouve cet élément et lui ajoute (ou retire) l'attribut data-popup-shown
  • Comme plusieurs éléments peuvent déclencher ce JS, le JS retrouve tous les déclencheurs qui ont l'attribut data-popup-event-#{id retrouvé plus haut}
  • Enfin, il est possible d'ajouter également des listeners qui souhaitent "écouter" les changements d'état d'un élément. Dans l'élément à afficher/cacher, il faut ajouter l'attribut data-popup-listner-ids avec une liste d'identifant séparé par des espaces.
  • Le JS ne gère que les attributs des éléments du DOM. Tout ce qui est affichage et transitions est géré directement par CSS (à créer à la main selon les besoins).

D'après mes tests, ce code est compatible jusqu'à IE 10, je n'ai pas essayé de navigateurs plus vieux. Si vous voulez tester, ce code est actuellement installé sur https://dlfp.adorsaz.ch (utilisateur: moderateur, mot de passe identique).

PS: Je n'ai pas le courage de faire le ménage dans les commits, on y voit donc tout l'historique de rechreche de design… Est-ce que vous voulez que je fasse un squash avec toutes les modifications ? Ça ferait un gros commit, mais ça éviterait de polluer l'historique git…

Pour l'instant, je me limite au navigateur Internet Explorer 10 (sorti en 2012). Il permet de faire déjà pas mal de choses et il a quand même déjà 7 ans :)

Merci, ça semble bien fonctionner :-)

Ahaha, je me suis trompé, le cache est activé pour 86400*0* secondes et donc 10 jours, pas juste 1 :-)

Je me suis rendu compte quand j'ai préparé un PR qui active le mimetype pour woff2 et le cache pour ces polices:

https://github.com/linuxfrorg/admin-linuxfr.org/pull/5

J'ai fais ces modifications à la main et je ne les ai pas testées, alors il pourrait y avoir une erreur qui s'y est glissée…

Bon en vrai, la branch master de ce dépôt git n'a pas bougé depuis 2017, c'est peut être pas le bon endroit.

Hello,

Si je ne me trompe pas, c'est la configuration du serveur nginx qu'il faudrait ajuster.

J'ai regardé le contenu du dossier /public/fonts et je dirai qu'il faudrait activer le cache du navigateur pour tous les fichiers présents (les extensions y présentes sont pour l'instant afm, otf, ttf, woff, woff2).

Voici les résultats avec curl et différents fichiers (on voit bien que cache-control est présent pour une image et pour une police ttf, mais pas pour les nouvelles en woff et woff2):

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/images/markdown.png
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:35:12 GMT
content-type: image/png
content-length: 298
last-modified: Sat, 24 Feb 2018 14:16:08 GMT
etag: "5a9173a8-12a"
expires: Sun, 29 Sep 2019 18:35:12 GMT
cache-control: max-age=864000
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/LinLibertine.ttf 
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:36:20 GMT
content-type: font/truetype
content-length: 509248
last-modified: Wed, 13 Jul 2011 12:40:26 GMT
etag: "4e1d923a-7c540"
expires: Sun, 29 Sep 2019 18:36:20 GMT
cache-control: max-age=864000
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/Lato-Regular.woff
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:35:37 GMT
content-type: application/font-woff
content-length: 309192
last-modified: Sat, 24 Aug 2019 20:47:48 GMT
etag: "5d61a274-4b7c8"
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/Lato-Regular.woff2
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:36:26 GMT
content-type: application/octet-stream
content-length: 182708
last-modified: Sat, 24 Aug 2019 20:47:48 GMT
etag: "5d61a274-2c9b4"
x-content-type-options: nosniff
accept-ranges: bytes

Je suis étonné que l'on ait mis que 86400 secondes, ça fait juste un jour de cache. Personnellement, surtout pour les polices, j'aurais mis quelque chose comme 1 semaine, car c'est vraiment rare de les changer.

Hello,

J'ai regardé un peu le code et il me semble que pour l'instant LinuxFr ne permet pas de retrouver des informations des autres utilisateurs.

C'est bien les avatars de tous les correspondants dont tu aurais besoin ?

Si oui, il faudrait faire une api du style users/{id or name}. Est-ce envisageable par les administrateurs ?

Comme tous les avatars ne sont pas stockés sur LonuxFr, je pense que seule l'API pourra te donnerles bonnes URLs.

PS: je n'ai pas réussi à utiliser l'API avec Insomnia. Je n'ai pas bien compris l'oauth2 je crois… Si tu pouvais me guider je pourrai tester plus facilement :-)

Je pense qu'on s'est tous fait "bousculer" un jour dans les commentaires […], suffit d'aller faire un tour, boire un verre d'eau, et réaliser qu'aussi passionantes soient les discussions sur DLFP ça reste essentiellement du hobby.

Je pense que tu soulèves un point très important et pas toujours facile à appliquer quand les sentiments sont à vif.

Il faut clairement apprendre à prendre du recul par rapports aux commentaires des autres sur Internet (et aussi par rapport aux systèmes de notation).

Un problème est que les silos à publicité comme les réseaux sociaux font leur beurre sur le fait de nous faire réagir très vite et de manière inconsidérée : ça leur fait plus de contenu, plus de pages affichées (et donc de pub) et plus de revenu au final.

Du coup ils forcent les gens à ne plus prendre de recul et quand ils arrivent ici, les utilisateurs ont l'impression que le karma est le point essentiel de LinuxFr.

Alors que non, bien au contraire: pour moi, LinuxFr n'est pas un réseau sociale, mais un site de partage d'informations (l'espace de rédaction collaborative est vachement bien fait !) et d'entre-aide.

L'essentiel est donc dans le contenu, pas dans le jugement des autres via le système de karma (par contre le contenu des commentaires fait parti du contenu créé par la communauté).

Bon, si j'ai bien compris tes commentaires, ce correctif devrait rendre plus lisible le site:
https://github.com/linuxfrorg/linuxfr.org/pull/248

Je me réjouis de voir un nouveau journal pour m'expliquer que les polices sont devenus trop énorme :D

Je ne te trouve pas assez ambitieux: l'user agent devrait faire lui-même les CSS pour tous les sites.

Oui, j'ai vu ce matin, ma question pour Zenitram et arnaudus est: est-ce que c'est bien de ce changement que tu parles ?

Si c'est ça, j'arrive à reproduire et je pourrais faire un correctif :-)

Est-ce que tu peux répondre à ce commentaire stp ?

Je n'avais pas vu la différence quand j'ai changé la police. Il semble bien que le rendu est un peu plus petit et du coup que les interlignes semblent plus grand.

Comme ça je peux voir si Zenitram et toi, vous parlez du même problème.

Dis-moi, le soucis de taille, est-ce que tu le vois dans cette comparaison (après / avant):

Si c'est bien de ce genre de changement que tu parles, je ne l'avais pas vu effectivement (même quand j'ai fait cette capture d'écran).

Si non, je ne suis vraiment pas capable de reproduire ton problème.

L'idéal serait de proposer le nouveau design d'un coup, oui.

Mais je n'ai pas le temps ni la motivation ni les moyens de tout faire. Même si c'était possible pour moi, ce n'est pas forcément le cas pour mjourdan et Bruno Michel.

On a déjà fait des tests pour l'espace de rédaction et c'est vite énorme les changements à mettre en place: https://github.com/linuxfrorg/linuxfr.org/pull/242

Pour moi, c'est beaucoup plus rassurant de casser ce bloc de modifications en plus petit morceaux. C'est plus facile à repérer les problèmes (autant système qu'utilisateur).

D'ailleurs, je n'ai qu'un écran avec densité de pixel non-élevée. Je ne peux donc ni reproduire ni corriger ce genre de bug.

Par contre la solution de PsychoFox me semble très pertinente :-)

Hier, j'avais oublié de mettre les polices alternatives système serif et sans-serif.

Du coup, quand on bloquait les polices web, tout le site était en serif.

C'est donc possible qu'il y aie eu des rendus avec des polices à empattement uniquement.

De rien, c'est amusant de bidouiller le code :-)

Merci à Bruno également pour les mises en production rapides !

J'avais oublié en effet de définir la police comme "cherche d'abord sur le disque, si non télécharge".

C'est corrigé.

Remarquez que la police n'est pas téléchargée à chaque chargement de page: le navigateur la garde en cache. Donc les 250 Kio et 0.5ms d'attentes, c'est 1 fois ;-)

Enfin, j'ai aussi ajouté les alternatives système (serif et sans-serif). On devrait être au top maintenant.

Oups, je me suis trompé dans tout le texte:

s/Lota/Lato/

désolé :)

Ton analyse est tout juste :-)

J'avais essayé avec "Lota Regular", pour avoir une idée, regardez le commentaire plus bas.

Hello,

J'essaie par petits pas de faire passer LinuxFr au nouveau design proposé par mjourdan, il y a déjà quelques temps.

Pour aller par petits pas, je voulais déjà changer les polices, car c'est déjà faisable avec le design actuel. J'ai bien aimé l'idée d'utiliser une police à empattement pour les titres et une police sans empattement pour les contenus.

Tu vois donc déjà, que, tout le site n'est pas à empattement au contraire de ce que pourrais faire penser ton journal. Ce que j'aime bien avec la police à empattement, c'est que le rendu permet de se passer du gras pour les titres, car la police et la taille les distingue bien du contenu.

Maintenant, c'est vrai que j'ai eu un doute quand j'ai installé la police "Lato Light" au lieu de "Lato". Le rendu tel que vous le voyez maintenant, est bien celui prévu (la couleur de la police est bien noir, mais la police est plus fine.

Lato Light	Lato

(Cliquez sur les images pour les télécharger)

Je trouve que Lato (Light ou non) est déjà plus lisible que la police "Sans" précédente, je distingue mieux les lettres personnellement.

En regardant ces 2 rendus, je trouve que les boutons et menus sont mieux avec "Lato Light" (surtout pour le pied de page). Je voulais donc proposer une solution ou on garde "Lato Light" pour le site en général, mais que l'on utilise "Lato" pour les contenus.

Tiens, tout ça mériterait un sondage pour avoir un avis globale :-)

PS: Pour tester en live ce que ça donne avec "Lato", il vous faut ouvrir la console web et remplacer "Lato Light" par "Lato" dans le style CSS.

Ça marche aussi avec les domaines dynamique du style dyndns ?

Je ne sais pas, je n'utilise pas ce genre de service. Je te laisse chercher.

Si la machine qui demande le certificat est sur un réseau A et le serveur DNS sur un réseau B qui gère le domaine (les deux étant relié par une liaison quelconque), ça peut fonctionner ?

Tant que ta machine sur le réseau A peut donner un ordre de mise à jour DNS au serveur le réseau B, oui.

L'autre condition est que la machine du réseau A puisse envoyer des requêtes HTTPS sur Internet pour communiquer avec le serveur ACME.