Merci à tous pour vos retours, rapides et lumineux.
Le problème est réglé en modifiant le template profile_content.tpl, selon la méthode fournie par ddtddt.

C'est pas super propre, mais au moins ça fonctionne :)
Problème résolu, merci la PWG Team !

ddtddt a écrit:

nicolas a écrit:

Note:
(1) cela pose tout même un problème qu'il faudrait que l'on règle en mettant systèmatiquement un jeton dans tous les formulaires pour être sûr qu'ils ont été générés par le serveur!

Un fiche dans le Bugtracker :)

On peut effectivement recréer les champs supprimés.

Mais quand même, changer son mot de passe... Cela reste bien son mot de passe et pas celui du copain, non?
Je ne peux changer mon mot de passe que si je suis connecté (Auto-connexion comprise, je sais).
Le risque est donc limité voire extrêmement limité il me semble.

Un vent de sagesse?

nicolas > Je ne voulais pas sous-entendre qu'il était évident que les utilisateurs étaient des pousse-bouton. Cela dit, les manips que tu indiques sont assez vicieuses : je n'y aurais pas pensé tout seul, ça c'est sûr. Avec ton explication, je comprends mieux ce que tu voulais dire dans le post précédent : certes, la modification de password reste possible pour les initiés. Ce qui est peu probable. Et de toute façon, aucun n'a de rôle supérieur à "visiteur", donc rien de compromettant question sécurité (pour autant que je puisse dire).
Bien vu aussi pour le problème de sécurité qui en découle !

ddtddt > Hm, en fait, ce que tu suggères, c'est que je bourrine le template, sans passer par la case "plug-in". Pas besoin de LocalFilesEditor pour ça, en fait ;) (j'aime autant faire le truc tranquille sur un environnement de test avant de pousser ça en prod).

Pour moi je ferais

Avec le plugin LocalFiles Editor

Onglet template -> yoga/profile_content.tpl

début de ligne 20 et 27 <!--
fin de ligne 25 et 38 -->

Inconvénient dans le profile des utilisateur en admin tu ne pourra plus changer les mot de passe (mais tu saura faire la manip inverse en cas de besoin

ddtddt a écrit:

L'utilisateur générique est un utilisateur qui se connecte avec un identifiant et un mot de passe mais qui n'a pas accès à la page personnalisation je pense que c'est ton besoin (sauf si tu veux leur permettre de changer de thème).

Vu que le moteur de template va changer lors de la sortie de la prochaine version, il est aussi simple, avec le plugin qui va bien, d'aller modifier le template et de supprimer les lignes qui affiche le changement de code.

J'avais lu un peut vite ton premier message ok c'est bien la midif du template

Merci de ton retour !

Oui, il faudrait que les utilisateurs puissent modifier la façon dont la galerie s'affiche si la fantaisie leur vient. Le seul truc qu'il ne faut pas qu'ils puissent faire, c'est changer de mot de passe.

Supprimer les lignes qui affichent le code, c'est précisément ce que j'essaie de faire... et c'est aussi ce qui ne marche pas ;)
Merci pour ta confirmation que la démarche semble correcte (modification du template à la volée).

Un print "$s"; après l'extraction de la chaîne -//:---\spam qu'elle est bien extraite : j'ai bien trois lignes ({lang:Password}, {lang:new_password} et  {lang:Confirm Password} ) avec les champs de saisie qui s'affichent en haut de page. Du coup, je ne comprends vraiment pas pourquoi les champs persistent à s'afficher. Qu'est-ce que je rate ?

ddtddt > Je pensais que c'était justement ce que faisait mon plug-in : retirer du texte dans le template quand le trigger est lancé ?! Du coup, pas besoin de modifier le php...

P@t & ddtddt > Non, l'utilisateur générique ne semble pas la bonne solution, car il faudrait quand même que l'utilisateur saisisse un password pour être identifié (sauf erreur de ma part, ce n'est pas le cas avec Générique - d'après ce que j'ai compris de la doc ; je n'ai pas testé). EDIT : j'ai testé ; apparemment il faut bien saisir le mot de passe : bon point. En revanche, l'utilisateur ne peut plus personnaliser son affichage, ce qui n'est pas souhaitable.

nicolas > Bah non, justement. Le fait de modifier le template à la volée pour empêcher l'affichage de ces champs fait que l'utilisateur peut bien taper l'URL de profile.php, il ne verra quand même pas les champs (ou alors, j'ai rien compris, ce qui reste possible). Et même si c'était le cas, les utilisateurs supposés de la galerie n'ont pas le niveau technique (ce sont des clique-bouton, quoi).

