Dans une installation WordPress standard, de nombreux fichiers PHP remplissent des fonctions essentielles, mais souvent méconnues. Parmi eux, wp-signup.php se distingue par son rôle spécifique dans le fonctionnement des réseaux multisites. Si vous administrez un WordPress en mode multisite, ce fichier est incontournable. Pourtant, il reste souvent mal compris, voire mal protégé. Dans cet article, nous allons explorer la fonction précise de wp-signup.php, dans quel contexte il est utilisé, comment il interagit avec le réseau multisite, et enfin, comment sécuriser ou désactiver son accès dans des environnements qui n’en ont pas besoin.

Origine et rôle du fichier wp-signup.php de WordPress

Le fichier wp-signup.php est directement issu de l’héritage de WordPress MU (Multi-User), un fork officiel de WordPress lancé en 2005, destiné à la gestion de réseaux de blogs. WordPress MU permettait à une seule instance WordPress d’héberger plusieurs sites — fonctionnalité aujourd’hui connue sous le nom de « multisite ». Pendant des années, WordPress MU et WordPress classique ont évolué en parallèle, jusqu’à leur fusion complète dans la version WordPress 3.0, publiée en juin 2010. À partir de cette version, toutes les fonctionnalités multisites ont été intégrées nativement dans WordPress, mais restent désactivées par défaut. Pour activer le multisite, il est nécessaire d’ajouter la constante suivante dans le fichier wp-config.php :

define( 'WP_ALLOW_MULTISITE', true );

Une fois le mode multisite activé, WordPress crée automatiquement une arborescence réseau avec un site principal (site_id = 1), un super administrateur, une gestion centralisée des sites, et un ensemble de fichiers spécialisés, dont wp-signup.php.

Le rôle de wp-signup.php est précis : il orchestre l’inscription d’utilisateurs et/ou de nouveaux sites (blogs) dans un réseau multisite. Il s’agit d’un endpoint public qui fournit un formulaire d’enregistrement et qui gère la logique de validation, de confirmation par e-mail et de création différée via activation. Concrètement, il prend en charge plusieurs tâches clés :

• Création d’un compte utilisateur : si le réseau autorise les inscriptions ouvertes, un nouvel utilisateur peut s’enregistrer via ce fichier, avec un e-mail et un nom d’utilisateur.
• Création d’un site : si l’option « permettre la création de sites » est activée dans les paramètres réseau, les utilisateurs (connectés ou non) peuvent créer leur propre site (avec sous-domaine ou sous-dossier selon la configuration).
• Affichage dynamique du formulaire : le formulaire affiché par wp-signup.php est adaptatif : il varie selon que l’utilisateur est connecté, selon les options du réseau, et selon les personnalisations ajoutées via des hooks (show_user_form, show_blog_form, etc.).
• Gestion du double opt-in : après soumission du formulaire, l’utilisateur reçoit un e-mail contenant un lien vers wp-activate.php. Ce mécanisme de confirmation est obligatoire dans WordPress multisite et empêche la création automatique de comptes non validés.
• Stockage dans la table wp_signups : les données saisies sont temporairement enregistrées dans la table wp_signups en attendant leur activation. Ce stockage intermédiaire permet une vérification préalable avant toute insertion définitive dans wp_users et wp_blogs.

Ce fichier est donc spécifiquement conçu pour les réseaux WordPress multisite. Il est inactif sur une installation WordPress standard (non multisite). Dans ce cas, une tentative d’accès à wp-signup.php entraînera :

• soit une redirection vers la page d’accueil,
• soit l’affichage d’un message d’erreur : Multisite support is not enabled.

Techniquement, cette restriction est assurée par la condition is_multisite() dès le début du fichier, empêchant toute utilisation hors contexte. Cela signifie que son exécution ne peut se faire qu’une fois la structure multisite activée dans le système, avec le fichier .htaccess configuré pour router correctement les requêtes vers les sous-sites. Le fichier est situé à la racine du CMS WordPress, au même niveau que d’autres fichiers de gestion des sessions utilisateurs, comme wp-login.php, wp-register.php (obsolète) et wp-activate.php. Mais à la différence de ces fichiers plus génériques, wp-signup.php ne traite que les demandes d’enregistrement dans un contexte réseau.

