Les différences visuelles sont mineures, il s'agit juste de caler un peu les éléments, les gouttières, etc.
Par contre en arrière-plan on fait un gros ménage pour préparer et simplifier les évolutions futures.

* Rangement et reformatage complet de la CSS : mutualiser les règles, supprimer celles en double ou en triple, ajout de commentaires, etc.
* Markup : Ajout de classes utiles là où il n'y en avait pas, et notamment d'attributs data pour cibler plus facilement les éléments du menu selon la profondeur, pour faire par exemple .item[data-profondeur="2"] au lieu de ul>li>ul>li
* Menu identité : espacer les liens, textes plus foncés, traits de séparations inutiles, et icône de langue alternative.
* Menu rubriques : rétablit les carets pour les entrées depliables. Les sous-menu en colonnes sont fait avec column-count : cela permet de gagner de la place par rapport à display flex, grid ou autre, et cela simplifie les règles.
* Bien indiquer les prises de focus de tous les liens.
* Menus déroulants : refaire fonctionner la navigation au clavier qui était hs, purement en CSS pour l'instant. À voir s'il ne faut garder qu'une des 2 solutions, ou les 2 en compléments (le JS ajoutait un petit délai en plus, non reproductible en CSS).
* Ajout d'un peu de responsive

Ricardo Porto a rédigé 3 years ago et salvatore a validé 3 years ago

[Salvatore] [source:ecrire/lang/ ecrire] Mise a jour du bilan depuis https://trad.spip.net

Ricardo Porto a rédigé 3 years ago et salvatore a validé 3 years ago

[Salvatore] [source:ecrire/lang/ spip] Mise a jour du bilan depuis https://trad.spip.net

George Kandalaft a rédigé 3 years ago et salvatore a validé 3 years ago

