Il arrive régulièrement que le titre d'un lien soit tronqué de façon disgrâcieuse à 100 caractères, vraisemblablement sans que les soumetteurs ne s'en rendent compte. Certaines pages ont en effet des titres à rallonge. Augmenter la longueur du champ de la base de données (par exemple à 255) permettrait de mitiger ce problème.
Si on inclut deux symboles $ dans un bloc de code (donc entre backticks), LinuxFR interprète parfois ceci comme un bloc d'équation LaTeX.
Exemple:
Bla bla `clef:${foo}:${bar}` bla bla
va donner:
bla bla
clef:{mathjax} {foo}:{bar}bla bla
J'ai eu le cas en écrivant un commentaire.
Quand on change de page dans le suivi, le filtre est réinitialisé.
Il n'est donc pas possible par exemple de parcourir la liste des entrées fermées, car aussitôt qu'on clique sur la page 2 le filtre est réinitialisé aux entrées ouvertes.
L'OCSP Stapling permet aux client de vérifier la validité du certificat sans faire de requête auprès de l'autorité de certification. Letsencrypt eux-mêmes recommendent de l'activer pour des questions de performances, respect de la vie privée et aussi parce que ça leur coûte moins cher :-)
Avec nginx c'est assez simple à activer, il faut:
ssl_certificate /etc/letsencrypt/live/.../fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/.../privkey.pem; # managed by Certbot
# ajouterLes totoz en surimpression ne sont pas bien positionnées quand la fenêtre est suffisamment large pour dépasser la largeur maximale de la colonne, car l'offset est calculé à partir du coin supérieur gauche du document (donc, marges inclues) alors que la position est définie en fonction du coin supérieur gauche de la colonne (donc, marges exclues). Ceci résulte en une situation dans laquelle la totoz en surimpression est décalée sur la droite de la largeur des colonnes à la gauche (…)
Aujourd'hui, il est toujours possible d'accéder à linuxfr.org sans TLS, via http, et c'est même l'accès "par défaut" pour les navigateurs. Il semble même qu'il soit possible de s'identifier sans TLS, ce qui signifie que le mot de passe passe en clair sur le réseau, ce qui n'est pas optimal en termes de sécurité et confidentialité.
À l'heure actuelle, est-il toujours pertinent de conserver un tel accès non-chiffré?
Au niveau de nginx, il s'agit juste d'une configuration toute simple:
serverLa CSS par défaut utilise comme police de caractère la police "sans-serif" définie dans les navigateurs. Cette police est souvent (hormis pour les gens qui ont modifié la configuration de leur navigateur, càd quasiment personne) une "vieille" police telle que Verdana (sous Windows) ou DejaVu Sans (sous Linux), qui ont la particularité de mal gérer les systèmes de hinting modernes.
Cela se traduit par l'apparition de pseudo-gras quand on augmente la taille de la police (typiquement, sur ce site, en (…)
Bonjour,
Pour les gens qui tentent de modifier les CSS, une information qui serait fort utile serait l'évolution, chaque mois, des statistiques relatives aux user-agents utilisés pour accéder à LinuxFR. En effet, cela peut déterminer de la possibilité (ou non) d'utiliser telle ou telle fonctionnalité de CSS, cf. http://caniuse.com/
Actuellement, il existe des statistiques Webalizer mais elles sont inexploitables (le plus détaillé qui est plublié, c'est "51% de Mozilla/5.0"…)
Quand j'ai essayé de mettre une ligne avec une variable bash préfixée par un $, ben ça a déconné:
`{mathjax} echo "`IP" >> hosts
Bonjour,
Lorsque l'on exporte un contenu au format Markdown, je pense qu'il serait utile de rajouter des méta-données, notamment:
Je pense que c'est important pour une question de transparence et même de propriété intellectuelle (après tout la licence c'est CC-BY-SA, et là on n'a pas le BY).
Il me semble que traditionnellement, les métadonnées en Markdown peuvent être ajoutées au début du (…)
Je pense qu'il serait judicieux de définir une largeur maximale pour les pages du sites, dans la mesure où avoir des lignes de 3 km rendent la lecture compliquée avec des écrans à grande résolution (genre écran "HD" en 1920x1080). En plus l'effet graphique laisse à désirer notament au niveau des illustrations.
Alternativement ou en complément, il serait envisageable de "zoomer" automatiquement la taille des polices et images afin d'obtenir le même résultat: la réduction de la taille des lignes (…)
Bonjour,
Afin de faciliter le premier contact aux contributeurs potentiels de linuxfr, je propose de relocaliser les divers dépôts de code de linuxfr au sein d'une "organisation" dans github. Ce serait plus clair que la situation actuelle où les dépôts sont mélangés avec d'autres choses sur le compte de nono, et où on n'est pas certain que tout y est…
Qu'en pensez-vous?
L'ajout de étiquettes est présentement faite avec un truc en javascript. Cependant, au moment de la validation d'une nouvelle étiquette, celle-ci n'est pas ajoutée à la liste des étiquettes actuellement visibles. Elle apparaît cependant en rafraîchissant la page.
Testé dans le cas de l'ajout d'une étiquette à un journal.
768px correspond à la largeur d'un ipad vertical. Il serait sympa d'éclipser la sidebar dans ce cas-là car la colonne de droite est alors trop étroite que pour être lisible.
Je n'ai pas d'ipad mais j'utilise souvent un navigateur sur moins d'un demi écran (environ 650px de large), et pour l'instant ce ne devient agréable à utiliser que sous les 580px de large. C'est domage pour 70px.
En regardant certains contenus ou commentaires (par exemple, cette dépêche) on peut remarquer que certains utilisateurs se "trompent" en encodant l'adresse de leur site perso.
Dans l'exemple ci-dessus on remarque l'absence de "http://" mais j'ai déjà vu également des fautes de frappes du style ':' ou '/' manquant. Du coup, quand on clique, on arrive sur une page 404 de ce site-ci.
Il serait probablement bienvenu de vérifier lors de l'encodage si l'adresse est correcte, et de corriger les (…)