Il constitue donc un point d’entrée stratégique pour toutes les plateformes WordPress mutualisées qui souhaitent permettre à des tiers de créer des comptes et/ou des blogs. Des exemples typiques incluent des réseaux de blogs universitaires, des hébergements de blogs communautaires (comme WordPress.com), ou encore des extranets modulaires organisés en sous-sites autonomes.

L’analyse du fichier wp-signup.php ligne par ligne

Le fichier wp-signup.php est conçu pour gérer les inscriptions dans un réseau multisite WordPress. Il s’exécute uniquement si le mode multisite est activé et propose un formulaire de création de compte, de site, ou les deux. Voici une explication détaillée des blocs de code qui le composent, telle qu’on les trouve dans une version standard de WordPress.

1. Le chargement de l’environnement et vérification multisite

require_once( dirname( __FILE__ ) . '/wp-load.php' );

require_once( ABSPATH . WPINC . '/ms-functions.php' );

if ( ! is_multisite() ) {
    wp_die( __( 'Multisite support is not enabled.' ) );
}

Le fichier commence par inclure wp-load.php, ce qui initialise l’environnement WordPress (déclaration des constantes, base de données, hooks, etc.). Ensuite, il charge ms-functions.php, qui contient toutes les fonctions utiles au mode multisite. Enfin, une vérification est faite avec is_multisite() : si le réseau n’est pas activé, le script est stoppé via wp_die(), ce qui protège l’exécution de code non pertinent en contexte monosite.

2. Le chargement des styles et hooks initiaux

add_action( 'wp_head', 'signup_header' );

Cette ligne utilise le système de hooks de WordPress pour injecter une fonction personnalisée signup_header dans le <head> du document HTML. Elle permet de personnaliser l’en-tête de la page d’inscription (ex. : ajouter du CSS ou des balises meta spécifiques à l’environnement réseau).

3. La détection du contexte utilisateur

$active_signup = get_site_option( 'registration' );

WordPress détermine ici quel type d’inscription est autorisé : uniquement les utilisateurs, uniquement les sites, ou les deux. Cette information est stockée dans l’option réseau registration. Elle est essentielle pour afficher dynamiquement le bon formulaire et orienter le traitement du formulaire soumis.

4. La gestion de l’état de connexion

$current_user = wp_get_current_user();

if ( $active_signup == 'all' || $active_signup == 'blog' ) {
    if ( is_user_logged_in() ) {
        signup_another_blog( $current_user );
    } else {
        signup_user_blog();
    }
} elseif ( $active_signup == 'user' ) {
    signup_user();
}

Ce bloc est central : il conditionne l’affichage du formulaire selon que l’utilisateur est connecté ou non, et selon les règles d’inscription définies par l’administrateur réseau :

• signup_user() affiche le formulaire de création de compte utilisateur
• signup_another_blog() permet à un utilisateur connecté d’ajouter un site
• signup_user_blog() propose un double formulaire pour créer à la fois un compte utilisateur et un site

Ces fonctions sont définies dans ms-functions.php et utilisent des fonctions de validation comme wpmu_validate_user_signup() et wpmu_validate_blog_signup().

5. L’affichage du formulaire d’inscription

do_action( 'before_signup_form' ); ?php do_action( 'after_signup_form' );

Avant et après le formulaire HTML, des hooks (before_signup_form et after_signup_form) sont proposés pour permettre aux développeurs de modifier ou enrichir l’interface (ajout de reCAPTCHA, termes et conditions, validation JS, etc.). Le contenu exact du formulaire dépend de la fonction d’inscription invoquée.

Avant et après le formulaire HTML, des hooks comme before_signup_form et after_signup_form sont appelés. Ces points d’ancrage permettent aux développeurs de modifier ou d’enrichir l’interface du formulaire, par exemple pour ajouter un champ reCAPTCHA, un encadré RGPD, des validations JavaScript ou encore des messages personnalisés. Le contenu du formulaire dépend de la fonction invoquée (signup_user(), signup_user_blog(), etc.) et de la configuration du réseau multisite.

