Re : Plugin Auteur Complet + #SESSION

Merci à vous deux pour votre réponse … super rapide !
Dans mon squelette j’ai juste mis id_auteur =
#SESSION{id_auteur} et en effet ca ne fonctionne pas. J’ai juste id-auteur et non l’id de l’auteur.

Ce que j’ai fait :
télécharger le plugin
uploadé dans le répertoire plugins
activer dans l’interface de l’admin
dans une page du squelette ajouté id_auteur =
#SESSION{id_auteur}

Ai-je oublié quelque chose ?

Merci
Olivier

----- Message d’origine ----
De : BMR bmr@ediweb.org
À : spip@rezo.net
Envoyé le : Jeudi, 1 Mars 2007, 8h52mn 15s
Objet : Re: [Spip] Plugin Auteur Complet + #SESSION

J’ai essayé le plugin #SESSION sur 1.9.2, il fonctionne.

Il suffirait de mettre dans ton squelette « id_auteur =
#SESSION{id_auteur} » pour voir s’afficher le numéro d’auteur, si ça
fonctionne.

BMR

Webmaster Zetudiants.net a écrit :

Bonjour,

Pour utiliser le plugin « Auteur Complet » il faut que le plugin #SESSION
soit installé.
J’ai SPIP 1.9.2 (la dernière version téléchargeable sur le site).

  1. comment puis-je vérifier que le plugin #SESSION fonctionne ? Car il
    me semble qu’il ne marche pas.

  2. le formulaire public pour modifier son profil avec « Auteur complet »
    fonctionne-t-il uniquement pour les rédacteurs ou aussi pour les membre
    (visiteur forum) ?

  3. Comment appeler ce formulaire ?

  4. Est-ce que parmis vous, certains sauraient si un plugin de type
    « communaut*é » serait en développement ? * Un plugin qui permettrait,
    coté public, de gérer leur profil avec gestion de l’avatar, de consulter
    la fiche des autres membres en pouvant leur envoyer un message, etc. Sur
    l’idée de « Auteur complet », le webmaster pourrait créer les champs dont
    il a besoin pour la gestion de ces membres, sans que cela soit
    déterminer par avance.

Merci.
Bonne journée à vous tous.
Olivier


liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip-contrib.net/spikini/FaQ

On Thu, 2007-03-01 at 08:16 +0000, Webmaster Zetudiants.net wrote:

Ce que j'ai fait :
télécharger le plugin
uploadé dans le répertoire plugins
activer dans l'interface de l'admin
dans une page du squelette ajouté id_auteur =
#SESSION{id_auteur}

Ai-je oublié quelque chose ?

Les pages qui utilisent ça doivent avoir un cache à 0

--
À+, Pif.

christian lefebvre a écrit :

On Thu, 2007-03-01 at 08:16 +0000, Webmaster Zetudiants.net wrote:

Ce que j'ai fait :
télécharger le plugin
uploadé dans le répertoire plugins
activer dans l'interface de l'admin
dans une page du squelette ajouté id_auteur = #SESSION{id_auteur}

Ai-je oublié quelque chose ?

Les pages qui utilisent ça doivent avoir un cache à 0

juste une remarque sur l'acces restreint et la balise session :
Cela ne fonctionne qu'avec un cache à 0.

Ce qui veut dire que, si le squelette est bien compilé une fois pour toute, les requetes, elles, sont executées à chaque appel.
On perd donc completement l'interet du cache qui est pour moi le plus gros interet de Spip

C'est donc à utiliser en connaissance de cause (eviter de faire 5 boucles imbriquées ou des boucles hierarchie avec un cache à 0).

Une mauvaise utilisation de ces outils peut conduire les hebergeurs à dire que Spip est une usine à gaz... si c'est pour balance 400 requetes à chaque hit, autant faire du PHP directement et optimiser ces requetes.

C'est une discussion qu'on a deja eu sur spip-zone, mais je crois que c'est important de le rappeler ici.

Personnellement, je prefere exploiter le cache...

Il n'est pas compliqué de faire du cache personnel ou par statut, il suffit de se faire ses propres scripts d'inclusion et de mettre la variable souhaitée dans le contexte.
Dans ce cas, on multipliera les fichiers de cache, mais un utilisateur pourra cliquer 25 fois sur refresh sans ecrouler le serveur....

mes 2 sous.

@++

PS : voila un exemple simpliste pour illustrer :

bloc_perso.php :
<?php
//secu basique
if (!isset($contexte_inclus['fond'])
  || strstr($contexte_inclus['fond'], '..'))
    die ("erreur");
//mettre l'id_auteur dans le contexte
if (($GLOBALS['auteur_session']['statut']=="0minirezo")
  ||($GLOBALS['auteur_session']['statut']=="1comite")
  ||($GLOBALS['auteur_session']['statut']=="6forum")) { $contexte_inclus['auteur_session_id']=$GLOBALS['auteur_session']['id_auteur'];
$contexte_inclus['auteur_session_statut']=$GLOBALS['auteur_session']['statut'];
}
//renvoyer les non authentifiés sur un autre bloc
else $contexte_inclus['fond']='login';

include _DIR_RESTREINT_ABS.'public.php';
?>

de cette facon, on peut faire dans un squelette, quel que soit son cache :
<INCLURE(bloc_perso.php){fond=squelette_perso}>

et dans squelette_perso, on a toujours #ENV{auteur_session_id} et #ENV{auteur_session_statut}

On ne risque pas d'afficher le cache generé pour l'utilisateur A à l'utilisateur B, et on peut jouer sur le temps de mise en cache de cette inclusion.

PS2 : pour faire un cache par statut, il suffit de ne pas mettre l'id_auteur dans le contexte.

On Thu, 2007-03-01 at 13:29 +0100, spipcarto wrote:

$contexte_inclus['auteur_session_id']=$GLOBALS['auteur_session']['id_auteur'];
$contexte_inclus['auteur_session_statut']=$GLOBALS['auteur_session']['statut'];

  Est-ce que ça signifie qu'il suffirait d'ajouter ça dans les plugins
balise/boucle session pour que le cache ne soit plus un problème ?
  Idéalement, on pourrait même se contenter de n'en mettre qu'un des
deux selon les champs utilisés (si on s'en sert que pour filtrer le
statut, li suffit du laisser le second).

--
À+, Pif.

christian lefebvre a écrit :

On Thu, 2007-03-01 at 13:29 +0100, spipcarto wrote:

$contexte_inclus['auteur_session_id']=$GLOBALS['auteur_session']['id_auteur'];
$contexte_inclus['auteur_session_statut']=$GLOBALS['auteur_session']['statut'];

  Est-ce que ça signifie qu'il suffirait d'ajouter ça dans les plugins
balise/boucle session pour que le cache ne soit plus un problème ?

non, c'est au niveau de l'inclure que ca se joue.
il faut générer des caches differents, sinon, ce qui est calculé pour A sera resservi à B.

Si tu es dans un squelette, c'est "trop tard".
Ou alors, il faut faire un formulaire, la, pas de souci de cache et le formulaire peut lui meme appeler les squelettes en mettant ce qu'il veut dans le contexte, ce qui revient au systme d'inclusion dont je parlais.

  Idéalement, on pourrait même se contenter de n'en mettre qu'un des
deux selon les champs utilisés (si on s'en sert que pour filtrer le
statut, li suffit du laisser le second).

oui, c'etait un exemple simpliste.
Il faut adapter à son besoin et ne pas hesiter à mettre dans le contexte ce qui peut servir (si ca ne multiplie pas les caches)

@++