afficher la config de réglage de l'unicité des réponses que si on aura réellement besoins (tous les traitements en PHP se basent sur le principe que le règlage par défaut = cookie, donc c'est bon normalement)

encore un peu plus de séparation en fieldset dans la config des enregistrements + un changement de label + deux / trois broutilles de mise en forme

ne pas proposer de ne pas stocker l'id_auteur si jamais on utilise l'id_auteur pour identifier une réponse et qu'en plus on a besoin d'identifer une réponse

en r112879 je disais "compatibilité assuré pour les gens qui auraient modifié les variables globales". C'était faux. Maintenant c'est vrai

Etape 5 : avoir une fonction qui trouve la réponse d'une personne à un formulaire tenant compte du choix principal d'identification des réponses

Etape 4: lorsqu'on teste le droit de poster une réponse, tester en prenant en compte les paramètres d'identification de la réponse

dire supprimer l'id_auteur

Etape 2: séparer clairement l'id_auteur de la variable php d'identification + migrer les données et traitements existants

problème indépendant de la conservation de l'identifiant auteur.

On sépare donc cela.
Première étape : séparation dans l'espace de config.

Dans formidable, on n'appelle pas en squelette le chemin des fichiers
mais via formidable_generer_chemin_fichier().
Si les personnes surchages dans leur mes_options cela ne change rien.

Si les gens font des #EVAL{_DIR_FICHIERS_FORMIDABLE}, et bien c'est mal.
Ils sauront qu'il faut utiliser formidable_generer_chemin_fichier(), et
ils pourront rustiner en definissant eux mêmes les constantes.

on conditionne au fait qu'on teste l'unicité d'un champ

mettre la case rafraichir le cache avant affichage résumé de la réponse, juste pour des raisons esthétiques

- Réglages généraux
- Données personnelles
- Divers

Etape 1 : ordonner les champs

label + explication pour la variable d'anonymisation + pas besoin d'une chaine de langue pour l'intro du select (surtout avec un nom absolument pas explicite)

identification ne sert pas que pour la modification des réponses, mais aussi pour interdire les réponses multiple, on reformule la chaîne de langue.

1. n'était utilisé que deux fois
2. était redondante avec le système d'afficher_si utilisé partout ailleurs (car fournit par saisie)
3. en plus n'était pas à bon escient (cf prochain commit)

tout ceci nous permet de supprimer formidable_options, et donc d'economiser à chaque hit. Cela mérite bien un +1 sur y

éviter de mettre une définition  dans un options, lorsque la valeur n'est utilisé que dans une fonction. Autant définir dans ce cas dans la fonction

- code plus clair en évitant de créer des variables juste pour inverser le résultat d'un test, et pour recopier la valeur d'une variable sans la modifier après (!)
- plus de variables globales pour modifier un réglage (qui de toute facon
aurait du passer plutot par un pipeline dédiée)
- limiter les cas d'appel a eval()

Compatibilité assuré pour les quelques personnes qui auraient modifiés
ces variables globales (mais qui?)

pas besoin de définir les constante dans un fichier d'options, ne le définir que lorsqu'on s'en sert