[spip-dev] Discussion avant pull request sur autorisation pour accès à <:bouton_cache_desactiver:>

Dev
1

Bonsoir,
Je souhaiterai formuler le vœu de pouvoir si on le souhaite distinguer l'accès à cette fonctionnalité (le bouton "désactiver temporairement le cache" du formulaire admin_vider_cache) de l'accès à la page intégrale de vidage de cache, ceci grâce à une autorisation explicite, dérogeant au principe actuel que la désactivation soit utilisable par qui accède au formulaire général du cache.

Ceci pour différencier les droits d'un admin restreint de ceux d'un webmestre, cette fonctionnalité semblant d'avantage vouée au dev qu'à une administration restreinte du site.

Peut-être ce sujet a-t'il déjà été débattu, ce que j'ignore, et c'est la raison pour laquelle, avant de poster un request d'amélioration sur https://core.spip.net/projects/spip/issues, il m'a semblé plus opportun de demander avant ici si l'idée paraissait la peine d'y être posée ?

Perso, actuellement, n’ayant trouvé d'autres palliatifs subvenant à mes besoins, je pose un [(#AUTORISER{webmestre}|oui)] en surcharge dans un squelette perso squelettes/prive/squelettes/inclure/admin_vider_cache.html, mais ça me pose le problème de devoir regarder à chaque release de Spip si une modif a été faite sur le squelette de la distrib pour refaire le mien.

Bref, s'il y avait en natif un (#AUTORISER{bouton_cache_desactiver}|oui)] pour ce bouton, ou un autre procédé du genre permettant de l'occulter si besoin, je mettrai une fois pour toutes dans mes_options une surchage de cette autorisation pour la limiter aux seuls webmestres.

Merci si vous pouviez m'indiquer si je peux lancer une request dans ce sens ou directe abandonner l'idée et continuer de bidouiller dans mon coin.

2

J'oubliais, indispensable pour une meilleur compréhension, j'ai absolument besoin de donner aux admins restreints le droit sur le vidage de cache et j'ai donc surchargé ainsi dans mes_options:
function autoriser_configurer($faire, $type, $id, $qui, $opt)
{
     //echo 'faire: ' .$faire . ' - type: ' .$type;
     //return false;
     if (isset($type)) {
         if ($type == 'adminvider') {
             return $qui['statut'] == '0minirezo';
         }
     }
     return $qui['webmestre'] == 'oui';
}

En effet, un admin restreint doit pouvoir, sur mon projet, et d'après mon expérience de pas mal d'année à présent, avoir la main sur ses publications. Cet aspect peut faire partie de la discussion, bien entendu. Ceci dit, après moults recherches j'ai trouvé cette capacité de pouvoir le faire (fonction autoriser_configurer), alors je me demandais si on ne pouvait pas affiner jusqu'à lui restreindre l'autorisation sur la seule désactivation temporaire du cache, ce qui de mon point de vue est un privilège bien plus élevé que le reste du formulaire, à réserver au dev.

3

Hello,

ça ne me parait pas scandaleux de mettre une autorisation spécifique sur le bouton « désactiver temporairement le cache » même si par défaut elle restera identique, je t’invite donc à proposer une PR en effet.

Mais sur le fond, ça me parait par contre bizarre que des admins restreint aient besoin d’accéder au bouton « vider le cache ».
Pour tout dire ce bouton ne devrait jamais servir dans la vie courante du site, c’est vraiment en processus de développement qu’il peut être utile, si on modifie les squelettes par exemple.

Aujourd’hui la simple publication d’un article ou tout autre action éditoriale implique une invalidation de tout le cache, une action de vidage ne devrait donc avoir aucun effet supplémentaire (si ce n’est psychologique pour se rassurer, ou par habitude acquise sur les anciennes versions de SPIP).
Sans remettre en cause ta proposition initiale je ne pourrai que t’inviter à creuser un peu ce problème et éventuellement à nous remonter des scénario précis qui justifieraient vraiment ce vidage de cache qu’on pourrait améliorer.

Bonne journée à toi,

4

Cerdic a écrit le 23/01/2019 à 10:48 :

Hello,

