Suivi — Syntaxe markdown Interaction entre $$ (mathjax) et `` (code)

#3203 Posté par  . État de l’entrée : ouverte. Licence CC By‑SA.
Étiquettes : aucune
0
6
juin
2024

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.

Suivi — Suivi La pagination du suivi ne prend pas le filtre courant en compte

#3183 Posté par  . État de l’entrée : invalide. Assigné à Adrien Dorsaz. Licence CC By‑SA.
Étiquettes : aucune
0
25
jan.
2024

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.

Suivi — Administration système Activer l'OCSP Stapling dans la configuration nginx

#3042 Posté par  . État de l’entrée : ouverte. Licence CC By‑SA.
Étiquettes : aucune
1
16
nov.
2023

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:

  • Ajouter la config pour le stapling dans la config nginx du site:
  ssl_certificate /etc/letsencrypt/live/.../fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/.../privkey.pem; # managed by Certbot
  # ajouter
(…)

Suivi — Tribune Les totoz en surimpression ne sont pas bien positionnées

#3033 Posté par  . État de l’entrée : corrigée. Assigné à Adrien Dorsaz. Licence CC By‑SA.
Étiquettes : aucune
1
18
août
2023

Les 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 (…)

Suivi — Administration système Enlever l'accès sans TLS? (rediriger http://linuxfr.org vers https://linuxfr.org)

#1808 Posté par  . État de l’entrée : corrigée. Assigné à Benoît Sibaud. Licence CC By‑SA.
Étiquettes : aucune
3
3
avr.
2018

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:

server
(…)

Suivi — Feuilles de style (CSS) Utilisation d'une police "zoomable"

#1293 Posté par  . État de l’entrée : invalide. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes :
2
18
mar.
2014

La 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 (…)

Suivi — Statistiques Statistiques détaillées sur les user-agents

#1286 Posté par  . État de l’entrée : invalide. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes : aucune
0
13
mar.
2014

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"…)

Suivi — Syntaxe markdown Bug d'interaction entre les maths et les blocs de préformatés

#1282 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes : aucune
2
12
mar.
2014

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

Voir https://linuxfr.org/users/nud/journaux/toi-aussi-installe-ton-propre-linuxfr-en-trois-lignes-de-bash-et-contribue

Suivi — Administration site Export Markdown: ajouter des méta-données

#1280 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes : aucune
4
12
mar.
2014

Bonjour,

Lorsque l'on exporte un contenu au format Markdown, je pense qu'il serait utile de rajouter des méta-données, notamment:

  • le nom des auteurs
  • la data de publication
  • la licence si CC
  • les tags
  • l'url initiale du contenu

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 (…)

Suivi — Feuilles de style (CSS) Limiter la largeur maximale du site pour les grands écrans

#1267 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes : aucune
2
28
fév.
2014

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 (…)

Suivi — Proposition Organisation "linuxfr" sur github

#1264 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes : aucune
4
24
fév.
2014

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?

Suivi — Étiquettes La liste des étiquettes visible n'est pas mise à jour quand on ajoute une étiquette

#1257 Posté par  . État de l’entrée : ouverte. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes :
8
28
jan.
2014

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.

Suivi — Feuilles de style (CSS) Layout "verticalisé" pour la CSS par défaut sous 768px

#980 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel.
Étiquettes : aucune
0
10
août
2012

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.

Suivi — Comptes utilisateurs Vérifier le format de l'url vers le site perso

#974 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel.
Étiquettes : aucune
0
2
août
2012

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 (…)