6. Le traitement de la soumission du formulaire

Lorsque l’utilisateur soumet le formulaire, le script détecte une requête HTTP de type POST. WordPress procède alors à la validation des champs à l’aide de fonctions spécifiques du fichier ms-functions.php :

• wpmu_validate_user_signup() vérifie que le nom d’utilisateur et l’adresse e-mail sont valides, disponibles et conformes aux restrictions éventuelles du réseau (blacklist, format, domaine autorisé, etc.).
• wpmu_validate_blog_signup() est utilisée en complément lorsque le formulaire permet également la création d’un site. Elle valide le nom du site (préfixe de sous-domaine ou sous-répertoire), le titre du site et les champs associés.

Si la validation est positive, les données sont enregistrées temporairement dans la base de données, plus précisément dans la table wp_signups. Cette table contient :

• l’identifiant proposé,
• l’adresse e-mail,
• les méta-informations (nom du site, titre),
• une clé unique d’activation,
• la date de soumission,
• et l’état de l’inscription (active ou en attente).

Cette inscription n’est pas immédiatement finalisée. WordPress envoie ensuite un e-mail de confirmation contenant un lien sécurisé vers wp-activate.php. L’utilisateur doit cliquer sur ce lien pour confirmer son inscription (double opt-in), ce qui évite les enregistrements frauduleux et garantit que l’adresse e-mail fournie est bien accessible.

7. L’activation et la finalisation de l’inscription

Le lien reçu par e-mail contient une clé générée aléatoirement et stockée dans wp_signups. Lorsqu’un utilisateur clique dessus, le fichier wp-activate.php traite cette clé, vérifie sa validité, puis appelle les fonctions wpmu_activate_signup() ou wpmu_activate_blog() selon le cas.

Ces fonctions transfèrent définitivement les données de wp_signups vers les tables wp_users (pour les comptes) et wp_blogs / wp_site (pour les sites), tout en envoyant les e-mails de bienvenue ou de confirmation, selon la configuration du réseau. Le compte est alors actif et utilisable.

8. Les points d’extension via hooks

Le fichier wp-signup.php propose de nombreux hooks permettant aux développeurs d’ajouter ou de modifier des comportements sans toucher au cœur du CMS :

• signup_header : pour injecter du code dans l’en-tête HTML (par exemple du CSS ou du JavaScript)
• before_signup_form / after_signup_form : pour ajouter des éléments autour du formulaire (avis légal, encadré RGPD, messages personnalisés)
• show_user_form et show_blog_form : pour modifier ou enrichir les champs de formulaire existants
• signup_finished : pour afficher un message ou rediriger l’utilisateur après la soumission

Ces points d’extension sont essentiels dans une logique multisite publique, où chaque réseau peut avoir des besoins spécifiques (restreindre certains domaines, filtrer par pays, interdire certains préfixes de site, etc.).

9. Résumé du flux de wp-signup.php

Pour résumer, voici le cycle complet de fonctionnement de wp-signup.php dans un réseau multisite :

1. Un visiteur accède à /wp-signup.php.
2. Le fichier vérifie que l’installation est bien en mode multisite.
3. Il détecte les options d’inscription activées dans le réseau (utilisateur, site ou les deux).
4. Il affiche dynamiquement le bon formulaire.
5. Si le formulaire est soumis, les données sont validées.
6. Si tout est conforme, les informations sont enregistrées dans wp_signups.
7. Un e-mail est envoyé avec un lien vers wp-activate.php.
8. L’utilisateur clique sur le lien pour activer son compte et/ou son site.
9. Le réseau active définitivement le profil et affiche une confirmation.

Grâce à cette architecture modulaire, wp-signup.php permet à WordPress multisite de fonctionner comme une véritable plateforme de création de comptes et de sites, à l’image de WordPress.com ou de réseaux académiques, professionnels ou communautaires.

La sécurité et le contrôle d’accès à wp-signup.php

Comme tout fichier accessible publiquement à la racine d’une installation WordPress ainsi que xmlrpc ou encore wp-trackback, wp-signup.php représente un point d’entrée potentiel pour des abus si aucune mesure de sécurité n’est mise en place. Ce risque est d’autant plus important dans un environnement multisite où les inscriptions sont ouvertes à tous. Voici les principaux scénarios de menace, ainsi que les bonnes pratiques pour sécuriser efficacement ce fichier.

