Pleroma/Gegeweb

# Firefox : distinguer les sous-domaines avec l'outil d'aide à la saisie des identifiants

Lorsque la fonctionnalité "Renseigner automatiquement les identifiants et les mots de passe" est activée, Firefox affiche l'ensemble des identifiants communs au domain en cours. Ce comportement est peu pratique lorsqu'on utilise de nombreux services situés dans des sous-domaines différents d'un même domaine […] gemini://chezjln.xyz/blog/firefox-autofill-subdomain.gmi

@jln Je confirme !

@jln

Regarde la PJ pour ce que je te disais à propos de la position des commentaires.
Et toujours un problème de connexion à ta capsule avec Lagrange quand je suis en IPV6.

Ton ndm renvoit un enregistrement A et un AAAA, mais ton serveur n'écoute qu'en IPV4.

Il y a un bug avec Lagrange qui ne bascule pas sur l'IPV4 quand l'IPV6 ne répond pas.

@gerald Oui effectivement, j’ai également dû insérer des lignes vides dans le tpl. Faut que je corrige ça.

Concernant le problème IPV6, ça se règle côté serveur gemini (agate pour moi), ou côté système ? (je tourne avec #Yunohost)

En tout cas, pour cette première utilisation “en prod” (si j’ose dire), le constat que je fais est qu’il faut vraiment que je code un truc pour insérer un footer ou un header automatiquement. Ça va vite devenir lourd sinon d’insérer toujours les mêmes liens de retour à l’accueil.

@jln @gerald Retour à l'accueil : dans Lagrange, suffit de cliquer sur le haut de la page :)

@fouine

Oui tout à fait ! Mais c’est un peu embêtant d’être dépendant du client pour ce type de fonctionnement.

Et puis y’a pas que le retour à l’accueil : en l’occurrence, sur ma page y’a aussi le retour à l’index du blog.

@gerald

@jln --addr :::1965 au lieu de --addr 0.0.0.0:1965 pour démarrer Agate. Ça écoute alors en IPV6 et sous Linux la librairie utilisé traduit alors les adresses IPV4 en IPV6 et ça fonctionne en dual stack.

@jln @gerald Yep, j'ai cherché également a reproduire le principe de NavBar -> gemini://www.underworld.fr

@jln

Voilà.
Y'a pas qu'un client, et donc on ne peut pré-supposer de leurs fonctionnalités.

J'inclus systématiquement des liens de navigation interne en bas de mes pages.

@fouine
replies
1
announces
0
likes
0

@gerald @fouine bon en attendant vous pourrissez ma page de commentaires sur un article qui n’a rien à voir 😹

Je plaisante bien évidemment, mais ça illustre les limites d’un tel système de commentaires sur lequel on n’a aucune prise.

@jln

> Ça va vite devenir lourd sinon d’insérer toujours les mêmes liens de retour à l’accueil.

Bah regarde ma PR. ;)

@gerald ah oui, top !! 😃 😃

@gerald le test “if COMMENT_PLACE:” est toujours True puisque la variable est assignée plus haut dans le script ?

Faudra plutôt qu’on teste la présence de sa valeur dans la source, ou alors qu’on place le replace() dans un bloc try

@jln Pas si tu la fixe à False (normalement)

@jln Ou que tu ne la met pas dans la section config.

@gerald ah oui, je partais du principe que l’utilisateur n’a pas vraiment à toucher à cette assignation.

@jln
Tout ce qui est dans la section config est modifiable par l'utilisateur, c'est le but.
Là l'idée c'est soit tu définis l'emplacement dans ton template source soit non et ça va en bas de page.

D'ailleurs le script peut très bien tourner ailleurs (c'est mon cas) qu'à coté des répertoires sources et destinations.

Ça ça sera dans un prochaine PR la section config. ;)

@gerald
Justement, je ne l'aurais pas mis dans la section config 😉

L'utilisateur a le choix de spécifier l'emplacement des commentaires, mais pourquoi aurait-il à modifier le "mot clef" permettant de spécifier ce choix ?

@jln

Et pourquoi non ?

Un anglophone mettrait %%comments%%, un francophone %%commentaires%%, etc…

Ainsi le template est dans un langage personnel.
C'est ma façon de voir les choses.

@gerald Oui je comprends ; dans mon esprit, on a plutôt affaire à une syntaxe “imposée” par le logiciel. Tout comme la clef pour insérer un commentaire est %%toot-content, %toot-author pour son auteur, etc., la clef pour insérer le bloc des commentaires serait %%comments

@jln
En fait c'est un peut ce que je reproche à tous les systèmes de template que j'ai pu voir, ou de générateur de contenu.
Ce n'est pas assez souple. Ils imposent leur "langage" alors que ça n'est pas strictement nécessaire.

Si ce sont des "clef" (constantes) définies en début de code dans la section config l'utilisateur du script peut se faire sa syntaxe à lui lorsqu'il construit son template.

En plus ton projet me donne des idées… c'est une bonne base pour mon système qui partirait du text/gemini pour construire la version HTML.

Un genre de générateur de site/blog statique gemini/web.

Ça n'a pas l'air si compliqué au final.

Puis Python, je commence à comprendre ! ;)

@gerald C’est sûr que techniquement, rien n’empêche de proposer à l’utilisateur d’employer les noms de clef de son choix. Je me demande dans un tel cas s’il ne vaut mieux pas créer un “vrai” fichier de conf (notamment pour ne pas qu’une màj du script écrase la config utilisateur).

Pour le bloc des commentaires, en réalité on peut s’en tirer autrement : il suffit que la clef soit le nom du fichier tpl. On pourrait être libre de l’appeler comments.tpl, commentaires.tpl, topinambour.tpl…