Forum CMS Made Simple FR
[Résolu]Permissions de groupes spécifiques aux pages - Version imprimable

+- Forum CMS Made Simple FR (https://forum.cmsmadesimple.fr)
+-- Forum : Général (https://forum.cmsmadesimple.fr/forum-3.html)
+--- Forum : Général (https://forum.cmsmadesimple.fr/forum-10.html)
+--- Sujet : [Résolu]Permissions de groupes spécifiques aux pages (/thread-260.html)

Pages : 1 2


[Résolu]Permissions de groupes spécifiques aux pages - Yvan - 31/03/2010

Hmm... J'ai fait le tour des préférences dans la gestions des utilisateurs du site, mais j'ai pas localisé d'option qui permette ça. Je me suis demandé si c'était pas 'utiliser les permissions spécifiques des FEUsers', mais c'est finalement pas ça. Note, je comprends pas vraiment ce que c'est, donc je peux me tromper !

Je ne suis pas non plus sûr de la façon dont on va créer une page membre. J'ai trouvé des bouts de code du genre :

{cms_module module=CustomContent}
<!--customContent: startif group=members -->
{cms_module module=FrontEndUsers form=silent}
Tu es membres !

<!--customContent: else -->
Tu n'es pas encore enregistré :
{cms_module module=FrontEndUsers}

<!--customContent: endif -->

Ce que je comprends pas, c'est la syntaxe des commandes entre '<!--' et '-->' (d'ailleurs, elles apparaissent tel quel dans le rendu). Et ça sort d'où endif et startif ? Et group ? Bon, la doc montre aussi une autre façon qui reprend les mêmes commandes présentées dans l'aide :

{if $customcontent_loggedin > 0}
Bienvenue {$customcontent_loginname}
{else}
Vous n'êtes pas autorisé à regarder ce contenu
{/if}

Pour moi, ça suffirait comme j'aurai qu'un seul groupe de membres. Sauf que la page n'affiche aucune mise en page + cette erreur :
string(121) "Smarty error: [in content:content_en line 1]: syntax error: unidentified token ';' (Smarty_Compiler.class.php, line 1410)"
Parse error: syntax error, unexpected '>' in /home/www/2facc9cde4200ebea4065b97f8888179/web/test_cmsms/tmp/templates_c/66^%%70^707^707A8977%%content%3Acontent_en.php on line 7

Un autre truc, c'est que j'ai cru comprendre qu'on devait éviter de mettre du code dans le contenu d'une page. Si on veut mettre du php, il faut créer des tags utilisateurs et on peut faire des templates pour mettre du Smarty. C'est juste ? Mais pour une simple condition comme au-dessus, on s'en fout ?

J'ai fouillé les forums pour mon problème de menu de pages réservées aux membres. J'ai trouvé ça à mettre dans le template du 'navigation block' :

{cms_module module=CustomContent}
<!--customContent: startif group=members -->
{menu template='simple_navigation.tpl' collapse='1'}
<!--customContent: else -->
{menu template='simple_navigation.tpl' number_of_levels="0"}
<!--customContent: endif -->

ça signifie que si le visiteur ne fait pas partie du groupe 'members', le menu n'affichera rien ? ça n'a pas de sens...

Finalement : on est obligé de mettre une propriété pour créer un groupe et on est obligé d'appartenir à un groupe. Mais je m'en tape, moi. Je veux pas de groupe. Je veux juste des membres avec un nom et un mot de passe. J'ai rajouté un champ bidon spécifié comme requis et je suis pas obligé de le mettre pour me connecter....

Désolé pour le pavé... Sad


[Résolu]Permissions de groupes spécifiques aux pages - bess - 01/04/2010

comme j'ai dit, la notion de connexion frontale avec un utilisateur du back-office, je ne gère pas des masse. créé une nouvelle discussion à ce sujet tu auras plus de chance d'avoir des retours sur le problème.


[Résolu]Permissions de groupes spécifiques aux pages - Yvan - 01/04/2010

Ok. J'ai trouvé sur le forum international, écrit pas un certain Pierre M. (que tu connais, j'imagine) :

"Je crois que c'est plutôt v2 d'avoir les mêmes utilisateurs quel que soit le côté du système."

Donc, ça doit être rapé... Pour ce qui est de mon autre problème, je l'ai en partie résolu :

C'est l'éditeur WYSIWYG qui faisait planter les commandes smarty. Je sais pas pourquoi, mais il transforme les '->' en '->'. C'est habituel ? J'ai aussi remarqué que, quand je passais de l'éditeur normal au WYSIWYG, le rendu passait par une étape plus proche du rendu du site avant de revenir à un rendu moins sexy. Par exemple, les éléments des listes se décalent légèrement sur la droite avant de revenir contre la gauche... Bizarre, non ?

Dernier point, pour l'instant, j'ai mis mon CMS en ligne dans un répertoire test_cmsms. Est-ce que je pourrai facilement en prendre le contenu et le mettre directement dans le répertoire du site, ou le changement de file path sera désastreux ?


[Résolu]Permissions de groupes spécifiques aux pages - bess - 01/04/2010

désactive le WYSIWYG pour coder ce genre de chose car effectivement il transforme < et >. Si tu veux pas mélanger code et contenu tu peux l'insérer via un contenu global ou un tag utilisateur.

la modification de répertoire est facile à faire et un seul fichier est à modifier pour répercuter les modif. On en a déjà évoqué le sujet sur le forum à de nombreuses reprise Wink


[Résolu]Permissions de groupes spécifiques aux pages - Yvan - 01/04/2010

Justement, j'aimerais beaucoup, beaucoup mieux pouvoir rester en WYSIWYG. Le tag utilisateur, j'y ai pensé. J'ai fait ça comme tag:

if($params['condition']) {
echo $params['texte'];
}

et je l'appelle comme ça :

{membre condition='$ccuser->loggedin()' texte= ' fsfsdf

sdfsdfsd

sdfsdfsdf'}

C'est bien, ça garde la forme que lui donne et je pense mettre un else, mais je voulais savoir s'il y avait mieux. Comment tu trouves mon idée ? Y a moyen de mettre des paramètres optionnels ? (pour un else, par exemple)


[Résolu]Permissions de groupes spécifiques aux pages - bess - 01/04/2010

ton texte ne pourras pas du coup être édité sous WYSIWYG.

dans ta page sans WYSIWYG

{if $customcontent_loggedin > 0}
{global_content name='contenuConnecte'}
{else}
{global_content name='contenuNonConnecte'}
{/if}

là tu as deux blocs éditable en WYSIWYG Smile


[Résolu]Permissions de groupes spécifiques aux pages - Yvan - 01/04/2010

Cool ! Je savais pas ça... Merci Smile Mais donc, il faudra faire ça pour chaque page réservée aux membres. Si c'était possible, je préférerais que les éditeurs n'aient pas à se préoccuper de ça : s'ils créent une page fille à une page réservée aux membres, elles devraient être automatiquement réservées aux membres, qu'ils n'aient pas à s'embêter avec du code, même s'il est très simple. ça n'a pas l'air possible, est-ce que je me trompe ?

Autre question : en général, quand un utilisateur arrive sur une page réservée, on lui repropose de s'enregistrer, même si le formulaire se trouve déjà plus haut, n'est-ce pas ? Mais je n'aimerais pas remettre l'option 'Me mémoriser sur cet ordinateur', par exemple. Y a-t-il un moyen de jouer avec les variables du gabarit de connexion dans l'appel au formulaire ?

Dernier point, pour l'instant, j'ai mis mon CMS en ligne dans un répertoire test_cmsms. Est-ce que je pourrai facilement en prendre le contenu et le mettre directement dans le répertoire du site, ou le changement de file path sera désastreux ?


[Résolu]Permissions de groupes spécifiques aux pages - bess - 01/04/2010

Citation :je préférerais que les éditeurs n'aient pas à se préoccuper de ça : s'ils créent une page fille à une page réservée aux membres, elles devraient être automatiquement réservées aux membres,
déplace le code et adapte le dans un gabarit dédiée aux pages ou tu applique un contrôle

Citation :Autre question : en général, quand un utilisateur arrive sur une page réservée, on lui repropose de s'enregistrer, même si le formulaire se trouve déjà plus haut, n'est-ce pas ? Mais je n'aimerais pas remettre l'option 'Me mémoriser sur cet ordinateur', par exemple. Y a-t-il un moyen de jouer avec les variables du gabarit de connexion dans l'appel au formulaire ?
voir les gabarit proposé dans le module feu ou customcontent tout doit y être

pour ta dernière question je t'ai déjà répondu


[Résolu]Permissions de groupes spécifiques aux pages - Yvan - 01/04/2010

Oups ! Je m'excuse de me répéter. merci pour ta réponse !

J'ai déplacé le code comme tu as proposé ! Mais à ce sujet, j'essayais d'abord avec '$customcontent_loggedin > 0' pour la condition et ça ne marchait pas (c'était toujours le texte pour les non-membres qui s'affichait). J'ai ensuite essayé avec '$ccuser->loggedin()' et ça fonctionnait parfaitement... Quelle en est la raison ?

Pour ce qui est du gabarit de connexion, j'ai bien vu qu'on pouvait le customisé à souhait. Mais j'aimerais savoir comment avoir deux formulaires de connexion qui soient différents. Je ne sais pas si on peut créer d'autres gabarit relatifs à FrontEnd Users où ajouter un paramètre à la commande et une condition à l'intérieur du gabarit... Tu vois où je veux en venir ?


[Résolu]Permissions de groupes spécifiques aux pages - bess - 01/04/2010

Citation :Quelle en est la raison ?
aucune idée, peut être une évolution du module ?

Citation :Tu vois où je veux en venir ?
oui et si je ne pense pas que tu puisse créer X gabarits par type de formulaire je suis certain que tu peux personnaliser l'unique gabarit disponible afin d'y inclure des paramètres.

par exemple avec la syntaxe {assign} de smarty, tu peux définir une variable qu'a mi hauteur de ton gabarit (juste avant le second appel du formulaire). De l'autre côté dans le gabarit du formulaire tu fais un test : si la variable est nulle alors [gabarit par défaut] sinon [gabarit moins quelques trucs]


[Résolu]Permissions de groupes spécifiques aux pages - Yvan - 01/04/2010

Je vais regarder ça, merci !

Une petite en passant : j'ai vu que certains spécifiaient '{cms_module module=CustomContent}' avant d'utiliser la variable $ccuser, par exemple. Mais ça n'a pas l'air nécessaire... Y a-t-il une réelle utilité à cette commande ?


[Résolu]Permissions de groupes spécifiques aux pages - bess - 01/04/2010

aucune idée. faut tester.


[Résolu]Permissions de groupes spécifiques aux pages - Yvan - 01/04/2010

Ben, j'ai l'impression que ça fait rien... Jusqu'au jour où des trucs planteront sans explication !

Sinon, j'ai repensé à mon problème de menu, pour qu'il n'affiche que les pages non-réservées aux membres quand l'utilisateur n'est pas connecté.
J'ai regardé le fichier cssmenu.tpl et je me suis dit que je pouvais changer la nodelist pour qu'elle ne contienne que les pages visibles par le membre :

{if !$ccuser->loggedin()}
{assign var=i val=0}
{foreach from=$nodelist item=node}
{if ($node->alias|truncate:7:"":true)!="membre_"}
{assign var=realnodelist[$i] val=$node}
{assign var=i val=i+1}
{/if}
{/foreach}
{assign var=nodelist val=$realnodelist}
{/if}

J'ai regardé la doc de Smarty, mais j'arrive pas à trouver les trucs de base dont j'ai besoin. Résultat, mon machin est tout faux, forcément. Mais, il me semble que l'idée est bonne...


EDIT: Je suis naze. J'ai finalement utilisé le paramètre excludeprefix et ça marche tout seul... Mais juste pour la forme, ce serait bien si quelqu'un peut me dire si mon idée allait marcher et ce que j'aurais dû changer dans mon petit bout de code. Merci Smile


[Résolu]Permissions de groupes spécifiques aux pages - Yvan - 06/04/2010

Rebonjour !

Après ce long weekend, j'essaie de remanier le template des articles pour faire exactement ce que je veux. Par rapport à l'exemple de news qui est donné avec le CMS, je ne comprends pas pourquoi il s'affiche comme il le fait. Quand je ne mets pas de sommaire, j'ai seulement le droit à un lien vers le texte complet et j'ai dû changer le template pour obtenir le même résultat que dans l'exemple... Vous savez pourquoi ?

Pour le reste, ça marche pas mal, sauf que j'aimerais utiliser un champ que j'ai moi-même défini avant le titre :

{if isset($entry->fields["Date"])}
<div class="NewsSummaryLink">
Date: {eval var=$entry->fields["Date"]->value}
</div>
{/if}

J'obtiens l'erreur suivante : syntax error: unidentified token '["Date"])'

Par la suite, j'aimerais également ne pas rappeler ce champ 'Date' dans la boucle foreach, mais je ne vois pas comment faire...

Quelqu'un a une idée ? Merci !


[Résolu]Permissions de groupes spécifiques aux pages - jce76350 - 06/04/2010

Si c'est résolu je ferme la discussion