Hello,

Aujourd’hui la simple publication d’un article ou tout autre action éditoriale implique une invalidation de tout le cache, une action de vidage ne devrait donc avoir aucun effet supplémentaire (si ce n’est psychologique pour se rassurer, ou par habitude acquise sur les anciennes versions de SPIP).

Sauf pour l'ajout d'un mot clef à un article/rubrique...
Qui ne provoque pas d'invalidation de cache.
(ni la modification d'un mot clef d'ailleurs).

Il y a aussi le plugin Dictionnaire qui nécessite de vider le cache après avoir rajouté/modifié une entrée.

5

Hello,
Merci pour vos réponses Cerdic et RealET. Je me rends compte que j'ai honteusement zappé des années de dev sur le fonctionnement du cache, car en effet, j'ignorais ces invalidations automatique de cache sur publications/éditions d'objet (!).

Ceci dit, j'ai des objets éditoriaux particuliers (personnes avec propriété, photos, et quelques autres particuliers aussi) qui sont gérées en privé par les admins restreints, par formulaires privés dédiés CVT, et affichés classiquement en public par boucles et balises en squelettes. Les saisie/modifs sur ces objets n'invalident pas le cache.

Pour ces dernier je pourrais finir les traitements de saisie/modif avec une invalidation forcée du cache, et dans ce cas là je n'aurai plus besoin de donner accès au formulaire du cache aux admins restreints. A ce propos, je n'ai que dans ma besace qu'un:
$purger = charger_fonction('purger', 'action');
$purger('cache');
Je ne sais pas s'il y a mieux ou plus approprié ? Je suis très preneur de recommandations, propositions.

Ceci étant dit, je vous remercie encore pour vos réponses, et m'avoir appris quelque chose que j'avais complètement zappé, et qui existe pourtant depuis longtemps déjà, si j'en crois cet article https://programmer.spip.net/Actualisation-du-cache (merci Matthieu, désolé, page trouvée uniquement ce jour après recherche suite à la réponse de Cerdic).

Je crois que je ferai une PR tout de même pour une autorisation explicite au moins sur ce bouton particulier de « désactiver temporairement le cache ». En effet il y a 2 statuts qui accèdent à cette page, les admins (complets) et les webmestre. Et j'ai du mal à comprendre en quoi un admin pourrait bien se distinguer d'un webmestre s'il a accès nativement à cette fonctionnalité, dont la principale caractéristique consisterait, outre les nuances apportées par RealET comme les modifs/ajout mots clés, à vérifier ses modifs sur les squelettes, que seul le webmestre édite.
Je crois même qu'il serait pas mal de faire une autorisation sur la page elle-même, pour les besoins particuliers, ça ne mangerait pas de pain du point de vue du codage. Parfaitement d'accord avec les valeurs par défaut identiques à l'existant, Cerdic, juste apporter de la souplesse (de l'agilité comme diraient certains :wink: )

Merci encore.

6

Je tombe sur ce ticket quia été clôturé:
https://core.spip.net/issues/3553
qui dit:

Lorsqu'on est connecté en tant qu'administrateur non webmestre, nous avons accès à des sous-éléments des différents menus du BO. Lorsqu'on clique sur ces items, on obtient un "accès interdit". De ce fait, il n'est pas pertinent d'avoir ces items dans le menu si les administrateurs n'y ont pas accès
Il faudrait créer l'autorisation sur les menus en reprenant l'autorisation présente sur la page prive/squelettes/contenu/page_desiree.html

Exemple : ecrire/?exec=admin_vider

Ce ticket a été fermé, mais l'accès direct a ecrire/?exec=admin_vider est toujours accessible aux admins non webmestre. C'est normal ?

7

Sur 3.2.3, ai-je oublier de préciser.

8

Hello,

La bonne pratique pour invalider le cache après modification éditoriale c’est ça

https://git.spip.net/SPIP/spip/src/branch/master/ecrire/action/editer_objet.php#L409

(surtout pas purger le cache !)

9

Merci pour ta réponse, je vais me plonger dans tout ça.

10

