SPIP

Alors plusieurs choses mélangées :
- tu confonds les liens et les boutons (des formulaires donc)
- je ne sais pas quelle version de Duplicator tu as, mais à priori pas la dernière, vu que l'intitulé est "Dupliquer ce contenu et ses enfants"
- les boutons sont toujours en text-align center, même SPIP ne fait rien sur ça, ce sont les styles de nav par défaut
- je ne sais pas pourquoi tu as l'un des boutons large et l'autre pas, normalement ils sont juste en inline, donc largeur suivant le contenu, et non pas 100%

Le sujet c'est l'apparence, qui est hétérogène et bancale...

J'ai bien la dernière version de duplicator mais oups j'avais édité le texte du lien avant le copie d'écran, pour voir si c'était mieux quand le texte tenait sur une seule ligne.
Cependant ça ne change rien à l'apparence hétérogène.

version cible svp ?

J'explicite ma première phrase de ma réponse ci dessus : il n'est pas utile que l'UI indique si une fonctionnalité est fournie par un lien ou par un bouton de formulaire. Et même c'est néfaste car forcément ça complexifie inutilement le décryptage de l'UI.

version SPIP 3.3.0-dev [24422]

C'est totalement faux et l'inverse : il faut absolument distinguer lien et bouton, car les liens ne font rien, ils amènent à un autre endroit. Tandis que les boutons modifient des choses dans la base de données, ce qui n'a strictement rien à voir. C'est la base de l'affordance de la différence entre les deux, ça ne doit surtout pas être amalgamé !

Tempère les mises en gras (ton discours) rasta, c'est bien un lien qui est affiché pour la suppression d'une rubrique :p

De plus, je crois me souvenir qu'on peut "styler" un bouton d'action afin qu'il ressemble à un lien.

Le ticket a au moins ce mérite : je viens enfin de saisir d'où sortent ces pseudo-boutons sur fond gris :D
C'est quand on active l'option « afficher uniquement le texte » dans les préférences utilisateurs. Le truc que j'ai du tester une fois il y a 10 ans et que j'avais complètement oublié depuis.

• #URL_TRUC|icone_horizontale{...}
• #BOUTON_ACTION

(Des fois on a direct des #URL_ACTION_AUTEUR mais c'est mal :p)

Et si je suis d'accord qu'il faut bien distinguer visuellement les boutons de formulaires et les simples liens, il y a des choses à harmoniser, ça fait un peu disparate dans l'ensemble.

Et +1 pour changer le titre du ticket

Je ne tempère rien du tout : si c'est un lien c'est une faute importante, et absolument aucune suppression dans la base ne doit se faire avec un lien HTML, balise <a>. Donc c'est un bug dans le code du noyau de SPIP, et donc sans rapport avec ce ticket.

Une fois que les bonnes balises sont utilisées suivant les comportements voulus (= un lien pour amener quelque part, et un bouton pour modifier la base), et bien je le répète, les liens et les boutons ne devraient pas être confondues, ce sont des actions totalement différentes. Quand un utilisateur a la vision d'un lien, il sait que ça va juste "changer sa vue", soit en l'amenant sur une autre page, soit en rechargeant un morceau de la page en cours (ajax ou ancre peu importe). Quand un utilisateur voit un bouton, il sait que ça va modifier quelque chose, ça va faire une action, ce n'est pas juste un changement de vue.

Les deux seules exceptions les plus courantes (dans tout il y a des exceptions, mais ça reste rare, ça ne veut pas dire qu'il n'y a pas une règle de base) :
- faire qu'un lien ait l'apparence d'un bouton si c'est un lien qui amène à une vue qui permet de modifier des choses, donc c'est comme si ce lien était la première étape de l'action (mais c'est bien un lien qui amène à changer de vue, ce n'est surtout pas un lien qui modifie directement quelque chose !)
- faire qu'un bouton ait l'apparence d'un lien, pour annuler une action, car il s'agit effectivement d'une non-action, de revenir au départ, à la vue de départ

Mais tout cela implique bien que les liens et boutons doivent absolument continuer d'être différenciés (colonne de gauche ou pas, n'importe où), et ces deux exceptions sont rares et réfléchies.

Pour illustrer, voici ce qu'on obtient selon la préférence utilisateur :

Texte + icône (le défaut)

Texte uniquement

