Migration BBcode

Je suis en train de corriger des balises dans mes sorties (italique, gras, soulignement et quelques liens) puisque cela ne s’est pas fait automatiquement !
y’ a pas moyen que ces sorties n’ apparaissent pas de nouveau en page d’accueil ? (il m’en reste 150 à vérifier)

Inutile de t’embêter à corriger à la main !
C’est juste que certains champs n’ont pas été corrigés. Il faut que le robot les corrige.
Il s’agit au moins des champs texte « Conditions » et « Commentaire sur l’accès », mais il y en a peut être d’autres.

Pour l’affichage sur la home, il s’agit d’un bug. Apparemment, la première fois qu’on modifie le texte d’une sortie créée sur la V4 ou la V5, ça entraine un affichage sur la home.
Un exemple de modif : Camptocamp.org

Ok, merci.
Je vais arrêter là. Vu la météo, ça occupait bien.

Hello @stephfb,

En effet, je n’ai pas encore passé sur les docs persos (pour une raison technique). Je les ferais en tout dernier.

Dans l’aide sur la mise en forme du texte, j’ai déplacé la section concernant les sous-titres en tête de l’article.
En effet, s’il y a 1 chose à savoir, c’est l’utilisation des sous-titres.
Il ne faut pas utiliser la mise en forme des caractères (gras, souligné, etc) pour faire un sous-titre, mais utiliser uniquement la balise de sous-titre. Normalement, on n’a rarement besoin de mettre en forme des caractères. Par contre on a toujours besoin des sous-titres, dès que le document contient un peu d’info, pour le structurer.
La balise de sous-titre permet de générer du html comportant des indications que c’est un sous-titre. Ces indications de structure du texte, outre la possibilité de changer le style des sous-titres via une modif de design, permettent d’améliorer le rendu dans certains cas, par exemple avec les navigateurs conçus pour les handicapés.

@bubu, je t’ai répondu sur la discussion rattaché à la page d’aide en question.

Bon, sinon, sans avis supplémentaire, je ferais une passe pour supprimer les balises col présentes sur les documents.

Ce serait bien de sauvegarder la liste des articles qui contienne des col.

J’ai essayé d’utiliser un <div>. Ca fonctionne, mais si le <div> contient du L#, ça ne décode pas le L# et ça met tout au km.

Oui, le code contenu dans la plupart des balises HTML n’est pas interprété. Il faut vraiment éviter pour le moment de les utiliser, tant qu’on a des inconnus la dessus.

Bon, j’ai une petite nouvelle :

Ce bug est hyper pénible à fixer, ca demande d’aller bidouiller loin dans le parser, sans garantie que ca soit vraiment stable et rigoureux. C’est du coup bien plus simple et stable de recoder une extension.

En pratique :

  • La balise <span id="ancre-fixe>` pourrait être autorisée ailleurs que dans un titre. Mais je recommande très vivement de l’interdire si nous n’en avons pas l’usage. Il y a des effets de bord pénibles à trop permettre l’utilisateur de choisir des id, cf le bug de la page qui ne s’affiche plus.

  • La syntaxes suivantes pour les titres seront valides :

    Titre simple

    Titre avec # emphase

    Titre avec un id fixe {#id-fixe}

    Titre avec # emphase et avec un id fixe {#id-fixe}

  • @rabot se chargera de retransformer dans l’autre sens les balises <span id="id-fixe"></span> vers {#id-fixe}

Ok pour tout le monde (extension, et interdiction du span) ?

Désolé pour l’aller-retour :confused:

Ok pour moi.
On préfixe quand même l’ID ?

(Pour les autres, c’est une discussion technico-technique qu’on a sur la ML de dev.)

Le sujet est annexe mais oui, il va falloir faire quelque chose pour ce problème, on ne peut pas se permettre de péter les pages avec un markdown qui semble totalement anodin. D’ailleurs, tu n’as pas donné ton avis sur la ML :wink:

PI, pas d’opposition, bye bye balise [col]!

Elle n’est plus.

amen!

Par contre, il va falloir nous indiquer comment faire le job en html.

Oui, je sais :slight_smile:

Il y a un gros travail de compréhension à faire dans l’interaction du parser markdown et l’HTML.

Pour le moment, je vous conseille de ne surtout pas faire de tentative en HTML, au risque de voir vos pages changer de rendu à cause de modification du parser.

Une fois le travail de compréhension fait, et les ajustements du parser nécessaire codés, je rédigerais une aide claire.

Hello,

Sans contre-avis, je compte donc supprimer cette possibilité (pas pour la prochaine release, mais celle d’après, histoire de laisser le temps à @rabot de re-migrer).

je ne connaissais pas l’existence de [hr] auparavant, en tous les cas le même job était fait par [—], et je ne crois pas que cette balise ait été migrée. Est-ce possible de l’ajouter à la liste ?

ah, je l’ai pas vu cette balise, tu as un doc qui la contient sous la main?

Je la migrerais dès que je pourrais.

ben non, pas de doc, et elle ne figurait pas dans une dernière version de l’article d’aide bbcode. Mais je peux t’assurer qu’elle existait et fonctionnait.

Cette balise n’existait que sur le forum de la V5. Utilie principalement pour séparer un commentaire de la modération du reste du post.
Je ne l’avais pas mis dans le topoguide, car dans un doc c’est la plupart du temps inutile. Quand on a besoin de séparer un doc en plusieurs parties, c’est souvent qu’une organisation via des sous-titres est nécessaire. Et donc il faut utiliser les sous-titres, c’est plus clair pour le lecteur, et plus pratique (sommaire et ancre possible).
Sur le web en général, la balise hr est souvent utilisée pour avoir le même comportement que la balise [p] : autant utiliser la balise [p].

1 Like