Les deux cases "pétition" et "forum" dans la marge (nouveautés beta22 et
beta23) sont trop grosses : ça devrait être quelques chose de bcp plus
discret, car ça va servir très rarement. Peut-être les mettre dans une case
unique, et remplacer
PÉTITION
Cet article est une pétition
Cet article ne propose pas de pétition
Changer
FORUM POUR CET ARTICLE
Article avec forum (fonctionnement normal)
Ne pas afficher de forum pour cet article.
Changer
par :
INTERACTIF
Forum: () oui (x) site () non [aide]
Pétition: [ ] [aide]
ou le choix "site" correspond au choix par défaut réglé dans "Configuration
précise" ? et "pétition" est une case à cocher/décocher oui/non
ou unifier graphiquement ainsi
INTERACTIF
Forum: () oui (x) site () non [aide]
Pétition: () oui (x) non [aide]
Hé, qu'est-ce que tu crois, le Arno des fois il pense: quand tu désactives les forums, l'encadré disparaît
Mais si on propose la possibilité de réactiver les forums pour un article spécifique, ben il reviendra (p'têt avec une formulation différente)...
Le pseudo-tag qui s'occupe de tout est: #FORMULAIRE_INSCRIPTION
C'est pas bien compliqué (en espérant que ça fonctionne bien...): on indique son pseudo et son email, et ça envoie le code de connexion par mail. Du coup, j'ai modifié la page "A suivre" de l'espace privé, qui propose un lien "Informations personnelles" (colonne de gauche) où le rédacteur pourra compléter ses informations personnelles et, éventuellement, changer son mot de passe (il ne peut pas, en revanche, changer son adresse email).
Tout cela mériterait d'être testé, vu que c'est assez lourdingue comme modifs et que ça touche à des points sensibles (création des accès protégés).
J'ai cependant un problème (un recul par rapport à la version d'uZine actuelle): que faire quand le rédacteur a oublié son mot de passe (et a perdu le mail d'information)? Avant, je me contentais de renvoyer le mail en tirant les infos de la base. La solution: "il suffit de créer un nouveau mot de passe et de l'envoyer à nouveau par mail" n'est pas satisfaisante: n'importe qui pourrait en effet changer le mot de passe d'un autre utilisateur régulièrement, et ainsi lui pourrir la vie (bien sûr, l'autre recevrait ça par mail, m'enfin c'est la plaie...).
Tout cela mériterait d'être testé, vu que c'est assez lourdingue
comme modifs et que ça touche à des points sensibles (création des
accès protégés).
Oui, ce serait sympa de tester vu qu'à vue de nez, ça doit foirer
à certains endroits (login en double par exemple). Et puis éviter
les variables globales qui ne servent à rien (global $compteur
pour gérer les doublons de logins alors qu'un while() suffirait).
D'autre part :
- ce serait bien de factoriser les fonctions : quel intérêt de
recopier deux fois le code de chargement http (appelé "testersipage"
à un endroit et "TesterPage" à un autre) ? De plus, à vue de nez,
toute page contenant la chaîne "302" sera rejetée.
- appeler "erreur" une fonction spécifique au refus d'une signature
de pétition, c'est pas très bien trouvé
La solution: "il suffit de
créer un nouveau mot de passe et de l'envoyer à nouveau par mail"
n'est pas satisfaisante: n'importe qui pourrait en effet changer le
mot de passe d'un autre utilisateur régulièrement, et ainsi lui
pourrir la vie
Mmmh, alors éventuellement rajouter un étage supplémentaire : envoyer
un mail de confirmation de demande de changement de mot de passe ;)))
Une nouvelle version... En fait j'ai simplement ajouté le
traitement des pétitions aux routines de sauvegarde et
restauration de la base. Il a fallu modifier légèrement
la structure des tables MySQL associées, donc il y a une
procédure d'upgrade de la base.