• Des fois on a une bordure, des fois non
• Des fois les coins sont arrondis, des fois non
• Des fois c'est en dispay: block et ça prend toute la largeur, des fois non

Et quand on veut afficher un bouton d'action comme un lien, la taille du texte est plus petite.

Et je pense aussi que c'est pas rare que les gens utilisent |icone_horizontale au lieu de #BOUTON_ACTION uniquement pour avoir un bouton "plus joli", ou disons plus sémantique visuellement (comme avec le paramètre "del" qui ajoute un fond hachuré).

Petite proposition pour unifier un peu les liens icônes et les boutons d'actions :

• Police identique : taille, couleur, graisse
• Ajouter la prise en charge des classes del, add et edit pour les boutons d'actions : [(#BOUTON_ACTION{Glop,#URL,add})]

Ce qui donnerait ça :

Et comme c'est actuellement pour référence :

Et aussi : la préférence pour afficher le texte uniquement devrait juste enlever les icônes, sans autre différence de style

Et même à la réflexion, pour les boutons d'actions prendre un gris neutre au lieu de la couleur utilisateur (qui pique un peu les yeux des fois), pleine largeur et centrer le texte (si dans une colonne).

PS : j'ai retouché dans Photoshop et le profil colorimétrique a bougé, ce n'était pas l'intention.

Merci Rasta pour les explications. Désolé je suis pas expert mais ouf j'ai échappé à tes majuscules.

En regardant sur un autre SPIP je vois qu'il n'y a pas autant de différences donc certains pb viennent de mes propres css. Les boutons sont à droite sauf ceux de Duplicator et celui pour supprimer le logo (centré).
Les boutons de Duplicator sont auto-forms, alors ça justifie peut être un traitement particulier, mais plutôt qu'alignés à gauche, je les préférerais texte-centrés à width-100% de la colonne comme ceux présentés par Tcharlss ou nicod_.
Et le bouton pour supprimer le logo est tellement associé à l'image qu'il gagnerait à être remplacé par une simple croix dans un coin du logo, non ? Comme ça il n'y aurait plus ce centrage exceptionnel.

Les changements proposés sont chouettes aussi.
Et une simple croix en X rouge pour "Del" ? Ça serait plus léger non ?
Et pourquoi pas aussi un simple plus + vert pour "Add" plutôt qu'un + blanc sur fond rond vert ?

Tu fais une PR avec ta proposition de CSS tcharlss ?
Et je complète avec la modif de l'icône (ou j'en fais une deuxième)

Ok pour le PR avec le border-radius et la marge.

Pour l'icône je pense qu'il vaut mieux traiter ça à part dans un autre PR, en fait ça ouvre la porte à d'autres questions.
Est-ce que cette icône doit forcément signifier qu'on supprime un contenu ? Elle pourrait être aussi utilisée pour des boutons d'action qui dissocient des contenus par ex., sans les supprimer.

L'icône actuelle a le mérite d'être assez générique sur ce point, elle peut être utilisée dans un cas ou dans l'autre.
Sinon ça voudrait dire compléter les icônes et les classes qui vont avec pour distinguer plusieurs types d'actions :
- supprimer
- retirer ou dissocier
- annuler
- ...

C'est dans la branche de test issue_4468 : https://git.spip.net/spip/spip/src/branch/issue_4468

Se rendre sur ?exec=issue_4468 pour voir en vrai

Bon, c'était comme d'habitude un peu pus compliqué que ce qu'il n'y paraissait, et faut s'y retrouver dans ces CSS minifiées...

En résumé :

• Typo des icônes, boutons d'action et boutons de formulaires unifiées (couleur, police, graisse).
• Boutons d'actions et de formulaires unifiés aussi (padding, border-radius, couleur de fond)
• Portage des classes add, del, edit, config aux boutons d'actions, qui reprennent les icônes de la classe .icone
• Portage des des classes left, right aux boutons d'actions (et correction de .icone.right qui merdait)

Ça c'était pour la partie "porter certaines classes des icônes sur les boutons d'action et unifier les styles".
Tant qu'à faire, j'ai aussi ajouté une poignée de nouvelles classes génériques pour les boutons d'actions ou de formulaires (utilisées nulle part pour l'instant donc, mais dispos si besoin) :

• secondary pour les boutons secondaires
• block pour mettre un bouton en pleine largeur (automatique pour les boutons en colonne latérale)
• boutons_groupe pour encapsuler une séries de boutons adjacents.

