Recherche avancée

Sur d’autres sites (12166)

• Anomalie #3107 (Fermé) : Uniformité dans le squelette-dist dans #TEXTE => texte surlignable

  29 octobre 2014, par cedric -

  http://zone.spip.org/trac/spip-zone/changeset/85719

• Evolution #3886 : Trier les menus du bandeau de l’espace privé dans l’ordre alphabétique

  1er mars 2017

  Oui, si on parles des objets éditoriaux, le Core a proprement parler n’a que Articles, Rubriques et Auteurs.
  Tout le reste, c’est des plugins (dist ou pas).

  Un usage assez fréquent aussi est de mettre pratiquement tous les plugins indispensables au site dans plugins-dist. Faire un distingo « plugins / plugins-dist » n’a pas de sens non plus à mon avis.
  Enfin une problématique est que bien que mettre en avant Auteurs et Articles par exemple dans le menu en supposant qu’ils sont le plus utilisés n’est pas forcément le cas pour tous les sites ; loin de là.

  L’avantage de l’ordre alphabétique est qu’au moins on retrouve assez facilement ce qu’on cherche dans la liste (il y a une certaine logique). Avant c’était un peu au petit bonheur la chance, et lorsque beaucoup d’objets éditoriaux étaient présents sur le site, c’était pas du tout évident. Ce qui me gênait pour ma part, c’est que pour certains sites ou certains rédacteurs, ils n’ont pas besoin d’aller fréquemment aux mêmes éléments du site. C’est pour cela que j’ai ajouté cette option de favoris. Je trouve cela pas trop mal à l’usage d’ailleurs (et je ne suis pas le seul).

  Certes c’est perfectible aussi, mais c’est une réponse relativement correcte au fait qu’on ne sache pas
  1) ce qu’il y a dans les menus
  2) la fréquence d’utilisation de ces menus par l’utilisateur

• Evolution #4036 (Nouveau) : [Compresseur] Rechercher la présence événtuelle de .min.(js|css) dans ...

  31 octobre 2017, par placido .

  Je propose un amélioration de la fonction minifier, lorqu’elle est appliquée à un fichier.

  La plupart des plugins qui embarquent des bibliothèques tierces fournissent leur sources en format avec commentaires (plugin.js) et minifié (plugin.min.js).
  On peut parler de convention tacite concernant l’extension ".min.js"

  Le traitement dérogatoire serait le suivant :

  A : La source a-t-elle une extension min.(css|js) ?

  Oui : on renvoie tel quel
  Non : ->B

  B : Existe-t-il un fichier nommé source.min.(css|js) dans le même répertoire que la source ?

  Oui : on renvoit le fichier trouvé
  Non : Alors on lance le compresseur sur la source et on renvoie

  Je vois 2 avantages à cette évolution :
  - Un léger gain de performance : on économise un processus de compression superflu en échange d’une recherche de fichier dans un dossier unique (même pas besoin de find_in_path)
  - On se fie sur la version minifiée livrée par le tiers (supposée fiable), et ainsi on évite d’éventuels problèmes qui peuvent surgir lorsque qu’on applique le compresseur sur un fichier déjà minifié.

  Vos avis ?