Préremplissage dynamique

Extension payante. Un formulaire peut arriver déjà rempli : depuis le compte connecté, un paramètre d’URL déclaré, une valeur fixe ou une source métier branchée par filtre PHP.

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 « Arriver avec le formulaire déjà rempli ».

Le navigateur ne choisit jamais une donnée protégée

C’est la décision qui commande tout le reste. Chaque valeur vient d’une source que le serveur lit lui-même, et la seule que le visiteur contrôle — l’URL — est la plus encadrée.

Les cinq sources

• Profil du compte connecté : prénom, nom, nom affiché, adresse. Quatre propriétés, et pas une de plus. Ouvrir la liste à n’importe quelle propriété de WP_User laisserait préremplir un mot de passe haché ou une clé d’activation — des champs qui existent sur l’objet et qu’on n’imagine pas en écrivant la règle.
• Métadonnée du compte connecté, sous les mêmes refus que l’écriture : ni préfixe wp_, ni clé de capacités, ni jeton de session.
• Paramètre d’URL, sous un nom déclaré dans le réglage.
• Valeur fixe, écrite dans le réglage.
• Filtre PHP, pour une source propre au site.

Aucune source ne va chercher une donnée ailleurs au moment du rendu. Une requête sortante déclenchée par l’affichage d’un formulaire public serait une porte ouverte : l’adresse viendrait d’un réglage, la réponse entrerait dans la page, et le temps de rendu dépendrait d’un tiers.

Le compte lu est celui de la session

Le résolveur n’a pas de paramètre d’utilisateur : il appelle get_current_user_id() lui-même. En accepter un depuis un réglage ou une URL aurait suffi à afficher le profil d’autrui dans un formulaire public — et la tentation d’ajouter « juste pour les administrateurs » serait venue ensuite.

Un visiteur non connecté n’obtient rien des sources de compte. Ce n’est pas une erreur, c’est l’absence de donnée : le champ reste vide et le formulaire reste utilisable.

La clé d’URL est nommée, et distincte du champ

Un paramètre nommé prenom ne remplit pas le champ prenom : il faut qu’une règle déclare explicitement « le champ prenom se remplit depuis le paramètre code ». Sans ce nommage, tout champ deviendrait remplissable par une adresse forgée.

La valeur est bornée à deux cents caractères et passe par la sanitation du type de champ. Un paramètre d’URL se partage, se met en favori, s’indexe et apparaît dans les journaux : rien de confidentiel ne doit y passer.

Ce qu’aucune règle ne peut viser

Mot de passe, paiement, fichier, signature — et tout ce que le cœur déclare sensible.

• Préremplir un secret le ferait apparaître dans une page, donc dans un cache, un historique, une capture d’écran.
• Le montant d’un paiement est décidé par le serveur au moment de régler ; l’imposer depuis une URL reviendrait à laisser choisir ce qu’on paie.
• Aucune valeur préremplie ne correspond à un fichier ni à une signature : un chemin injecté désignerait un fichier du serveur, et un tracé prérempli serait une signature que personne n’a tracée.

Le verrouillage

Un champ verrouillé s’affiche en lecture seule — readonly, non disabled : un champ désactivé n’est pas envoyé du tout, et le serveur recevrait une valeur vide là où il attend celle qu’il a décidée.

Le verrou visible n’est pas la garantie. Ce qu’un navigateur affiche se change. La garantie est que le serveur réécrit la valeur d’un champ verrouillé à la soumission, avant la validation — la valeur réimposée suit donc exactement le même chemin qu’une saisie, et ne contourne aucun contrôle.

Réécrire plutôt que refuser : refuser punirait quelqu’un dont la page était simplement ouverte depuis longtemps, là où réécrire donne le résultat attendu.

Si la valeur n’est plus résoluble — le visiteur s’est déconnecté, le paramètre a disparu — le champ garde ce qu’il portait plutôt que d’être vidé : vider ferait échouer la validation d’un champ obligatoire sans que personne n’ait rien fait de mal.

Le verrou n’est offert que sur les champs de saisie libre. readonly n’a aucun effet sur une liste déroulante ni sur une case, et offrir un verrou qui ne verrouille rien serait pire que ne pas l’offrir.

Le filtre PHP

add_filter(
	'solis_forms_pro_prefill_value',
	static function ( string $valeur, string $cle, string $champ ): string {
		return 'numero_dossier' === $cle ? mon_numero_de_dossier() : $valeur;
	},
	10,
	3
);

Le filtre reçoit la clé déclarée, le champ visé et le formulaire. Ce qu’il rend passe ensuite par la sanitation du champ, comme tout le reste. C’est le seul endroit prévu pour brancher une source propre au site : il vit dans le code, sous la responsabilité de qui l’écrit.

Les lignes répétables

Le serveur remplit ce qui existe au moment du rendu. Une ligne ajoutée ensuite n’existait pas, et le répéteur la vide en la clonant : le module frontal y recopie alors ce que le serveur avait mis dans la première.

Il relève cette valeur au chargement, avant toute frappe. La relever plus tard recopierait la saisie du visiteur dans les lignes suivantes, ce que personne n’a demandé. Il ne lit ni URL, ni compte, ni réglage : une valeur que le navigateur choisirait ne serait pas un préremplissage mais une saisie déguisée.

Ce que le module ne fait pas

Ni requête REST arbitraire, ni connecteur CRM, ni écriture inverse vers le profil, ni lecture d’une soumission d’autrui, ni secret transporté par une URL.