[testing] à propos du mot de passe
by Aide Pour
petite question relative au mot de passe Dc
si je m'en réfère aux informations données par webdevelopper:
id="user_pwd" maxlength="255" name="user_pwd" size="20"
ce qui signifie que le mot de passe peut comporter jusque 255 caractères
mais que la zone de texte ne permet l'affichage que de 20 caractères à
la fois (longueur)
D'où ma question: la longueur du mdp est-elle vraiment limitée à 255
caractères ?
Si oui, ne pourrait-on pas avoir une longueur plus importante pour la
zone de texte ?
Question subsidiaire: tous les caractères alphanumériques sont-ils
autorisés ?
--
Bernard - *Dotclear chez les chtis*
http://forum.dotclear.org/viewtopic.php?id=47318
https://www.facebook.com/groups/DotclearChezLesChtis/
10 years, 9 months
"Let fieldsets be fieldsets "
by Dsls
Re,
Pour les profanes en ergo/a11y/standards comme moi, vous pouvez donner
quelques explications sur les refontes ergo qui visent à supprimer les
<fieldsets> ?
Je suis curieux :)
--
Bruno
10 years, 9 months
[testing] Maj 2.6-dev-r1482 : admin kapout
by mirovinben
Après mise à jour de 2.6-dev-r1466 à 2.6-dev-r1482, impossible de se (re)connecter à l'admin avec message dans page blanche :
*Fatal error*: Call to a member function addNamespace() on a non-object in *plugins\pages\_install.php* on line *24*
10 years, 9 months
Question sur changeset 1468
by Dsls
Hello,
Je merge régulièrement default et twig. Je viens de constater que le
changeset 1468 sur la branche default ajoute un titre h3 "hidden". C'est
volontaire ?
C'est ligne 541 du fichier admin/post.php : echo '<h3
class="hidden">'.__('Edit post').'</h3>';
--
Bruno
10 years, 9 months
[sexy] error_handler
by Denis Jean-Christian
Hello les (non) vacanciers,
J'ai fini les quelques fixes que je savais faire sur la branche
"default" et je suis retourné sur la branche "sexy". Ce mail me permet
de faire une petite mise au propre de mes réflexions sur la gestion des
erreurs et surtout d'avoir un petit coup de main ;-)
Je me penche donc sur la mise en place d'un gestionnaire d'erreur pour
TOUT Dotclear, en effet aujourd'hui il y a un peu tout est n'importe
quoi comme manière de lever des erreurs:
- Erreur de lancement avec __error(),
- Erreur interface avec core->error(),
- Erreur divers avec throw new Exception(),
- Erreur style deprecated (comme dans dcSettings) avec trigger_error(),
- ETC...
Avec également encore des différences avec les modes DC_DEBUG, CLI_MODE, ...
Mon but est que tout passer par un seul et même endroit puis d'y
redistribuer après, cela faciliterait la gestion des erreurs et
l'ouverture aux plugins, ou autres gestionnaires de backoffice et aussi
les log en mail/text/base...
Quelques limites se dessinent:
- Pas forcément compatible avec l'existant (surtout pour les plugins),
- Même si l'handler est définie très tôt certaines erreurs risquent
d'être levées avant,
- Certaines erreurs ne peuvent pas être loguées en base car appelées
trop tôt ou dû à la base,
- Pas forcément possible d'utiliser des plugins pour les même raisons
Pour l'instant je n'ai rien coder, je fouille un peu partout pour voir
ce qu'il se fait, si vous avez des avis/idées je suis preneur !
Cordialement,
JC|au chaud
10 years, 9 months
[mise à jour des versions de dev] WTF ?
by philippe＠dissitou.org
Je ne sais pas vous, mais je trouvé dérangeant que la branche 2.6 ne
comporte pas les dernières mises à jour apportées sur la branche 2.5.x
En effet, depuis la version 2.5.1, pour suivre le développement au
jour le jour sur une installation de test, on est forcé de tester sur
deux installations indépendantes : une sur la branche testing, l'autre
sur unstable. (ou alors je n'ai pas tout compris, ce qui est fort
probable)
Pas glop pour les vieux comme moi qui ont mis des heures d'arrachage
de cheveux pour passer de SVN à Mercurial (et encore, je n'ai pas de
clone local et je pushe donc toujours directement sur défault sur
hg.dotclear.org parce que les fous de la team m'ont donné les clés un
jour de beuverie ^^)
Auparavant, si on mettait à jour avec la version unstable, on avait
aussi les modifs de la branche testing, c'était trop simple ?
Du coup j'ai une version testing en ligne et une unstable en local,
sans autre coordination que manuelle et fastidieuse, et si je veux
faire des modifs (rassurez-vous, je ne touche guère qu'à la doc ;)) je
ne sais pas où les faire ni surtout où ça va finir, et vous serez
probablement obligés de faire le ménage après moi :P
--
Philippe
10 years, 9 months
Réunion IRC Code
by Franck Paul
'jour les gens,
Ce soir y'a … réunion :-)
Dites, est-ce que ça conviendrait à tout le monde si on déplaçait la
réunion à 22h, plutôt qu'à 20h ?
Au menu (rapide) :
1. version 2.5.3
2
. version 2.6
3. README + CONTRIBUTING
4. workflow
5. questions diverses
S
i besoin on reportera à la semaine prochaine certains des points, nous ne
sommes pas dans une période "critique", c'est-à-dire à quelques jours
d
'une release.
À ce soir
--
Franck
10 years, 9 months
[dev][clearbricks] Le déba(t|llage)
by Denis Jean-Christian
Bonjour, bonsoir,
J'ai vu plusieurs PR, messages, etc, parlant de fonctions à remplacer
dans Clearbricks par leurs pendant en PHP natif, je souhaiterais lancer
un grande (ou pas) discussion qui je le pense va être mouvementée, mais
c'est le but.
Voici mes premières questions :
1) Quelle est politique à propos de Clearbricks, a-t-on les pleins
pouvoir sur la branche default, car bien que essentiellement utilisée et
hébergée (tout comme) par Dotclear, elle n'en fait pas vraiment partie
et d'autres personnes l'utilisent.
2) L'avantage de Clearbricks est qu'elle fonctionne sur quasi tous les
serveurs, c'était d'ailleurs son but premier. Le temps de retard qu'elle
a par rapport aux innovations PHP n'est-elle pas un avantage ? (hormis
les deprecated comme modifier PCRE \e, mysql vs mysqli, etc)
3) Des messages sont également passés disant "la suite c'est de s'en
séparer", bon OK je sais que, hum, non. z'en pensez ?
D'autres questions peuvent suivre, c'est ouvert :-)
Cordialement,
JcDenis
10 years, 9 months