P@t > Merci pour l'info ; j'ai corrigé mais la page de profil n'est pas modifiée... Le trigger "end" arriverait-il trop tard ?!


Merci de vos retours, tous ! Que pensez-vous de la situation ? Pas brillant, hein ? :)

C'est normal, le template n'est pas encore assigné lors de l'évènement loc_begin_profil. Il faut faire:

add_event_handler('loc_end_profile', 'personal_cache_password');

Mais comme dit ddtddt, il faut voir si l'utilisateur générique n'est pas la bonne solution...

Bonjour à nouveau ;)

Nouveau besoin, nouvelle problématique : je cherche à supprimer, dans la page "Profil" (profile.php) les trois champs liés au mot de passe. L'idée est que le visiteur ne puisse pas modifier son mot de passe (je m'y prends peut-être mal, n'hésitez pas à signaler si c'est le cas).

Partant de choses qui fonctionnent, j'ai rédigé le plug-in suivant :

<?php
/*
Plugin Name: Cache Change Password
Version: 0.0.0.1
Description: Dans la page "Personnaliser", cache les champs permettant de redefinir le mot de passe de l'utilisateur.
Author URI: http://phpwebgallery.net/doc/doku.php/fr:personnalisation:branche_1.7:menubar
*/

add_event_handler('loc_begin_profile', 'personal_cache_password');

function personal_cache_password()
{
  // Recupere et enleve les trois champs de password
  $s = personal_remove_tpl_code('profile_content', '<!-- BEGIN not_admin -->', '<!-- END not_special_user -->');
}

/* Suppression d'une partie du code dans un template */
/* Code compris entre la chaine $str_begin et $str_end */
function personal_remove_tpl_code($tlp_handle, $str_begin, $str_end)
{
  global $template;
  $template->loadfile($tlp_handle);

  $p_beg = strpos($template->uncompiled_code[$tlp_handle], $str_begin);
  $p_end = strpos($template->uncompiled_code[$tlp_handle], $str_end) + strlen($str_end);
  $s = substr($template->uncompiled_code[$tlp_handle], $p_beg, $p_end - $p_beg);

  $template->uncompiled_code[$tlp_handle] = 
  substr_replace($template->uncompiled_code[$tlp_handle], '', $p_beg, $p_end - $p_beg);
 
  return $s;
}

?>

Problème : le seul résultat est un texte d'erreur au lieu de la page Profil : "Template->loadfile(): No file specified for handle profile_content"
Et là, j'ai beau chercher, je capte pas. Ça marche au poil pour menubar, mais je comprends pas pourquoi, dans template.php, "files[$handle]" semble vide.
Si l'un de vous a une idée sur le pourquoi, ou sur la façon de débugger ça (je débute en PHP ; j'ai beau avoir des bases - lointaines - en Java, shell et Basic, c'est un peu rude), je suis preneur !

Merci d'avance !


Précisions peut-être utile : PWG v.1.7.3, PWG_Stuffs installé (utilisé uniquement pour sa fonction "bloc personnel") et quelques autres plug-ins perso (tout petits : chacun gère une seule fonction : changement sur menubar / adaptation de la taille des vignettes / modification de la bannière sur la page d'administration).