Re: Discussion avant pull request sur autorisation pour accès à <:bouton_cache_desactiver:>

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 !)

--
Cédric
Le 23 janv. 2019 à 20:25 +0100, 6ril <[email protected]>, a écrit :
> Le 23/01/2019 à 12:11, RealET a écrit :
> > 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.
> >
>
> 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 ;-) )
>
> Merci encore.
>
>
>
>
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip