Oui, mais pour ca, on attends le developpeur, qui gere les sources du module. Je ne suis pas sure, que j'ai toutes les adaptions proposee dans ce discussion, mais c'est toujours possible pour obtenir une zip de mes sources par PM.

J'ai aussi placee une explication pour la probleme du boite a selection sur Xoops.org .

Peut-etre, je doit m'excuser pour l'idee, que la bas s'atire plus d'attention et devient plus rapide resolu. :oops:

J'ai encore quelque messages debug php, quand je montre le bloc avec les formulaires disponible:
Quand le bloc est mis au invisible, les messages sont disparu egalement.

Pour les menu descriptifs qui se montre avec le hoover audessus les images en admin en prennant toute la largeur d'ecran, ca est resolue en FF3.

Donc,
-1- l'utisateur vient a ton site Xoops
-2- il fait le login en Xoops
-3- il va au page avec le chat code (piece code mo 2) et le demarre
-4- le site chat fait une verification avec piece code no 3
-5- si bon l'utilisateur peut faire le chat, autrement il est exclus.

Est-ce-que l'utilisateur a aussi une compte a la site chat?

Si oui, comment est il enregistree (sur le site chat) et est-ce que le nom ou mot-de-passe doit corresponder avec celles de Xoops?

Si non, le nom (pseudo) qui est utilisee dans le chat est celui prevu dans la page de Xoops (no 2).

Autrement il faut m'expliquee, les relations entre les utilisateurs (et compte) du deux sites et la deroulment des actions.

Il y a quand-meme des possibilitees pour la verification d'utilisateur, mais il faut d'abord expliquer que-est-qu'il doit passee (quelle actions et par qui, comment vous pensez que ca doit marcher idealment).

Retrouver dans la formulaire d'example (SQL pour l'installation du module):

J'ai adaptee ca dans le database manuellement et comme ca, ca marche. Mais faire certaines modifications a la formulaire detruites ce valeur.

Je crois qu'il existe seulement le nummero d'utilisateur en $_SESSION['xoopsUserId'] (et son nummero du usergroup, qui est le plus important pour les droits sur la site).

Les autres variables ne sont pas la, parcequ'ils sont une risque de securite! Le mot de passe est d'ailleur encryptee a sens unique dans le database.
Qu'est-ce-que vous essayent de faire et pourquoi?

Citation :J'ai retester ce fonction et j'experience la meme problem. :-o
Pourtant, j'ai utilisee ca une fois, mais je crois c'etait mieux pour les utilisateurs, qu'il utilise des boutons radio (pour des petites selections (6)).
J'ai l'impression que ca devient mal encodee dans la database. Le champ ele_value pour une selection est:
Surtout ce 'array' me semble pas juste.

Peut-etre Dugris aime seulement ?les utilisateurs Firefox 3.0.

Autrement, le download est camouflee comme titre de l'article. Cliquez dessus pour le demarrer. (Les deux lignes en dessous pointes sur des pages deja visibles.)

Dependent a la nature de ton site il faut extensier xoops avec des modules. Il existe des .modules packs predefinie.
Avant d'installer verifiez q'il n'existe pas une nouvelle version sur la site du programmeur (par exemple News 1.56 est maitenant 1.61).
Naturellement, vous etes libre de combiner comme vous voudrez. Regardez a des sites existant (comme frxoops.org) et voyez quelle modules sont utiliser et q'il sont utile a vous.

Ou attendre a Xoops 3.0

@agir: Verifier en admin modules formulaire menu (modules/formulaire/admin/menu_index.php) tous les formulaires necessaires sont bien activee.

@Emulgator2: Vous avez une version Anglaise? Oui, faites certainements les modifications d'ici.

Il y a une page, a quelle je n'ai pas de confiance, et c'est pour le nouveau ordre pour tous les elements dans une formulaire. (modules/formulaire/admin/index.php?id=x) (x=no d'id) Il y a le bouton 'new sort' qui permit d'arrangee tout l'ordre des elements d'une formulaire et leur option pour montrer ou 'required'. Ca a donne des problemes et a partir je modifie tous les elements apart, pour leurs position et options. Plus lentement, mais plus sure.

C'est possible de verifier les droits dans le database meme, avec phpMyAdmin.
Faites bien attention et prenez d'abord une backup!
Selectionez le table XXX_group_permission (XXX = prefix) et clique sur browse.
Sortez par colonne gpermname par cliquer dessus. Cherchez dans les pages pour 'Droits des categories' ou 'Permissions of the categories' (dependent de la langue). Notez le nummero pour le moduleid dans la colonne gperm_modid. (Aussi a voir dans le tableau XXX_modules) Verifiez que tous les id des formulaires en colomme gperm_itemid ont une id de user comme necessaire dans la colonne gperm_groupid. (1=admin, 2=registrants, 3=anonymes, 4,5,...=cat. extra (voir tableau XXX_groups (1-3=standard))). Inserez les combinations manquant.

Alors triez par gperm_itemid et cherchez dans le pages pour le moduleid (voir note). La il faut que la permission 'module_read' existe pour tous les users, qui ont besoin la module formulaire. Quand vous utilisez des blocks, il faut aussi la permission 'block_read' pour chaque usergroup, qui l'a besoin. Le droit 'module_admin' est reservee pour les admins ou groupes qui peut rediger des formulaires.
Chez moi il y a encore des droits 'profile_edit' et 'profile_search' mais je crois qu'il sont specifique de Xoops 2.2 et il sont attribuee a admin et certaines registrants, mais ne sont pas necessaire pour remplir des formulaires.