Comptes WordPress

Extension payante. Un formulaire peut créer un compte WordPress à partir d’une soumission, ou mettre à jour celui du visiteur connecté. Adhésions, formations, portails clients, inscriptions payantes.

Ce document décrit ce que le module garantit et ce qu’il refuse. Le guide utilisateur en donne la version courte, dans la section « Créer des comptes de membre ».

Le principe

Le réglage vit dans les réglages du formulaire, sous user_account. Il n’y a pas de table de configuration : un formulaire exporté puis réimporté emporte son action de compte, et un formulaire dupliqué la duplique.

{
  "user_account": {
    "enabled": true,
    "mode": "create",
    "email_field": "email_1",
    "role": "subscriber",
    "profile": {
      "first_name": "name_1_first",
      "last_name": "name_1_last",
      "display_name": "name_1_first"
    },
    "meta": [
      { "key": "membership_number", "field": "text_4" }
    ],
    "send_password_setup": true
  }
}

Une référence désigne un champ — email_1 — ou l’une de ses parties pour les champs composites — name_1_first, address_1_postal_code.

Les deux modes, et celui qui manque

create crée un compte. update_current met à jour celui du visiteur connecté, et lui seul.

Le troisième mode auquel on pense — retrouver un compte par son adresse sur un formulaire anonyme — n’existe pas, et son absence est une décision. Il suffirait de connaître l’adresse d’un tiers pour réécrire son profil : c’est une prise de compte, pas une mise à jour.

En mise à jour, l’identifiant vient toujours de la session. Masquer le formulaire aux visiteurs anonymes ne protège rien, puisqu’une requête forgée ne passe pas par l’affichage ; la règle d’accès « Connexion requise » est une courtoisie, la vérification côté serveur est le contrôle.

Aucun mot de passe ne passe par le formulaire

Le compte naît avec wp_generate_password(), un secret que personne ne lit — pas même le code qui le fabrique, qui le passe directement à wp_insert_user(). Le membre reçoit ensuite le courriel standard de WordPress, avec un lien de définition à durée limitée.

Un champ « mot de passe » dans le formulaire aurait fait transiter le secret en clair dans la requête, dans les journaux du serveur et, pour un formulaire mal réglé, dans la notification envoyée à l’administrateur.

Si l’envoi échoue, le compte reste créé : le défaire conduirait l’administrateur à en créer un second. Le motif mail_failed s’inscrit dans l’audit, et une réinitialisation manuelle suffit.

Le rôle, et les deux garde-fous

Par défaut, seul subscriber est attribuable. Ouvrir la liste demande du code :

add_filter(
	'solis_forms_pro_allowed_registration_roles',
	static fn ( array $roles ): array => array_merge( $roles, array( 'membre' ) )
);

Un second contrôle s’applique après ce filtre : un rôle portant une capacité de reprise du site est écarté même s’il a été explicitement autorisé — manage_options, edit_users, install_plugins, unfiltered_html, solis_forms_manage_settings et quelques autres. administrator est refusé nommément en plus de ce contrôle.

La raison n’est pas la malveillance de l’administrateur, c’est sa méprise : un rôle « Gestionnaire » créé par une extension tierce peut porter edit_users sans que son nom le laisse deviner, et le formulaire qui l’attribue ressemble à tous les autres.

Un rôle configuré hors de cette liste ne retombe pas silencieusement sur subscriber : l’action entière est refusée, parce qu’un réglage qui dit autre chose que ce qui sera fait est pire qu’un réglage inopérant.

Les métadonnées

Les clés sont contrôlées avant écriture. Sont refusées :

celles qui commencent par un tiret bas, convention WordPress pour « interne » ;
celles qui commencent par wp_, par le préfixe de tables du site ou par celui du réseau — sur un site dont les tables s’appellent monsite_, les capacités se rangent sous monsite_capabilities, et sur le deuxième site d’un réseau sous wp_2_capabilities ;
capabilities, user_level, session_tokens, role, user_pass, user_login, user_email et quelques autres, ainsi que tout ce qui se termine par _capabilities ou _user_level ;
celles dont la forme sort de [A-Za-z][A-Za-z0-9_-]*.

