Recherche avancée

Sur d’autres sites (7271)

• Anomalie #4506 : Supprimer les CSS inline des modèles de documents

  12 février 2021, par cedric -

  Le problème c’est pas de pouvoir ou non le gérer en css : on peut tout faire en css.

  Le problème c’est de garantir un comportement acceptable sur les sites qui font une mise à jour, qui ont un squelette qui marchait dans la version antérieure et qui doit continuer à marcher à peu près.
  Si tout le monde est obligé de reprendre ses css partout à cause des modèles de document, ça va être l’enfer (sans compter tous les utilisateurs qui ne savent pas faire)
  Ça a toujours été la raison de ces styles en dur.

  Là j’ai passé du temps à trouver un compromis en refondant les modèles. Il est peut-être possible de faire mieux, mais il faut se refader les tests.
  Tu prends un squelette 3.2 qui marche, tu passes aux nouveaux modèles et tu te débrouille pour que ça marche encore sans toucher aux css du site.

  Mais bon : SI on a un plugin "modèles documents historiques" qui reprend les modèles exacts de SPIP 3.2 et que tout fonctionne à l’identique avec ce plugin, ça peut être la solution de dire
  - Si vous mettes à jour votre site, ajoutez le plugin "modèles documents historiques" pour que tout continue à fonctionner comme avant
  sachant que petit à petit tout se cassera la figure quand même parce que les nouveaux plugins, ou les mises à jour de plugin vont se baser sur les nouveaux modèles et que le fonctionnement avec les anciens modèles sera de plus en plus cassé...

  J’ai pas de solution idéale.
  Le principal problème de ce width en dur qui me chagrine aussi, c’est que si on passe un image_reduire sur le texte de l’article qui contenait des grandes images, les images sont réduites mais ce width ne bouge pas et c’est le drame...

• Anomalie #4688 (Fermé) : recherche et warning preg incorrecte

  7 mars 2021, par jluc -

  inc_recherche_to_array_dist appelle expression_recherche pour déterminer la méthode à employer : REGEXP ou LIKE. En particulier, c’est LIKE lorsque preg_match provoque une erreur. La méthode choisie est bien utilisée pour le sql_select principal https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/recherche_to_array.php#L92 mais elle n’est pas testée par la suite, pour le calcul du score notamment où un preg_match ou preg_match_all sont systématiquement faits : https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/recherche_to_array.php#L119

  De ce fait, le preg_match_all rencontre parfois une erreur de regexp mal formée, renvoie false et génère un warning :
  

  PHP Warning :  preg_match_all() : Compilation failed : nothing to repeat at offset 0 in /srv/data/web/vhosts/www.ndd.ext/htdocs/ecrire/inc/recherche_to_array.php on line 120
  

  Il serait possible
  - d’ajouter @ avant preg_match et preg_match_all
  - peut être de conditionner le passage par ce code au fait que la méthode soit REGEXP : ajouter un " and ($methode "REGEXP’) " dans le test avant mais alors faudrait il compléter ce code par une version pour les cas $methodeLIKE ?

  Dans mon cas ça se passe lorsqu’il y a un caractère accentué en 1er caractère, car à cette étape il a été remplacé par un ’ ?’
  C’est une boucle

  3recherche>

  
  et la pile montre que ça a appelé inc_prepare_recherche_dist(éolien...) puis recherche_en_base(éolien...) puis inc_recherche_to_array_dist(éolien...)
  et ça échoue dans le preg_match_all avec recherche=’éolien’ methode=’LIKE’, q=’’%%’’, preg=’/ ?olien/UimsSu’

• Anomalie #4623 : Styles des fieldset dans l’espace privé

  18 avril 2021

  Bon stop (ou pas) !

  Il semble que les blocs fieldset ne peuvent pas parfaitement se styler seuls. Manifestement c’est assez récent que les navigateurs acceptent un display:flex; dessus par exemple.

  J’ai fait quelques tests en partant du formulaire de préférences des menus (tiens d’ailleurs ce formulaire a des div.editer sans div.editer-groupe parent (à corriger !)
  Il contient un fieldset + .editer-groupe.deux_colonnes (columns : 2)

  Ce que j’ai testé (sous macOS avec FF, Safari, Chrome & Opéra) : la formule suivante (enlever le .editer-groupe interne et le monter sur le fieldset)
  

  <span class="CodeRay"><span class="tag">fieldset</span><span class="class">.editer-groupe</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer</span>
      <span class="tag">div</span><span class="class">.editer</span>
      ...
  </span>
  Télécharger

  1) Si on applique un columns: 2 sur ce fieldset,
  - Firefox & Safari : conservent le legend, passent le reste en 2 colonnes
  - Chrome & Opéra : ignorent et conservent donc un affichage 1 colonne.

  2) Si on applique un display: flex; flex-wrap: wrap sur ce fieldset
  - Tous : le legend est conservé comme tel
  - le reste passe effectivement en flex (permettant donc de mettre plusieurs .editer sur la même ligne)

  Déjà je suis étonné que Flex semble fonctionner, contrairement à ce que dit https://caniuse.com/mdn-html_elements_fieldset pour tous les Gecko. Et Edge aussi est indiqué en non fonctionnel.

  Donc du coup… je me dis que le .editer-groupe dans le fieldset à encore du sens stylistique.
  Ce qui pour le coup ne nous arrange pas forcément, mais ça évite aussi de casser un truc de plus dans cette structure html en le laissant.

  Donc du coup, on en reviendrait peut être à "fieldset.editer-section" ou "fieldset.editer-fieldset" ou "fieldset.fieldset" ou "fieldset" (sans rien)…
  J’utilise .editer-section ensuite (mais peut importe)

  A) fieldset.editer-section > div.editer-groupe¶

  (le plus proche de l’actuel je pense)

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-section</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-groupe</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  B) fieldset.editer-groupe > div.editer-section¶

  L’autre possibilité si ça facilite vraiment le css, c’est d’inverser les classes (avec l’ennui principal de du coup devoir reprendre l’existant)

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-groupe</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-fieldset</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  B) fieldset.editer-groupe.editer-section > div.editer-groupe¶

  Ou du doubler d’une autre classe

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-groupe</span><span class="class">.editer-section</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-groupe</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  Mais dans ce cas là je trouve cela redondant (fieldset.editer-section me parait suffisant, si on doit effectivement mettre un classe css dessus)
  Le plus ennuyant est peut être de devoir annuler des styles CSS du .editer-groupe dans .editer-section > .editer-groupe ;