Produits Entr'ouvert » Combo

Mais mon problème de base avec ce ticket c'est qu'il fait passer une cellule évidente (un seul champ dans lequel taper du texte peu importe lequel) à une cellule qui propose aussi de taper un titre, avec des questions qui se poseront quant à la relation entre celui-ci et le texte libre

Une cellule évidente ? pas de mon point de vue.
Toutes les cellules ont un champ titre qui correspond au titre de la cellule. Cette cellule fait exception.

Pour lui donner un titre, on en revient donc à bidouiller du code CSS pour appliquer le style "titre de la cellule" au premier h2 du corps du texte (et qui n'est documenté il me semble nulle part) et qui rend encore plus confus l'utilisation de l'option foldable qui ne fonctionnera pas si ce h2 posé manuellement n'est pas présent.
Au delà de cela, ça crée une exception dans le style et le markup de cette cellule, dont les marges avec le bord de la cellule sont alors gérées à coup de margin sur les éléments du corps de texte (mais pas sur tous les éléments, car tous les lister serait assez contre-productif et complique la maintenance, du coup, pas d'alignement typo garanti et souvent des lignes de patchs dans les thèmes). Cette exception complique encore plus le besoin de pourvoir ajuster les marges des cellules (voir #64406 qui a ressorti ce ticket d'outre tombe).

Ajouter un champ champ titre optionnel permetterait donc :

• Éviter les bidouilles et à terme nettoyer les exceptions pour cette cellule dans le core de publik-base-theme
• Pouvoir ajouter un h2 en premier enfant de corps de texte qui ne soit pas un titre de cellule (ne pas appliquer le style, parce que pas besoin mais besoin de conserver la hiérarchie des titres).
• Ajouter vraiment un titre à cette cellule (en option) et les options qui vont avec dans une UI similaire aux autres cellules.
• homogénéiser le markup des cellules.
• Avoir un alignement typo garanti pour les éléments du texte (quand je tape un h1, un h2, une ul/li, etc).

quant à la relation entre celui-ci et le texte libre

Je ne comprends pas ce qui te pose problème, tu pourrais préciser ?
le champ titre étant omiprésent pour les autres cellules, il a le même objectif : donner un titre à la cellule dans le style 'titre de cellule". Si on en veut pas on en met pas et on peut continuer comme aujourd'hui. Mais on permet une décorélation entre hiérarchie de titres et design.
Bref, je n'y vois que des avantages à la condition de pouvoir trouver une solution de migration de l'existant.

C'est agressif de valider un patch pour lequel je note la nécessité de discussion.

Voilà le patch. A noter que la migration est faite pendant l'affichage, mais que ça serait temporaire et qu'il faudrait la faire partout en base.

(je souhaiterais que ne soit pas proposé de patch avant qu'il y ait eu la discussion)

Ça implique qu'on ne supporte plus les mises en formes exotiques qu'autorisaient CKEditor et qu'elles seront supprimées (ajouter du gras ou des liens dans un titre). À voir si c'est acceptable.

J'ai lancé ce script :

from combo.data.models import TextCell
import lxml
import lxml.html
from lxml.etree import Comment
from io import StringIO
from django.urls import reverse
from django.db import connection

tenant = connection.get_tenant()

if hasattr(tenant, 'domain_url'):
    tenant_url = f'https://{tenant.domain_url}'

    for cell in TextCell.objects.all():
        if not cell.text:
            continue

        parser = lxml.etree.HTMLParser()
        html_document = lxml.etree.parse(StringIO(cell.text), parser)
        root = html_document.getroot()
        if root is None:
            continue

        title_nodes = root.xpath('/html/body/h2[1]')

        if title_nodes:
            assert len(title_nodes) == 1
            title_node = title_nodes[0]

            lxml.etree.strip_tags(title_node, Comment, 'meta')
            if len(title_node) or len(title_node.attrib):
                title_node_content = lxml.html.tostring(title_node).strip().decode()
                title_node_content = title_node_content.replace('\n', '').replace('\r', '')
                page_url = reverse('combo-manager-page-view', kwargs={'pk': cell.page.id})
                print(f'{tenant_url}{page_url} : {cell.get_reference()} : {title_node_content}')

sur amiens-prod, cd31-prod, combo.node1.hds.saas.entrouvert, combo.node1.prod.saas.entrouvert.org, cr-reunion-prod, grenoble-prod, lille-prod, moselle-prod, sitiv-prod, toulouse-1, villejuif-prod. J'ai une erreur de forwarding de stdin quand je me connecte à cnil-prod, et combo-manage tenant_command runscript ne trouve pas mon script sur sictiam-prod, je n'ai pas investigué.

Le résultat en PJ. On a donc 1446 cellules sur les serveurs mentionnés avec du markup dans le titre. Si on filtre les cellules pour lesquelles c'est "uniquement" de la mise en forme :

$ cat nested-cell-text-title.txt | grep -Ev '<h2(\s*(style|class|align)=".*")*>[^<]*(<[/]?(br|strong|em|u|i|b)>[^<]*)*</h2>' | wc -l                              
206

Dont 145 titres qui contiennent un lien

$ cat nested-cell-text-title.txt | grep -Ev '<h2(\s*(style|class|align)=".*")*>[^<]*(<[/]?(br|strong|em|u)>[^<]*)*</h2>' | grep '<a' | wc -l
145

Et 26 qui contiennent une image

$ cat nested-cell-text-title.txt | grep -Ev '<h2(\s*(style|class|align)=".*")*>[^<]*(<[/]?(br|strong|em|u)>[^<]*)*</h2>' | grep '<img' | wc -l
26

Le reste sont des titres avec des attributs id, ou contenant des styles ou des balises <font>.

Je propose donc de faire comme Fred suggère : migrer uniquement les titres qui ne contiennent pas de balises, ou une sélection de balises qu'on considère comme acceptable de supprimer (les strong par exemple). Ensuite ajouter une dépréciation pour les cellules qui restent pour plus tard migrer le style en utilisant la classe cell--title, ce qui supprimera le support du système actuel.

On migre automatiquement uniquement si le titre n'a pas de nœuds enfants et pas d'attributs. Je ferais le pad suggéré, le style pourra être migré dans un second temps.

Le résultat en PJ. On a donc 1446 cellules sur les serveurs mentionnés avec du markup dans le titre

dont plus d'un tiers c'est demarches.montreuil.fr pour entourer d'un <strong>; 94 cellules sur support.grandlyon.com qui ajoutent un text-align: center. Ces utilisations (strong/center) se trouvent aussi, moins massivement, ailleurs, on peut en faire des classes utilisables officiellement. (#70283 et #70284).

commit afde19c1fe399951ee4f796201c89a8a7968d980
Author: Corentin Séchet <csechet@entrouvert.com>
Date:   Wed Apr 27 11:41:49 2022 +0200

    misc: add title field to text cells (#42968)