1. Risque de spam utilisateur ou de création massive de sites

Lorsqu’un réseau multisite autorise l’inscription libre de nouveaux utilisateurs ou la création automatique de sites, wp-signup.php devient une cible pour les bots. Ces scripts peuvent envoyer des milliers de requêtes POST pour créer des comptes avec des adresses e-mail jetables ou des noms de domaines suspects, saturant la base de données et polluant le réseau avec des sites inactifs ou malveillants.

Voici plusieurs mesures pour limiter ce risque :

• Installer un plugin de sécurité ou d’antispam tel que Antispam Bee, Wordfence ou CleanTalk, capables de filtrer ou bloquer automatiquement les requêtes suspectes sur les formulaires publics.
• Ajouter un reCAPTCHA Google ou une question de validation personnalisée dans le formulaire d’inscription, en utilisant un plugin compatible avec le multisite (ex. : Advanced Google reCAPTCHA).
• Limiter les notifications automatiques pour éviter les abus ou le spam par e-mail, via ce filtre :

  add_filter( 'wpmu_signup_user_notification', '__return_false' );

  Cela empêche WordPress d’envoyer automatiquement un e-mail à chaque tentative d’inscription (à n’activer que si vous avez mis en place une validation manuelle).

2. Restreindre l’accès aux inscriptions via les réglages réseau

Depuis l’interface d’administration réseau (/wp-admin/network/settings.php), WordPress propose plusieurs options permettant de restreindre ou conditionner l’usage de wp-signup.php. Ces paramètres affectent directement le comportement du formulaire d’inscription et la logique d’activation.

Voici les réglages recommandés :

• Désactiver l’inscription de nouveaux utilisateurs si le réseau est privé ou destiné à une organisation fermée.
• Interdire la création automatique de sites sauf pour les administrateurs réseau ou les utilisateurs approuvés.
• Restreindre les domaines autorisés pour les e-mails d’inscription (ex. : uniquement @mon-entreprise.fr).
• Bloquer certains préfixes de sites ou noms réservés (ex. : admin, test, demo) via la liste noire.

Ces restrictions se configurent sans code, directement depuis l’administration du réseau, et permettent de mieux encadrer les usages de wp-signup.php.

3. Blocage via le serveur si wp-signup.php n’est pas utilisé

Si votre réseau n’a pas besoin de laisser les inscriptions publiques actives — par exemple dans un environnement d’intranet, d’école ou de groupe privé — il est judicieux de bloquer complètement l’accès à wp-signup.php. Ce blocage se fait au niveau du serveur web, ce qui est à la fois performant et sécurisé, car cela évite que WordPress n’ait à interpréter la requête.

Apache (.htaccess)

<Files "wp-signup.php">
  Order allow,deny
  Deny from all
</Files>

Ce bloc à placer dans le fichier .htaccess interdit purement et simplement l’accès HTTP à wp-signup.php. Toute tentative d’accès renverra une erreur 403, ce qui stoppe l’exécution du fichier dès la couche serveur.

Nginx

location = /wp-signup.php {
  deny all;
  access_log off;
  log_not_found off;
}

La directive Nginx ci-dessus a le même effet que la règle Apache : elle bloque l’accès, évite l’enregistrement inutile dans les logs et allège les traitements côté serveur.

Ce type de blocage est recommandé dans les cas suivants :

• Vous utilisez un multisite fermé, uniquement pour des utilisateurs internes.
• Vous créez manuellement les comptes et les sites depuis l’administration réseau.
• Vous souhaitez limiter votre surface d’attaque aux seules fonctionnalités réellement utilisées.

Dans tout environnement multisite, le fichier wp-signup.php doit faire l’objet d’une évaluation spécifique. S’il est utile, il doit être renforcé avec des outils de contrôle et de filtrage. S’il ne l’est pas, il doit être désactivé proprement côté serveur. Cette approche permet de concilier flexibilité, sécurité et performance dans la gestion des inscriptions sur WordPress multisite.