Côté profil, la liste est blanche et non noire : seuls first_name, last_name et display_name s’écrivent. Énumérer ce qui est permis fait que l’oubli ferme au lieu d’ouvrir.

user_email n’y figure pas. Changer l’adresse d’un compte existant demande une confirmation sur l’ancienne adresse, faute de quoi il suffit d’un formulaire pour détourner un compte ; c’est hors du périmètre de cette version.

Une adresse déjà prise

La création échoue, la soumission reste enregistrée, et le visiteur n’apprend rien. La confirmation du formulaire est celle qu’il aurait eue de toute façon.

Ce silence est le point le plus délicat du module. Répondre « cette adresse a déjà un compte » répondrait à la question « cette personne est-elle inscrite ici ? » pour n’importe quelle adresse qu’on voudrait essayer, une à la fois. Le motif email_taken s’inscrit dans l’audit, que seul un administrateur consulte.

C’est aussi pourquoi ce module ne s’abonne pas à solis_forms_submission_errors, contrairement au paiement ou à la checklist : une erreur y serait affichée au visiteur.

Au plus un compte par soumission

La clé primaire de la table d’audit est l’identifiant de la soumission. Deux opérations pour une même entrée sont structurellement impossibles, et une soumission rejouée ne crée pas de doublon ni ne renvoie le courriel.

Si une panne survenait entre la création du compte et l’écriture de l’audit, la reprise retrouve le compte par une méta interne posée sur lui, _solis_forms_account_entry, jamais par l’adresse : deux personnes peuvent partager une adresse de service, et un homonyme ne doit pas se voir rattacher la demande d’un autre. Le tiret bas initial met cette méta hors de portée du mapping.

Paiement

Le compte naît sur solis_forms_entry_created, en priorité 8 — après le rattachement du règlement, en priorité 5.

L’essentiel tient toutefois ailleurs : une soumission payante dont le règlement n’est pas confirmé ne produit aucune entrée. Le garde de paiement répond sur solis_forms_submission_errors, bien avant l’enregistrement. Cet événement n’est donc atteint qu’avec un règlement vérifié ; l’ordre de priorité ne fait que l’inscrire dans le code.

Aucune création n’est déclenchée directement par un webhook de passerelle.

Ce que l’audit conserve

Le mode, le statut, l’identifiant du compte, le rôle, le motif, les destinations écrites, la date. Jamais le mot de passe, jamais le jeton de réinitialisation, jamais l’adresse, et jamais les valeurs écrites — seulement où elles l’ont été.

Les anciennes valeurs d’un profil mis à jour ne sont pas conservées non plus : elles constitueraient un historique de données personnelles que le membre croit avoir corrigées.

Les motifs sont des codes — email_taken, not_logged_in — traduits à l’affichage. Y écrire le message de WordPress figerait une langue en base et y ferait entrer l’adresse qui l’a déclenché.

La suppression

Supprimer une soumission efface sa trace d’audit et sa note. Le compte WordPress survit. Le membre s’est connecté, a peut-être commandé, figure peut-être dans un autre formulaire : il n’appartient pas à l’entrée qui l’a fait naître, et une suppression en cascade serait une surprise sans retour.

La suppression d’un compte relève de l’administration des utilisateurs de WordPress, et de la politique de rétention du site.

Ce que le module ne fait pas

Ni connexion sociale, ni SSO, ni MFA, ni annuaire LDAP, ni groupes. Ni changement d’adresse, ni fusion de comptes, ni suppression de compte, ni création de rôles, ni attribution de plusieurs rôles. Ni approbation manuelle : une activation différée demande un état de membre distinct, et l’ajouter à moitié laisserait des comptes dans un entre-deux que rien ne décrit.

Un visiteur déjà connecté qui remplit un formulaire de création n’obtient pas un second compte : sa soumission est rattachée à celui qu’il a.

Droits

La configuration exige solis_forms_manage_forms. Le bloc d’audit suit solis_forms_view_entries et les règles d’accès au formulaire. Le lien vers la fiche du membre n’apparaît qu’à qui peut la modifier.