En image :

Et l'actuel pour comparaison :

Pas mal du tout, avec ces nouvelles classes.
Mais tu as ajouté du padding sur les boutons par rapport à 4468_apres2.png, ils paraissent peut être un poil gros non ?
Et je me demande si le gris est bien la bonne couleur pour un bouton d'action, mais bon, on n'a pas non plus des masses de choix.
En tout cas, avec les deux vues côte à côte, ça rafraichit bien :)

Possible qu'il y ait plus de padding, la 1ère capture c'était sur des modifs faites à l'arrache dans l'inspecteur de firefox, j'ai pas refait du pixel perfect. Mais ouais on peut baisser je pense.

• Elle est déjà beaucoup utilisée un peu partout (bordures, fonds, etc.), c'est pour neutraliser un peu justement
• Et surtout, les icônes deviennent moins lisibles quand il y a une couleur trop saturée ou pas assez claire en fond.

Si tu veux corriger des trucs, hésite pas.

Je précise : il y a un peu de flex d'ajouté, je n'ai pas encore mis les préfixes navigateurs ni fait de fallback pour ceux qui supportent pas flex du tout (ah la plaie :p).

Super, peut-être une variante "important" qui justement là prend la couleur principale ? Amélioration mais comme il y a déjà quelques ajouts…

Ça semble sympa.
Ça pourrait pas être renommé le "boutons_groupe" en anglais (le reste des classes de cette catégorie est en anglais ; ça fait bizarre, même le .block que tu ajoutes...)

et faut s'y retrouver dans ces CSS minifiées

Pour info c'est débrayable avec define('_INTERDIRE_COMPACTE_HEAD_ECRIRE',true); ;)

RastaPopoulos :
peut-être une variante "important" qui justement là prend la couleur principale ?

Oui tant qu'à faire

marcimat :
Ça pourrait pas être renommé le "boutons_groupe" en anglais (le reste des classes de cette catégorie est en anglais ; ça fait bizarre, même le .block que tu ajoutes...)

Heu, du coup j'ai pas compris, tu suggères de tout mettre en français ou en anglais ?
L'un ou l'autre pourquoi pas, avec le mélange actuel on sait pas trop sur quel pied danser quand on arrive après pour ajouter des trucs.

Le .boutons_groupe à la place de .button-group c'était pour que ça soit cohérent quand c'est utilisé dans les formulaires :
<div class="boutons boutons_groupe"><input class="submit" ...></div>

Le .block c'est un peu pareil : c'est une classe qu'on peut passer en paramètre de |icone_horizontale et de #BOUTON_ACTION, et là actuellement c'est que des termes anglais (add, link, etc.)

C'est pas simple cette histoire...

b b :

faut s'y retrouver dans ces CSS minifiées

Pour info c'est débrayable avec define('_INTERDIRE_COMPACTE_HEAD_ECRIRE',true); ;)

Ah mais je parlais de l'écriture avec toutes les règles sur une ligne et sans espace dans les CSS :
.classe{truc:machin;chose:bidule;pouet:truc;}

J'ai perdu un dizième à chaque oeil à tout relire :p

tcharlss 🐽 a écrit :

RastaPopoulos :
peut-être une variante "important" qui justement là prend la couleur principale ?

Oui tant qu'à faire

Je dirais plutôt "primaire" (dans le sens couleur primaire mais bof) ou "principal", ou qqchose comme ça, plutôt que 'important".

Ah mais je parlais de l'écriture avec toutes les règles sur une ligne et sans espace dans les CSS :
.classe{truc:machin;chose:bidule;pouet:truc;}

J'ai perdu un dizième à chaque oeil à tout relire :p

Pareil, à chaque fois :)
Je proposerais bien de passer un coup de formatage sur tous ces fichiers, franchement, ça ferait pas de mal.
PhpStorm fait ça très bien.

On devrait en parler dans un ticket dédié, il faut qu'on se fixe des règles sur ce point comme on l'a déjà fait pour les PSRs.

