Recherche avancée

Sur d’autres sites (12794)

• Evolution #4102 : Ordre des inclures dans cache/charger_plugins_options.php

  28 juin 2018, par placido .

  jluc - a écrit :

  Donc tu proposes que les constantes, avant d’être définies par un define, soient possiblement pré-réservées par les plugins, via le tableau $flux où les éventuelles pré-réservations peuvent être surchargées.

  Oui en gros c’est ça. On obtient une gestion plus souple des contantes. Le pipeline peut servir à trier, ou écraser certaines valeurs, il est (re)calculé lors de la visite de la page admin_plugin&actualise=1 et son résultat est inséré au début du fichier charger_options.php donc avant les éventuels define() livrés par defaut par les plugins. On retrouve bien la logique de surcharge emblématique de SPIP (le plus bas dans la chaîne a possiblement le dernier mot) et la magie continue.

  Mais est-ce que ça couvre tous les cas ? Ou bien est-ce que c’est suffisant ?

  Ma solution a quelques limitations qu’il faut garder à l’esprit en effet.
  Le calcul du pipeline ne se fait pas à chaque hit, et en conséquence, certaines valeurs dont on souhaiterait modifier l’affectation en fonction du contexte de la requête (ex : ip / test_espace_prive, ...) ne seraient alors pas pertinentes. Mais cela reste des cas rares, qui déjà eux-même sortent de la simple déclaration de constante de configuration.

  Ou bien un peu plus simple : sa valeur + un indice de priorité.

  Pour moi, pas besoin de gestion explicite de priorité. Si on veut vraiment forcer une valeur en toutes circonstances, il reste mes_options.php.

• Evolution #4105 : Constante ou config ?

  27 septembre 2018, par RastaPopoulos ♥

  Ça reste bancal dans le sens où si on a opté pour le côté "déploiement", donc avec un choix fait en PHP, alors le formulaire de config est obsolète, et les gens vont le remplir en croyant que ça va faire quelque chose, alors que non.

  Quand au fait même de décider de faire cohabiter les deux (pas forcément constante mais "possibilité de le définir par le code") ce n’est pas tordu, mais bien indispensable si on veut permettre de déployer des choix sans que les admins puissent le changer MAIS que lorsqu’on est pas en mode déploiement, alors là les admins peuvent le changer dans une interface. Ce qui est contre-intuitif, c’est que le form est toujours visible si on a activé un define (ou autre méthode tel le pipeline décrit plus haut).

  La solution proposée au début n’est pas la bonne ok, mais l’objet même du ticket pour moi est toujours valable et parfaitement légitime : permettre avec la même API, de manière cohérente et unifiée, que les configs puissent être modifiables par interface OU déployables prioritairement par du code. Et que cela fonctionne au niveau technique ET soit compréhensible dans l’ergonomie (càd champ grisé ou supprimé quand il y a un déploiement par le code).

• Documentation #4098 : Compléter la documentation de #TRI pour générer un lien de tri avec un sens ...

  28 septembre 2018, par cedric -

  Juste pour être sûr, ce que Jean-Luc précise c’est que tu peux générer deux liens de changement de sens de tri avec la syntaxe suivante :
  

  [(#TRI’>’, #CHEMIN_IMAGEtri-asc-16.png|balise_img<:par_tri_croissant :>)]
  [(#TRI’<’, #CHEMIN_IMAGEtri-desc-16.png|balise_img<:par_tri_decroissant :>)]
  

  
  comme dans https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/albums/branches/v2/prive/objets/liste/albums.html#L47
  Ce sont 2 liens uniques qu’on met en général en début de bare de tri.
  Mais tu peux aussi les générer de manière contextuelle à côte de chaque lien en testant le champ de tri :
  

  [(#TRIid_album, <:medias:par_id :>)]
  [(#TRI|==id_album|oui)
    [(#TRI’>’, #CHEMIN_IMAGEtri-asc-16.png|balise_img<:par_tri_croissant :>)]
    [(#TRI’<’, #CHEMIN_IMAGEtri-desc-16.png|balise_img<:par_tri_decroissant :>)]
  ]
  

  Bon je réponds un petit peu à côté de la question mais quand même donc : on peut générer des liens de sens de tri dynamique, et les mettre en contextuel à côté de chaque lien de tri si c’est ce que tu veux.

  C’est vrai que le même lien qui change le sens du tri "comme dans phpMyAdmin" ce n’est pas prévu, mais a moitié aussi parce que je ne suis pas du tout certain que ce soit une bonne pratique accessibilité/usabilité
  (ie le même lien dont l’action change selon le contexte, ce n’est pas hyper cognitif)

  Donc à voir/discuter sous cet aspect peut-être aussi avant de coder quoi que ce soit de plus