[Spip] bouton "recalculer"

Dev
1

Salut à tous,

quelqu'un verrait-il un inconvénient à ce que l'on change l'interface de
recalcul de la page de la manière suivante :

actuellement :
    - si cookie admin -> affiche bouton de recalcul
    - appuie bouton -> l'URL contien recalcul=oui
    - si $recalcul=="oui" on recalcule

je propose :
    - si cookie admin -> on recalcule sans se poser plus de questions

avantages = ça simplifie l'interface ; ça évite les questions du genre "j'ai
    modifié mais ça n'a rien donné..." ; ça facilite l'utilisation d'URLs
    modifiées (pas de paramètre ?recalcul=oui à passer) ; ça permet
    d'administrer plus vite

inconvénient = le site est un chouia plus lent pour l'admin que pour le
    visiteur (mais l'admin qui aime surfer peut supprimer le cookie...)

-- Fil

2

@ Fil (fil@rezo.net) :

quelqu'un verrait-il un inconvénient à ce que l'on change l'interface de
recalcul de la page de la manière suivante

Ci-dessous le patch du fichier inc-public.php3 (il faut aussi, mais ce n'est
pas une obligation, patcher 'ecrire/articles.php3' au niveau du "Lien 'voir
en ligne'" (ligne 182 dans ma version.)

--- inc-public.php3-ori Mon Apr 16 01:44:00 2001
+++ inc-public.php3 Tue Apr 17 15:28:44 2001
@@ -2,6 +2,12 @@

include ("ecrire/inc_connect.php3");

+// sommes-nous admin ?
+$cookie_admin = $HTTP_COOKIE_VARS['spip_admin'];
+$admin_ok = ($cookie_admin == 'admin');

3

Mouais, heu, bof....
Je préfèrerais que la fonctionnalité reste explicite.
Sinon les gens ne vont jamais se souvenir si le cookie
est mis ou pas, si ça recalcule ou pas.... Et puis
c'est intéressant de pouvoir tester le fonctionnement
du cache, aussi.

Pour le répertoire CACHE : à ce moment-là, autant
mettre un "deny from all", c'est plus simple que
de recopier l'autre .htaccess (surtout qu'il n'existe
pas toujours !).

a+

4

@ Antoine Pitrou (pitrou@free.fr) :

Mouais, heu, bof....

ça marche chez moi, et j'en suis très content ! :wink:

Je préfèrerais que la fonctionnalité reste explicite.
Sinon les gens ne vont jamais se souvenir si le cookie
est mis ou pas, si ça recalcule ou pas.... Et puis

ah bin si, ils vont le voir : il y a le bouton "modifier" en bas.

c'est intéressant de pouvoir tester le fonctionnement
du cache, aussi.

dans ce cas ouvre ton second navigateur

Pour le répertoire CACHE : à ce moment-là, autant
mettre un "deny from all", c'est plus simple que
de recopier l'autre .htaccess (surtout qu'il n'existe
pas toujours !).

oui, tu as raison. la situation actuelle n'est pas satsfaisante, mais ma
solution non plus :wink:

-- Fil

5

Hello,

* Antoine Pitrou (pitrou@free.fr) écrivait :

Pour le répertoire CACHE : à ce moment-là, autant
mettre un "deny from all", c'est plus simple que
de recopier l'autre .htaccess (surtout qu'il n'existe
pas toujours !).

Sauf erreur de ma part, la solution du .htaccess ne marche pas. Si, dans une
partie publique, tu fais un include ou un virtual d'un fichier situé dans
une arborescence protégée, il refuse de te le servir (et c'est plutôt
rassurant). Donc si vous faites votre copie d'htaccess ou un deny from all,
les pages publiques ne pourront plus inclure le cache, c'est emmerdant.

Mais je suis d'accord avec Fil, c'est un peu emmerdant. (Quoique, vu que le
code est en GPL, tout le monde l'a déjà... Suffit que les trucs dangereux,
passwords etc ne soient que dans un fichier PHP tjs parsé, lui)

Laz

6

Lazuly :

Sauf erreur de ma part, la solution du .htaccess ne marche pas. Si, dans une
partie publique, tu fais un include ou un virtual d'un fichier situé dans
une arborescence protégée, il refuse de te le servir (et c'est plutôt
rassurant). Donc si vous faites votre copie d'htaccess ou un deny from all,
les pages publiques ne pourront plus inclure le cache, c'est emmerdant.

Non, ça marche, PHP ne passe pas par Apache quand tu fais
un include.

Aris :

Bon, la procédure elle-même est pas très propre... je sais. Mais faudrait
peut-être prévenir dans la doc au cas où certains utilisateurs seraient
tentés par les upgrades à la sauvage.

Non, normalement ça passe sans problèmes. Mais on ne peut rien te dire
de plus sans précisions. T'as regardé si ton login est toujours dans
la table spip_auteurs ? Tu as essayé de voir ce qui se passait quand
inc_auth.php3 est appelé ?

Fil :

Ce serait plus clair d'unifier les deux (i.e. si on se logue par mot de
passe on se fait poser un cookie, si on supprime le cookie on n'est plus
loggué par mot de passe).

Franchement, c'est deux fonctionnalités différentes. Tous les admins n'ont
pas forcément envie de se faire poser un cookie sur leur machine....
Pour le logout, je vais rajouter ça (je pensais que ça ne marchait pas
avec la méthode .htaccess ; effectivement sur certains serveurs ça
merde - e.g. Free).

Aris :

Autre remarque... Si je vais en zone "ecrire" sur un site SPIP et que je
laisse le cookie en partant, et que je vais sur un deuxième site SPIP de mon
serveur, toujours en zone "ecrire", il ne m'est plus demandé
d'autentification pour l'accès...

A priori, c'est du côté de ton navigateur que les codes d'accès
sont "cachés". Ca dépend des navigateurs, certains sont plus fins
que d'autres dans la façon dont ils envoient automatiquement les
codes déjà tapés (normalement c'est par répertoire).

Ceci dit, si ça marche comme ça, c'est que les couples login/pass
sont identiques sur les deux sites, sinon SPIP et/ou Apache devraient
t'envoyer bouler. C'est bien le cas ?

Fil :

Ai-je raison de penser que l'on pourrait passer les inc-* dans le dossier
ecrire ? Ce qui permettrait

Problèmes :

1) Les fichiers accédant à CACHE ou à IMG doivent être à la racine
à cause de l'impossibilité de remonter les répertoires en "safe mode"

2) Les fichiers de "config" (i.e. modifiables par le webmaster)
doivent rester à la racine pour ne pas être noyés au milieu d'un
océan de fichier "techniques".

Donc tous ces fichiers, ainsi que les fichiers les appelant en
include(), ne peuvent pas aller dans ecrire.

a+

Antoine.

7

Inconvénient de taille: la navigation par l'admin est alors systématiquement recalculée -> ralentissement important.

ARNO*