LucMorizur a écrit:
Or donc, j'ai l'intention de permettre au webmestre de se définir son tableau personnalisé de correspondance de caractères... si ça vous va...
Aucun soucis pour moi...
Sinon, très occupé actuellement... j'ai à peine le temps de lire vos messages... ;o)
Hors ligne
Bonsoir ;
il y a quelque chose que je ne comprends pas : comment est défini $conf_LCAS exactement ?
Car dans tous les fichiers, il est défini ainsi :
$conf_LCAS= unserialize($conf['LoginCaseAccentsSensitivity']);
Bon ; mais si on cherche comment est défini $conf['LoginCaseAccentsSensitivity'] , on ne le trouve que dans ./plugins/LCAS/admin/LCAS_admin.php :
$conf['LoginCaseAccentsSensitivity'] = serialize($newconf_LCAS);
et encore, inclus dans un bloc if :
if (isset($_POST['submit']) and !is_adviser() and isset($_POST['LCAS_Case_Sensitive']) and isset($_POST['LCAS_Accent_Sensitive']) and isset($_POST['LCAS_Mail'])) { /* General configuration settings */ $_POST['LCAS_MailText'] = str_replace('\"', '"', str_replace("\'", "'", str_replace("\\\\", "\\", $_POST['LCAS_MailText']))); $newconf_LCAS= array( $_POST['LCAS_Case_Sensitive'], $_POST['LCAS_Accent_Sensitive'], $_POST['LCAS_Mail'], $_POST['LCAS_MailText']); $conf['LoginCaseAccentsSensitivity'] = serialize($newconf_LCAS); // (...) }
Or de définir ainsi une entrée de $conf, ne la grave pas dans le marbre, si je ne me trompe ? Si ./plugins/LCAS/admin/LCAS_admin.php n'est pas exécuté, ce après validation des paramètres du plugin (afin que $_POST['submit'] entre autres soit défini), $conf['LoginCaseAccentsSensitivity'] n'est pas défini, et donc $conf_LCAS ne peut pas l'être ?
Ou bien je me goure quelque part ??
Hors ligne
[Subversion] r8638
Un gros set ce soir, je pensais me coucher plus tôt...
Mais en fait $conf['insensitive_case_logon'] nous fichait le bazar, car par exemple s'il était à true, et que l'on choisissait dans LCAS l'insensibilité aux accents seulement, il y avait en fait une insensibilité à la casse qui était effectuée par Piwigo...
J'ai résumé ça dans le tableau ci-joint (vous pouvez télécharger la feuille Excel (désolé, pas avec OpenOffice :-/ ) là si ça vous dit), et je l'ai implémenté. Dites-moi ce que vous en pensez...
P. S. : j'ai largement pas tout testé...
EDIT : petites corrections, [Subversion] r8643
Dernière modification par LucMorizur (2011-01-13 11:08:54)
Hors ligne
LucMorizur a écrit:
P. S. : j'ai largement pas tout testé...
Bon ben j'ai commencé (lentement, pas trop de temps en ce moment non plus), il y a du bug :-/ ... mais j'ai d'autres soucis avec ma galerie de tests en local, ce qui fait qu'il faut que je débugge bien d'un côté pour pouvoir débugger correctement de l'autre... bref.
Ce que montrent aussi les tests avec la version actuelle, c'est que la gestion de $conf['insensitive_case_logon'] en même temps que LCAS n'est pas fantastique. En effet, LCAS propose quatre options :
* insensibilité à la casse (1)
* insensibilité aux accents (2)
* insensibilité à la casse et aux accents (3)
* tableau personnalisé (0)
Or actuellement j'ai programmé pour que, si $conf['insensitive_case_logon'] est à true, seules les options 1 et 3 soient disponibles, et s'il est à false, seules les options 2 et 0 le sont -- cette dernière option (0) requérant aussi qu'un tableau personnalisé existe. Comme on voit, ça fait une gestion un peu complexe.
Je sais qu'on en a déjà parlé, mais, vraiment, ne vaudrait-il pas mieux que, lorsque LCAS est activé, il prenne le pas sur $conf['insensitive_case_logon'], en l'imposant à false ?
Hors ligne
LucMorizur a écrit:
Je sais qu'on en a déjà parlé, mais, vraiment, ne vaudrait-il pas mieux que, lorsque LCAS est activé, il prenne le pas sur $conf['insensitive_case_logon'], en l'imposant à false ?
Vraiment pas beaucoup de temps non plus, moi... :-/
Sur ton interrogation, je dirai qu'il ne faut pas perdre de vue que $conf['insensitive_case_logon'] ne traite *que* de la casse à l'identification. Selon moi, LCAS devrait surcharger l'existant sans en altérer le fonctionnement. Sinon, il y a un risque de mésentente sur les paramètres Piwigo vs LCAS.
Maintenant, d'un point de vue technique, faut voir...
Hors ligne
Eric a écrit:
Vraiment pas beaucoup de temps non plus, moi... :-/
Pas de souci ; en attendant que ça revienne, on peut au moins toujours discuter ;-)
Eric a écrit:
Sur ton interrogation, je dirai qu'il ne faut pas perdre de vue que $conf['insensitive_case_logon'] ne traite *que* de la casse à l'identification. Selon moi, LCAS devrait surcharger l'existant sans en altérer le fonctionnement. Sinon, il y a un risque de mésentente sur les paramètres Piwigo vs LCAS.
Disons que de mon point de vue, si LCAS est activé, alors il prend en charge complètement la casse et les accents, que ce soit à l'identification comme à l'enregistrement, et ce quelle que soit la valeur de $conf['insensitive_case_logon']. (Techniquement, en le surchargeant effectivement, juste après le chargement de ./local/config/config.inc.php .)
Ça a du sens, non ? Whiler, ton avis ?
Hors ligne
Bon, j'ai fini un petit truc qu'il fallait que je fasse, et j'ai réparé mes galeries de test avec lesquelles j'avais fait un peu n'importe quoi. J'ai l'intention donc de finir ce que je peux sur LCAS avant de finir la màj (mais ça va finir par être une réécriture quasi complète, si ça se trouve...) de Event Cats.
Or(es) donc :
LucMorizur a écrit:
Eric a écrit:
Sur ton interrogation, je dirai qu'il ne faut pas perdre de vue que $conf['insensitive_case_logon'] ne traite *que* de la casse à l'identification. Selon moi, LCAS devrait surcharger l'existant sans en altérer le fonctionnement. Sinon, il y a un risque de mésentente sur les paramètres Piwigo vs LCAS.
Disons que de mon point de vue, si LCAS est activé, alors il prend en charge complètement la casse et les accents, que ce soit à l'identification comme à l'enregistrement, et ce quelle que soit la valeur de $conf['insensitive_case_logon']. (Techniquement, en le surchargeant effectivement, juste après le chargement de ./local/config/config.inc.php .)
Ça a du sens, non ? Whiler, ton avis ?
Pour préciser les choses :
si on décide qu'effectivement LCAS n'influence pas le comportement de $conf['insensitive_case_logon'] ("opinion d'Eric", disons, actuellement) -- et c'est codé dans ce sens dans la dernière livraison --, alors ça signifie que par exemple :
_ un webmestre charge LCAS et l'active ; son $conf['insensitive_case_logon'] est à false et il n'a pas créé de tableau personnalisé pour LCAS ;
_ il va dans la page de contrôle de LCAS, il ne peut activer que l'insensibilité à la casse puisque $conf['insensitive_case_logon'] = false et qu'il n'a pas de tableau personnel ;
_ là quatre cas :
_ soit aucune option de LCAS n'est sélectionnée par défaut, mais de toutes façons seule "insensibilité aux accents" est disponible ;
_ soit on rajoute une option où rien chez LCAS n'est activé (le mieux si on conserve ce type de fonctionnement, voir plus bas), auquel cas on a cinq options dans LCAS, et les disponibles sont alors à ce moment-là "inactif" et "insensibilité aux accents", et évidemment c'est "inactif" qui est sélectionné par défaut ;
_ soit l'insensibilité aux accents est sélectionnée par défaut puisqu'elle est la seule disponible ;
_ soit l'insensibilité à la casse est sélectionnée par défaut car c'est elle la plus "populaire". Auquel cas LCAS affiche direct un message d'erreur, puisque $conf['insensitive_case_logon'] est à false !
_ il voudrait activer l'insensibilité à la casse et aux accents, il va donc dans LocalFiles Editor modifier la valeur de $conf['insensitive_case_logon'] ;
_ il retourne dans LCAS. Là, s'il avait sélectionné, en fonction des quatre cas cités ci-dessus, l'insensibilité aux accents, il a un message d'erreur de la part de LCAS car $conf['insensitive_case_logon'] est à maintenant à true, ce qui est gênant pour une insensibilité à la casse seulement !
_ bon, il peut tout de même sélectionner l'option d'insensibilité à la casse et aux accents et là tout va bien... jusqu'au jour où il veut changer, ce qui oblige comme on vient de voir et accessoirement en exprimant ça de façon concise, à gérer à la fois les options de LCAS et $conf['insensitive_case_logon'] , et en passant forcément par des messages d'erreur dans LCAS puisqu'on est forcé de changer $conf['insensitive_case_logon'] avant l'option de LCAS, et donc on se retrouve dans un cas où $conf['insensitive_case_logon'] est à une valeur ne correspondant pas à l'option actuelle de LCAS.
Voilà... c'est un peu ardu comme explication, j'ai fait tout mon possible pour mettre ça clair et pas trop long en même temps -- c'est pas facile.
Mais bon tout ça pour en arriver à dire que, sachant que $conf['insensitive_case_logon'] n'intervient dans le code actuel de Piwigo, vraiment que dans la vérification de la casse d'un compte nouvellement créé, je suis vraiment convaincu qu'il faut absolument que, contrairement au code actuel, LCAS gère complètement la casse et les accents, indépendamment du réglage de $conf['insensitive_case_logon']. Et je vais donc me remettre à coder, dans ce sens -- à la vitesse où je code (mais ça c'est quand même hyper simple comme changement), normalement ça laissera le temps aux intéressé(e)s de donner leur avis s'ils veulent que ce soit codé différemment.
À bientôt, donc :-) !
Hors ligne
Salut,
My 2 cents:
Si j'installe un plugin, c'est que j'estime que celui-ci m'apporte quelque chose...
Plus c'est imple, plus j'adhère au plugin en question...
Tout ça pour dire :
Je souhaite pouvoir gérer depuis l'admin de ce plugin ce à quoi il sert...
Je ne souhaite pas avoir à faire des modifs un peu partout...
Donc...
Qu'un plugin surcharge le comportement par défaut ne me choque pas.. bien au contraire, c'est souvent le but...
Et donc, pour en revenir à nos moutons, en tant qu'utilisateur :
- si j'installe LCAS, je m'attends à pouvoir faire les 4 réglages actuels
- je n'ai pas envie d'avoir à modifier $conf['insensitive_case_logon']
- concernant un 5è option, Inactif, elle serait redondante avec : Plugin/Gérer/LCAS Désactiver
Sinon, concernant la possibilité de créer ses propres réglages d'insensibilité, avec un tableau personnalisé, je réponds : pourquoi pas... mais dans une V2... s'il y a des besoins/demandes.. mais pour une V1, autnant resté simple... non ?
Hors ligne
Désolé mais je vais rester sur la touche encore quelques temps pour ce projet (les tests RC de Piwigo étant prioritaires sans parler de mes propres plugins). Ceci dit:
LucMorizur a écrit:
Mais bon tout ça pour en arriver à dire que, sachant que $conf['insensitive_case_logon'] n'intervient dans le code actuel de Piwigo, vraiment que dans la vérification de la casse d'un compte nouvellement créé, je suis vraiment convaincu qu'il faut absolument que, contrairement au code actuel, LCAS gère complètement la casse et les accents, indépendamment du réglage de $conf['insensitive_case_logon']. Et je vais donc me remettre à coder, dans ce sens -- à la vitesse où je code (mais ça c'est quand même hyper simple comme changement), normalement ça laissera le temps aux intéressé(e)s de donner leur avis s'ils veulent que ce soit codé différemment.
Ok, si on se désengage totalement de la configuration de Piwigo sur $conf['insensitive_case_logon'], çà me va.
Whiler a écrit:
Sinon, concernant la possibilité de créer ses propres réglages d'insensibilité, avec un tableau personnalisé, je réponds : pourquoi pas... mais dans une V2... s'il y a des besoins/demandes.. mais pour une V1, autnant resté simple... non ?
+1 pour la simplicité de la V1. On aura tout loisir de complexifier en V2 ;-)
Hors ligne
Whiler a écrit:
Plus c'est imple, plus j'adhère au plugin en question... (...)
Je ne souhaite pas avoir à faire des modifs un peu partout... (...)
Qu'un plugin surcharge le comportement par défaut ne me choque pas.. bien au contraire, c'est souvent le but... (...)
Et donc, pour en revenir à nos moutons, en tant qu'utilisateur :
- si j'installe LCAS, je m'attends à pouvoir faire les 4 réglages actuels
- je n'ai pas envie d'avoir à modifier $conf['insensitive_case_logon']
+1 à tout ça
Whiler a écrit:
- concernant un 5è option, Inactif, elle serait redondante avec : Plugin/Gérer/LCAS Désactiver
+1, je n'en ai pas envie non plus. J'évoquais ça juste pour étoffer mon exemple.
Eric a écrit:
Désolé mais je vais rester sur la touche encore quelques temps pour ce projet (les tests RC de Piwigo étant prioritaires sans parler de mes propres plugins).
Pas de soucis !
Eric a écrit:
Whiler a écrit:
Sinon, concernant la possibilité de créer ses propres réglages d'insensibilité, avec un tableau personnalisé, je réponds : pourquoi pas... mais dans une V2... s'il y a des besoins/demandes.. mais pour une V1, autnant resté simple... non ?
+1 pour la simplicité de la V1. On aura tout loisir de complexifier en V2 ;-)
M'bof. Je cède sous le nombre, mais pour moi cette fonctionnalité est vraiment importante car c'est elle qui donne son universalité au plugin : les utilisateurs -- les plus avertis il est vrai -- pourront grâce à elle implémenter une insensibilité à la casse et aux accents en arabe, en hébreu, en coréen, en inuktitut... De plus en termes de programmation c'est quasiment rien.
Mais bon. On va déjà faire simple, OK.
Hors ligne
[Subversion] r9158, LCAS prend en charge complètement la gestion de la casse.
Ça rend assez inutile l'affichage de la valeur de $conf['insensitive_case_logon'], qui est mis à false très rapidement dans le script par LCAS.
Bon ben sinon à part ça, ça fonctionne pas mal... reste surtout la partie notification, a priori, que je préfèrerais autant... laisser à d'autres ? :-) ; et aussi le message d'erreur lorsqu'un utilisateur essaye de s'enregistrer et que le nom d'utilisateur qu'il propose est déjà pris -- ça je dois pouvoir gérer, si ce n'est qu'UAM met son grain de sel là-dedans, il faut que j'approfondisse ça.
Hors ligne
LucMorizur a écrit:
[Subversion] r9158, LCAS prend en charge complètement la gestion de la casse.
Ça rend assez inutile l'affichage de la valeur de $conf['insensitive_case_logon'], qui est mis à false très rapidement dans le script par LCAS.
Super ! Pas le temps de tester maintenant mais dès que... Beau boulot en tous cas ;-)
LucMorizur a écrit:
Bon ben sinon à part ça, ça fonctionne pas mal... reste surtout la partie notification, a priori, que je préfèrerais autant... laisser à d'autres ? :-);
Me sens visé, là ;-)) Je regarderai çà dès que possible.
LucMorizur a écrit:
si ce n'est qu'UAM met son grain de sel là-dedans, il faut que j'approfondisse ça.
UAM "mettait" son grain de sel ;-)
Sur la partie identification, en tous cas. Pour l'inscription, c'est une autre histoire mais je ne pense pas qu'il y aura d'incompatibilités entre UAM et LCAS sur ce point. A vérifier...
Hors ligne
Eric a écrit:
Super ! Pas le temps de tester maintenant mais dès que... Beau boulot en tous cas ;-)
Merci :-) ! Mais... j'ai pas fait grand-chose...
Eric a écrit:
LucMorizur a écrit:
Bon ben sinon à part ça, ça fonctionne pas mal... reste surtout la partie notification, a priori, que je préfèrerais autant... laisser à d'autres ? :-);
Me sens visé, là ;-)) Je regarderai çà dès que possible.
Tieens, pourquoi te sens-tu visé ???...
;-)
Eric a écrit:
LucMorizur a écrit:
si ce n'est qu'UAM met son grain de sel là-dedans, il faut que j'approfondisse ça.
UAM "mettait" son grain de sel ;-)
Sur la partie identification, en tous cas. Pour l'inscription, c'est une autre histoire mais je ne pense pas qu'il y aura d'incompatibilités entre UAM et LCAS sur ce point. A vérifier...
Il ne s'agit pas, je pense, d'incompatibilité, c'est que si j'essaie de m'inscrire en fournissant un nom d'utilisateur qui peut être interprété comme un nom d'utilisateur déjà existant, alors l'inscription est refusée bien sûr, avec un message d'erreur modifié par UAM pour autant que j'aie compris. Mais je devrais pouvoir comprendre plus... si on me laisse éteindre la télé |-( ...
Sinon [Subversion] r9162, retrait de l'affichage de l'état de $conf['insensitive_case_logon'].
Hors ligne
LucMorizur a écrit:
Il ne s'agit pas, je pense, d'incompatibilité, c'est que si j'essaie de m'inscrire en fournissant un nom d'utilisateur qui peut être interprété comme un nom d'utilisateur déjà existant, alors l'inscription est refusée bien sûr, avec un message d'erreur modifié par UAM pour autant que j'aie compris. Mais je devrais pouvoir comprendre plus...
Pas dans les dernières versions d'UAM en tous cas. Les contrôles à l'inscription actuellement réalisés par UAM portent éventuellement sur la complexité du mot de passe, des caractères interdits dans le login et des domaines de messagerie interdits. Au niveau de l'identification, aucun contrôle n'est réalisé sur le login.
(j'ai l'impression d'avoir déjà eu cette conversation... ^^)
Hors ligne
Eric a écrit:
LucMorizur a écrit:
Il ne s'agit pas, je pense, d'incompatibilité, c'est que si j'essaie de m'inscrire en fournissant un nom d'utilisateur qui peut être interprété comme un nom d'utilisateur déjà existant, alors l'inscription est refusée bien sûr, avec un message d'erreur modifié par UAM pour autant que j'aie compris. Mais je devrais pouvoir comprendre plus...
Pas dans les dernières versions d'UAM en tous cas. Les contrôles à l'inscription actuellement réalisés par UAM portent éventuellement sur la complexité du mot de passe, des caractères interdits dans le login et des domaines de messagerie interdits. Au niveau de l'identification, aucun contrôle n'est réalisé sur le login.
En espérant ne pas me répéter lourdement...: ben en fait j'ai UAM 2.16.0 ; dans LCAS c'est l'insensibilité aux accents seulement qui est activée ; et donc lorsque (voir image attachée) j'essaie de m'inscrire en proposant un username qui peut être considéré comme déjà existant dans la configuration actuelle de LCAS (sur la galerie j'ai déjà un username "Sous-Privée"), j'ai un message d'erreur disant "ce nom utilisateur est déjà pris, ATTENTION le nom est insensible à la casse (Majuscule = Minuscule)". (LCAS n'est donc présentement pas configuré pour comme insensible à la casse, d'ailleurs si je propose "sous-Privée" c'est accepté ; et depuis la dernière version de LCAS, $conf['insensitive_case_logon'] est mis à false sur le trigger 'init'.)
Et donc pour finir, si j'effectue une recherche dans tous les fichiers PHP de cette galerie, sur la chaîne "ATTENTION le nom est insensible à la casse", je la trouve dans... ./plugins/NBC_UserAdvManager/language/fr_FR/plugin.lang.php ... d'où mon propos...
Et il s'agit donc de la clé de langue $lang['reg_err_login5'] (ligne 31). Voilà voilà.
Eric a écrit:
(j'ai l'impression d'avoir déjà eu cette conversation... ^^)
Tu parles de [Forum, post 158872 by LucMorizur in topic 19180] Insensible à la casse... :-) ??
Hors ligne