[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue en
[Salvatore] [source:ecrire/lang/ ecrire] Mise a jour du bilan depuis https://trad.spip.net

George Kandalaft a rédigé 3 years ago et salvatore a validé 3 years ago

[Salvatore] [source:ecrire/lang/ spip] Export depuis https://trad.spip.net de la langue en
[Salvatore] [source:ecrire/lang/ spip] Mise a jour du bilan depuis https://trad.spip.net

(sinon bug dans les onglets de ?exec=articles

et réglages flexbox

image_recadre si gd2 et plugin filtres activé, sinon image_passe_partout usuel

Ce patch corrige une régression introduite par le commit c4f810b5.

Lorsqu'un alias de boucle existe, certains traitements sont définis
par rapport à cet alias plutôt que par rapport au nom canonique de la
boucle.

C'est par exemple le cas dans la version spip/3.2.11 du plugin Forum.
Ce plugin définit un alias `forums` correspondant au nom canonique
`forum` (voir ligne 32 de `base/forum.php`), puis définit plusieurs
traitements associés à `forums` (l'alias) et non à `forum` (le nom
canonique), comme par exemple ligne 57 du même fichier :
```
    $interfaces['table_des_traitements']['TEXTE']['forums'] = "[…]";
```

Le commit c4f810b5 force l'utilisation du nom canonique pour retrouver
les traitements à appliquer à un champ, ce qui fait que les traitements
définis avec l'alias ne sont plus appliqués.

Cela peut être problématique, car l'utilisation de l'alias est parfois
plus fréquente que celle du nom canonique. Ainsi, l'alias `forums` est
plus utilisé que le nom canonique `forum` : même la documentation de SPIP
parle de la `BOUCLE_xxx(FORUMS)` (https://www.spip.net/fr_article908.html).
Dans ce cas, il est donc plus intuitif de définir les traitements à
effectuer par rapport à l'alias que par rapport au nom canonique.

Ce patch tente donc de concilier les deux approches, en cherchant tout
d'abord à appliquer les traitements associés au nom canonique, puis,
s'il n'y en a pas, en appliquant les éventuels traitements associés à
l'alias. Cela permet de donner la priorité au nom canonique (ce qui
était le sens de c4f810b5, je suppose), sans non plus complètement
ignorer les alias (ce qui permet de maintenir une rétrocompatibilité
avec l'existant, y compris avec les plugins officiels de SPIP).

tcharlss a rédigé 3 years ago et marcimat a validé 3 years ago

* On laisse le style de la boîte simple par défaut, sur fond blanc. Le fond coloré posait certains problèmes de contrastes (marcimat).
* Remplacement du picto pour indiquer le dépliement : on ne fait que 2 états haut/bas, c'est un pattern qu'on retrouve souvent et compréhensible. Plus besoin de la variante gauche/droite selon le ltr.
* Plus important, on souligne visuellement qu'il y a 2 éléments cliquables distincts : le picto et le titre. Légère bordure de séparation, et au survol les 2 sont séparés.
* On maximise la zone cliquable.
* Limiter la hauteur du logo à l'équivalent d'un titre sur une ligne, sinon ça décale tout pour pas grand chose.

Idéalement le picto de dépliement devrait être de l'autre côté, mais avec le logo, pas possible.
Entre ce picto, l'icône du cadre, le logo et le titre, la marge de manoeuvre est très serrée.

tcharlss a rédigé 3 years ago et marcimat a validé 3 years ago

* On passe les classes en BEM, cela évite les collisions qu'on peut avoir avec des noms de classes génériques tels que `.inner`, et cela simplifie les CSS. On bascule sur `.box__header`, `.box__body` et `.box__footer`.
* On simplifie le markup : plus besoin du div.inner ni des b.top, b.tl et cie. Tous ces éléments ne servaient très probablement qu'à faire des bords arrondis à l'ancienne, à base d'images. C'est donc maintenant complètement inutile.
* Enfin, la mini lib box.css est devenue inutile, l'intégralité des règles utilisées étaient surchargées dans box_skins.css.html. On la supprime donc.
* Conséquence : les quelques plugins qui surchargeaient les styles des boîtes devront les adapter. Dans la dist cela ne concerne que SVP et Compagnons, et 2 sur la zone.

tcharlss a rédigé 3 years ago et marcimat a validé 3 years ago

En remplacement des `<div class="notice">` et cie, ainsi que des `#BOITE_OUVRIR{'', notice}` et cie quand elles sont utilisées à mauvais escient, on ajoute une balise `#ALERTE` dédiée aux messages d’alertes.
Ces messages ont l’attribut `role="alert"` ou `status` selon l'importance du message.
Il y a toujours 4 types d’alertes possibles : `notice`, `error`, `success` et `info`.

On peut les utiliser de 2 façons :

* Pour les cas simples, quand il n'y a qu'une phrase et éventuellement un titre : `#ALERTE{message[,titre][,classes][,role][,id]}`
* Quand le texte est plus long, ça ne passe pas toujours au compilo : on peut alors utiliser des `#ALERTE_OUVRIR` et `#ALERTE_FERMER` sur le même principe que `#BOITE_OUVRIR` et `#BOITE_FERMER`, les 1ers paramètres étant identiques, la transition est facile.

Revert "Présentation des sous-rubriques (vignettes + grosses)"
This reverts commit 1847b1dc

Revert "Titres des boîtes et formulaires un peu plus grands et plus épais pour mieux distinguer du contenu (nicod_)"
This reverts commit 96fe7ab9.

Revert "Dans la page maintenance, utiliser une alerte plutôt qu'une boîte pour le message relatif au htaccess (#4727)."
This reverts commit 81ead9eb.

Revert "Introduction d'une balise `#ALERTE` dédiée aux messages d'alerte de l’espace privé (#4727)."
This reverts commit 986fc9db.

Revert "Refacto des styles des messages d'alerte de l’espace privé (#4727)."
This reverts commit e078f2d7.

Revert "Ajustements des styles des formulaires pour suivre la refonte des boîtes + quelques détails (#4727)"
This reverts commit b5068f84.

Revert "Refacto des styles des boîtes de l'espace privé (#4727)."
This reverts commit 18df0352.

En remplacement des `<div class="notice">` et cie, ainsi que des `#BOITE_OUVRIR{'', notice}` et cie quand elles sont utilisées à mauvais escient, on ajoute une balise `#ALERTE` dédiée aux messages d’alertes.
Ces messages ont l’attribut `role="alert"` ou `status` selon l'importance du message.
Il y a toujours 4 types d’alertes possibles : `notice`, `error`, `success` et `info`.

On peut les utiliser de 2 façons :

* Pour les cas simples, quand il n'y a qu'une phrase et éventuellement un titre : `#ALERTE{message[,titre][,classes][,role][,id]}`
* Quand le texte est plus long, ça ne passe pas toujours au compilo : on peut alors utiliser des `#ALERTE_OUVRIR` et `#ALERTE_FERMER` sur le même principe que `#BOITE_OUVRIR` et `#BOITE_FERMER`, les 1ers paramètres étant identiques, la transition est facile.

Remise en forme de la configuration du reducteur et utilisons une image svg d'erreur au lieu du vieux gif anime quand une methode ne marche pas

* Le picto svg est embed afin de pouvoir le styler plus facilement, on incite à cliquer dessus en le rendant un peu plus visible, comme une sorte de bouton.
* L'input qui montre la rubrique choisie est affiché comme un texte normal (uniquement s'il est en disabled, sinon ça reste affiché comme un input normal). On montre qu'une partie du texte est cachée avec un masque en dégradé.
* Ajout d'un placeholder à l'input de recherche pour comprendre sa fonction.
* Ajout de quelques classes en plus afin de styler plus facilement.
* Calages visuels, ajustement des couleurs, etc.

Donc le test sur le type chaine provoque une erreur et ne permet pas d'assurer la compatibilité avec l'ancienne version.
On utilise donc un test sur le type array qui est plus sur.

[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue br
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue ca
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue de
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue en
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue eo
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue es
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue fr_fem
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue fr_tu
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue it
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue ja
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue nl
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue oc_ni_mis
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue pl
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue pt_br
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue ru
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue sk
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue tr
[Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue uk
[Salvatore] [source:ecrire/lang/ ecrire] Mise a jour du bilan depuis https://trad.spip.net

Pour les utilise, ne renvoyer des erreurs que sur les plugins actifs, pas sur les plugins non activés

  - nécessite une dépendance Y (on a absolument besoin)
  - utilise une dépendance Y (si on a, tire profit)

Mais dans le cadre d'utilise une dépendance, on vérifie quand même que
cette dépendance respecte certaines condition de version.

Sauf que le message d'erreur, en employant "utilise" laisse croire que
le plugin X a besoin de la dépendance Y, alors qu'en réalité, on
souhaite juste indiquer que la dépendance Y n'a pas la bonne version.

Ex de mécompréhension :
https://www.mail-archive.com/spip@rezo.net/msg81070.html

Proposition de reformulation pour éviter cela.

Renommer toutes les fonctions parents/enfants pour eviter tout risque de collision avec le plugin historique declarer_parent qui pourra donc coexister et assurer une transition douce du code. Les pipelines sont aussi renommes

La fonction objet_trouver_enfants() retourne un tableau dans le même format que la fonction objet_trouver_parents(), a savoir une liste d'enfants de la forme
```
['objet' => '...', 'id_objet' => X, 'table' => '...', 'champ' => '...']
```
Si la relation a été trouvée par une table de liens (table finissant par '_liens'), une entrée 'lien' supplémentaire reprend la description complète du lien, ce qui inclue les éventuels champs rang, role...

On a ainsi une parfaite symétrie entre les 2 fonctions objet_trouver_enfants() et objet_trouver_parents().

On ajoute une fonction helper objet_trouver_enfants_par_type() qui retourne une liste réduite et simplifiée de la forme
```
[ 'objet1' => [ids...], 'objet2' => [ids...] ]
```

Par symetrie on propose aussi une fonction objet_trouver_parents_par_type()

Le retour de la fonction objet_trouver_parents() inclue la description complète du lien quand le parent est trouvé via une table de xxxx_liens

objet_trouver_parents() passe au pluriel et est agnostique : puisqu'on a potentiellement plusieurs liens de parentés (car plusieurs méthodes de parentés et certaines méthodes pouvant remonter plusieurs liens), la fonction ne choisit pas et retourne l'ensemble des parents symétriquement aux enfants.
Une option de la fonction permet de se limiter aux parentées directes, ce qui ne veut pas dire pour autant qu'on a qu'un seul parent car on peut avoir sur une table un id_parent1 et id_parent2 qui pointent vers 2 parents.

(C'est juste une feature de confort, car de toute façon le retour de la fonction objet_trouver_parents() permet de filtrer les parents directs et les parents trouvés par une table de lien)
Le pipeline est renommé en conséquence.

(La compatibilité fonctionnelle avec l'API au singulier du plugin https://git.spip.net/spip-contrib-extensions/declarerparent pourra être assurée par ce dernier qui aura juste à retenir le premier parent de la liste retourné par la fonction du core pour produire le même résultat qu'auparavant et eviter de casser les consommateurs qui ne supportent pas de multiples parents)

Un filtre |objet_trouver_enfants en plus et permettre d'appeler les filtre |objet_trouver_enfants et |objet_trouver_parent en syntaxe
```[(#ID_OBJET|objet_trouver_enfants{#OBJET})]``` (avec l'id en premier donc)

RastaPopoulos a rédigé 4 years ago et cerdic a validé 3 years ago

Cette API a été développée et testée en amont dans le plugin Déclarer parent, puis utilisée dans plusieurs plugins.
Elle comporte 4 fonctions :

- 2 pour connaitre les types parent et enfants d'un type donné (que objet),
- 2 pour connaitre les contenus parent et enfants d'un contenu donné (objet + id_objet).

Un filtre est ajouté pour connaitre le parent d'un contenu facilement (cas le plus courant).

On déclare le parent pour les articles et les rubriques.
Une fois intégré, il faudra ajouter les autres déclarations qui étaient fournies par le plugin pour les plugins-dist : syndic, mots, et forums.

Le filtre enlève notamment les ":" et espaces à la fin d'une chaine de caractères.