Bonsoir Cédric,
Je ne veux pas être lourd, dans ce cas ne pas hésiter à le dire, je comprendrai, mais je me lance, après tout ce temps passé à devoir y renoncer, de comprendre un peu la boite noire épouvantail (pour moi, bien sûr) du cache Spip.
De ce que je lis du code actuel https://git.spip.net/SPIP/spip/src/branch/master/ecrire/inc/invalideur.php#L131, un simple
ecrire_meta('derniere_modif', time())
à la suite d'une modif en bd, suffirait pour actualiser une page (pas le squelette, juste les données) ?
j'ai testé sur une modif en bdd, et ça a l'air d'être le cas.
Je suis très intéressé par quelques réponses de qui que soit d'avisé sur le sujet (sachant que je manipule depuis longtemps des "objets" éditoriaux non déclarés dans le système (pour l'instant, faute de mieux, je fais comme je peux) gérés cependant par cvt en privé et affichés en public par boucles et balises.

11

Hello,

Il y a deux questions dans ta question en fait :slight_smile:

Ton besoin de départ est d’invalider le cache après une modif éditoriale, et c’est donc ma réponse initiale : il faut utiliser la fonction suivre_invalideur() à laquelle on passe un identifiant d’objet

Comment ça marche en dessous, ça dépend, ça a évolué au gré des versions de SPIP… :slight_smile:

Il y a eu autre fois une table de gestion des caches, et l’invalidation d’un identifiant cherchait tous les caches concernés et les effaçait.
Mais la mise à jour de cette table des caches coutait beaucoup d’énergie et de performance.

Actuellement on est arrivé au point ou il est apparu que le compromis qui marche le mieux le plus souvent c’est de ne pas chercher à faire dans la finesse. Quand un objet éditorial est publié et que suivre_invalideur() est appelé il met juste à jour un flag dernière_modif dans les metas, et ensuite la gestion de cache considère que tous les caches plus anciens sont invalides, ce qui implique leur mise à jour au prochain affichage.

Donc oui *actuellement* ecrire_meta('derniere_modif', time()) suffit à actualiser tout le cache
*MAIS* tu ne dois surtout pas faire ça dans tes modifs éditoriales, car demain ça pourait marcher autrement et ton code n’invaliderait plus rien.
Par contre, en appelant la fonction suivre_invalideur() tu t’assures que ça marchera toujours, avec le cache tel qu’il est géré maintenant ou plus tard, ou avec un plugin qui modifie le comportement du cache etc.

12

Hello,
Merci de nouveau pour cette réponse instructive. Cela confirme ce que j'imaginais, suivre_invalideur(obj/id_obj) relève de la bonne pratique qui garantie la pérennité du code dans l'évolution du core.

Me reste à normaliser mes objets pour pouvoir profiter pleinement de l'invalidation, même si suivre_invalideur("n_importe_quel_param_autre_qu_objet") semblerait suffir aujourd’hui en l'état actuel du code, si je ne me trompe pas.
J'arrête le hs pour ne plus polluer ici et reviendrait certainement sur le groupe user pour ce qui est de la déclaration de mes objets.
Merci de nouveau pour le temps et la peine passés pour me répondre et bonne journée.

13

Note qu'il y a aussi la liste zpip-zone pour tout ce qui relève des plugins
et non de l'utilisation de SPIP-dist
JL

14

Pris bonne note, merci. En tout cas, j'ai beaucoup avancé grâce à ces échanges, j'ai adapté ma dizaine de formulaire, tests ok, et j'abandonne alors l'idée d'une pull request. Merci de nouveau pour votre support.

15

Hop,

16

Oui, c'est vrai, c'est autoriser configurer qui régit les droits avec [(#AUTORISER{configurer,_admin_vider}|sinon_interdire_acces)] dans le squelette, ce qui n'exclut que les admins restreints, pas les admins:
https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/autoriser.php#L845
J'avais surchargé https://contrib.spip.net/Le-plugin-Autorite#comment486349-485824 , avant cette discussion, pour autoriser les admins restreints, mais depuis j'ai remis les droits de la dist et j'utilise suivre_invalideur quand de besoin sur leurs actions éditoriales, comme conseillé ici.