+1 (et on avait évoqué aussi la question pour les squelettes d'ailleurs, à un moment.)

Je crois que le plus simple c'est de choisir une convention qui corresponde à ce que font les formateurs (ou linters, ou beautifiers, bref...). Comme ça on peut faire le truc automatiquement sans se prendre la tête.

Et la convention dans tous les formateurs que j'ai testés, c'est plutôt une règle par ligne.
Dans certains guides ou articles de blog, on trouve parfois des gens qui regroupent des familles de règles par ligne (positionnement, police, etc.), mais bon, le mieux c'est de rester sur des conventions simples à se rappeler amha.

Je proposerais bien de passer un coup de formatage sur tous ces fichiers, franchement, ça ferait pas de mal.
PhpStorm fait ça très bien.

+1
Mais alors peut-être après si cette prop abouti à un PR, sinon j'ose pas imaginer la galère pour merger :p

• Ajouté une variante .principal (comme ça on a principal / secondaire)
• Renommé .secondary en .secondaire
• Renommé .block en .bloc
• Réduit le padding (+ remis sur les .link)

Comme ça toutes les nouvelles classes sont en français.
Ah les nouvelles classes, ce ne sont que des propositions. S'il n'y a aucun cas concret d'utilisation possible dans le privé (les groupes de boutons par ex.), ça peut être viré.

Bon j'arrête les captures, à voir sur ?exec=issue_4468

tcharlss 🐽 a écrit :

Et la convention dans tous les formateurs que j'ai testés, c'est plutôt une règle par ligne.

Tututu, de mon côté j'utilise https://github.com/fidian/PrettyCSS/ qui me permet d'utiliser la convention pour laquelle j'ai une préférence avec cette config https://gist.github.com/brunob/d16beef0f181a55e24b5 ; tous ces outils sont configurables à souhait ;)

Non mais cherche pas, tout sur la même ligne c'est IMMONDE et ILLISIBLE (15 règles sur la même ligne, super pour retrouver TELLE règle précise cachée tout à droite en scroll horizontal). Aucun framework ne fait ça pour maintenir le code à plusieurs sur le long terme.

(saurez vous trouver l'auto caricature dans ce message) :p

Non mais cherche pas

T'inquiète, ça fait un moment que je ne cherche pas avec certains interlocuteurs :*

Hello,

Est il possible de prévoir une class pour habiller les liens en boutons.

Quelque suggestions de markup que j'ai l'habitude d'utiliser:

a .bouton ou a .button (apparence d'un bouton de spip couleur neutre gris?)
a .bouton.theme ( couleur du theme claire)
a .bouton.theme.foncee (couleur du theme foncee avec en prime du blanc couleur texte blanc?)

possiblement ajouter une classe hover
a .bouton.theme.hover-foncee ( couleur theme clair avec un effet hover: backgound fonce et texte blanc?)

Merci tcharlss :)

+1 pour un a.bouton (pas .button, en toute logique), avec des déclinaisons BEM si besoin, mais juste un .bouton serait déjà pas mal en standard.

Peut être un .bouton qui serait gris, et .bouton--clair / .bouton--fonce pour reprendre les deux couleurs du privé ?

@jluc : pretty please, c'est possible de renommer ce ticket en quelque chose de plus approprié ? Le sujet a glissé plus précisément sur les boutons et les icônes de la charte du privé. Meurchi.

Ah et dernière question pour les sachant⋅e⋅s : est-ce que quelqu'un⋅e peut m'expliquer vite fait la logique du découpage des squelettes css du privé ?

Je vois qu'il y a un fichier général theme.css.html un peu fourre-tout, et quelques fichiers pour des modules précis : forms.css.html, icons.css.html, etc.
Donc la logique semble être : les trucs qui correspondent à un module précis sont dans un fichier css.html à part, et tout le reste en vrac dans theme.css.html.
Sauf que parfois un module a des règles à la fois dans le fichier général et dans le fichier dédié. Et parfois les mêmes règles. Par exemple pour les formulaires, il y en a un bout dans theme.css.html et aussi dans forms.css.html.
En l'état, quand il y a des modifs à faire c'est le doutage, on les fait où ?

Là comme il s'agit de mutualiser les styles de plusieurs choses, dont les boutons de formulaire, le mieux serait de déplacer tout ce qui concerne les boutons dans un nouveau module boutons.css.html tout simplement, depuis forms.css.html et theme.css.html.
Des objections ?

Je dirais : ya sûrement eu une bonne volonté de rangement, mais comme dans plein d'autres endroits de SPIP, c'est pas carré cohérent, avec encore du bazar pas rangé.

+1 pour déplacer les styles de boutons dans un module dédié (et ranger tous les trucs de forms dans le module de forms, s'il en reste en bazar ailleurs)

Tcharls : c'est un ticket trac, pas git.spip et je ne peux aucunement modifier le titre du ticket ou un quelconque post. "Modifier" permet juste d'ajouter un nouveau post. Désolé. Mais pas de pb of course si qqn qui a des droits veut le faire.

Donc pour les liens boutons, il faudrait soit limiter à la balise <a> → a.bouton { … }, mais c'est un peu sale. Ou alors trouver une autre classe pour le bandeau.

Pourquoi "un peu sale" ? à part a et button, voir input[type=button] je ne vois pas où on pourrait appliquer cette classe.

Mais +1 pour renommer la classe des li de <ul class="rapides_creer"><li class="bouton">, qui n'a pas de logique là, ce serait plus cohérent.

@b_b : Super, merci

@jluc : Ah je pensais qu'on pouvait au moins éditer ses propres tickets sur trac, même sans être admin. Je viens de voir que j'aurais pu le faire moi-même d'ailleurs, mais je me suis encore fait avoir par l'UX : faut d'abord cliquer sur modifier, et ensuite sur la petite icône « changer la description ». Mon cerveau refuse de retenir ce truc.

Alors en fin de compte j'ai fait en sorte de ranger un minimum, mais en essayant de pas toucher à trop de choses non plus :

• Tout ce qui a trait aux boutons est dans un nouveau module boutons.css : les boutons de formulaires, les boutons d'action, et la nouvelle classe lambda .bouton.
• Je n'ai pas touché au bando rapide, donc pour les nouveaux boutons le sélecteur CSS inclus le tag : a.bouton. Je disais que c'est sale parcequ'en dehors des règles de base (reset, typo…), la règle générale c'est d'éviter de cibler un tag en particulier.

En parlant de rangement, le module icons.css contient aussi les onglets (barre + onglets simples). À mon avis le composant .icone.horizontale|verticale ça rentre dans la famille des boutons, donc à déplacer dans le module boutons.css, et le module icons pourrait ensuite être renommé en onglets.css.
Mais bon, j'y touche pas, ça pourra faire l'objet d'un autre ticket spécifiquement pour le découpage et le rangement des modules.

Je vais essayer de boucler ça demain, y a moyen de faire un PR pour tenter de squeezer ça dans l'alpha de la 3.3 amha.
J'y mettrai un description complète de la prop incluant les derniers correctifs.

Je répète, tant que tu y es :

+1 pour renommer la classe des li de <ul class="rapides_creer"><li class="bouton">, qui n'a pas de logique là, ce serait plus cohérent.

Merci en tout cas, super boulot !

Ah si, il restait un point pour lequel je suis pas complètement sûr, c'est les boutons des formulaires.
L'idée étant de cibler tous les boutons qui permettent de soumettre le formulaire.
Pour l'instant, je cible comme ça :

.formulaire_spip input.submit,
.formulaire_spip button {
    …
}

Mais peut-être que cibler tous les tags <button> est trop large ?
J'ai vu aussi une référence à des input.reset dans forms.css, mais je sais pas trop si c'est utilisé ou pas.
Le but étant d'avoir un sélecteur le plus concis possible, parcequ'il est répété moultes fois (aaah, que je regrette sass et ses @extend).
Avis bienvenus.

tcharlss 🐽 a écrit :

• J'ai aussi mis quelques animations au survol des icônes. Bon là j'ai pas encore assez de recul pour voir si c'est pas trop distrayant à l'usage. Mais j'aime bien le petit effet bling.

Tout ça me semble top, les animations sont choupi, mais j'ai un doute, surtout sur le fond danger animé qui fait défiler les hachures qui perturbe pas mal la lecture même si c'est mignon :) Mais, celles sur les add/del/etc ne me semblent pas poser de pb de lisibilité.

PS : merci pour tout le détail, la page de démo et le screencast !

mais j'ai un doute, surtout sur le fond danger animé qui fait défiler les hachures qui perturbe pas mal la lecture même si c'est mignon :)

Oui c'est sans doute la touche de trop, je vais la revert celle-là.

tcharlss 🐽 a écrit :

Pour l*'icone export* est ce que c'est possible de faire un flip horizontal afin de bine voir la diff par rapport à export?

C'est impressionnant !
Mais oui l'import en symétrie sera bien mieux.

Je suis d'accord que les deux se distinguent extrêmement mal, ça va pas. Mais s'il faut en changer je dirais plutôt celle d'import, car la majorité des utilisations c'est dans des sites où on lit de gauche à droite, et pour l'export ça parait plus logique d'avoir "notre site" représenté par le carré à gauche, qui exporte vers l'extérieur vers la droite.

Comme ça ne se voit pas dans les images, j'ai une question : est-ce que ça prend bien en compte pour les simples <input> submit aussi, pas juste <button> ?

Bonjour,

1. Time Memory Function Location
   1 0.0004 430392 {main}( ) ...\index.php:0
   2 0.1314 8997432 exec_admin_plugin_dist( ) ...\index.php:166
   3 0.3552 11321248 inc_commencer_page_dist( ) ...\admin_plugin.php:99
   4 0.3566 11366584 init_entete( ) ...\commencer_page.php:59
   5 0.3597 11445224 init_head( ) ...\commencer_page.php:98
   6 0.3597 11445600 recuperer_fond( ) ...\commencer_page.php:113
   7 0.3673 11547768 evaluer_fond( ) ...\utils.php:3211
   8 0.3673 11547768 inclure_page( ) ...\assembler.php:651
   9 0.3789 11699792 public_produire_page_dist( ) ...\assembler.php:279
   10 0.3789 11699888 public_parametrer_dist( ) ...\assembler.php:315
   11 0.4253 12770192 html_12cef13bf48781313bd9610ff114fef8( ) ...\parametrer.php:128
   12 0.5928 14417704 pipeline( ) ...\html_12cef13bf48781313bd9610ff114fef8.php:28
   13 0.5928 14417784 execute_pipeline_header_prive( ) ...\utils.php:265
   14 0.6592 14733152 minipipe( ) ...\charger_pipelines.php:715
   15 0.6592 14733152 compresseur_header_prive( ) ...\utils.php:199
   16 0.6598 14737384 compacte_head( ) ...\compresseur_pipeline.php:36
   17 0.6609 14802416 compacte_head_files( ) ...\compresseur_fonctions.php:138
   18 0.6652 14869280 concatener_fichiers( ) ...\compresseur.php:206
   19 0.6675 14927472 compresseur_callback_prepare_css( ) ...\compresseur_concatener.php:81

J'ai changé l'icône d'export plutôt que l'autre comme le suggérait RastaPopoulos, ça me semble plus logique.

@RealET : ça persiste après un recalcul ? J'ai une erreur php quand je bascule du master sur cette branche mais c'est normal car elle est en retard de quelques mois sur le master, donc certaines fonctions invoquées dans les fichiers mis en cache manquent. Par contre ton erreur ne semble pas concerner le dépôt spip mais un des plugins dist, donc je vois pas trop pourquoi elle apparaît juste là.

@RastaPopoulos : j'en parle justement plus haut : https://core.spip.net/issues/4468#note-51

Alors, même en vidant entièrement le dossier tmp, j'ai :
Fatal error: Uncaught Error: Call to undefined function ecrire_fichier_calcule_si_modifie() in C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur.php:302 Stack trace: #0 C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur_concatener.php(81): compresseur_callback_prepare_css('prive/themes/sp...') #1 C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur.php(206): concatener_fichiers(Array, 'css', Array) #2 C:\laragon\www\spip33\plugins-dist\compresseur\compresseur_fonctions.php(138): compacte_head_files('\r\n<!DOCTYPE htm...', 'css') #3 C:\laragon\www\spip33\ecrire\public\sandbox.php(180): compacte_head('\r\n<!DOCTYPE htm...') #4 C:\laragon\www\spip33\ecrire\public\composer.php(243): sandbox_filtrer_squelette(Array, '\r\n<!DOCTYPE htm...', Array, Array) #5 C:\laragon\www\spip33\ecrire\public\composer.php(93) : eval()'d code(117): analyse_resultat_skel('html_f4375c6230...', Array, '\r\n<!DOCTYPE htm...', 'prive/login.htm...') #6 C:\laragon\www\spip33\ecrire\public\parametrer.php(128): html_f43 in C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur.php on line 302

Et j'ai réessayé avec un spip nu, sans aucun plugin supplémentaire : pareil

Bravo pour tcharlss et tous ceux qui ont contribués !