Notre objectif est de mettre en place deux sites WordPress qui partageront les identifiants et les mêmes utilisateurs. Une fois qu’un utilisateur s’est abonné à un site Web, il peut accéder à l’autre site Web avec le même rôle et les mêmes capacités.

Pour atteindre cet objectif, nous devrions être en mesure de modifier le fichier de configuration WordPress et de mettre à jour des tables de la base de données. Une compréhension générale de l’architecture et de la structure de la base de données de WordPress est essentielle, ainsi qu’une connaissance de base du développement WordPress. Ne vous inquiétez pas si vous n’êtes pas un pro. Il vous suffit de suivre ces directives et de poser vos questions dans les commentaires.

Avant de commencer à coder, nous devons savoir où WordPress stocke les rôles et les capacités des utilisateurs. Donc, notre première étape est de plonger profondément dans les tables de la base de données.

Important : Ce qui suit ne fonctionnera pas dans l’environnement Kinsta car nous n’autorisons qu’une seule installation de WordPress pour chaque site (à moins que vous n’exécutiez la commande WordPress multisite). Il est peut-être possible de faire fonctionner cela sur notre plateforme, mais cela nécessiterait une installation ou un développement supplémentaire. Nous vous recommandons d’en discuter avec un développeur WordPress.

Données et Métadonnées Utilisateur

Par défaut, WordPress stocke les données relatives aux utilisateurs dans trois tableaux : {$pref}options, {$pref}users et {$pref}usermeta.

Lorsque nous travaillons sur de nouvelles installations WordPress, nous n’avons pas à nous soucier de la ligne {$pref}user_roles dans la table {$pref}options, car le champ option_value correspondant a toujours la même valeur. Nous devrions considérer cette ligne juste au cas où nous travaillerions sur des installations existantes où les rôles ou les capacités ont été modifiés.
Pas de souci à propos de la table {$pref}users, parce qu’elle stocke des données utilisateur basiques que nous ne modifierons pas lors du partage d’utilisateurs entre les sites Web.
La table {$pref}usermeta est la seule table que nous allons mettre à jour pour atteindre notre but.

Structure des tables users et usermeta

Structure des tables users et usermeta (source : Codex Database Description)

{$pref}usermeta stocke les métadonnées utilisateur dans des paires clé/valeur. Dans ce tableau, cinq lignes stockent les données que nous devons prendre en compte.

Cinq lignes dans la table usermeta stockent les données concernant les capacités de l'utilisateur, le niveau et les réglages du tableau de bord.

Cinq lignes dans la table usermeta stockent les données concernant les capacités de l’utilisateur, le niveau et les réglages du tableau de bord.

La première ligne a le champ meta_key défini sur {$pref}capabilities, et le champ meta_value correspondant est un tableau sérialisé contenant le rôle utilisateur. La deuxième ligne stocke le niveau utilisateur (notez que les niveaux utilisateur sont obsolètes depuis WordPress 3.0). Les trois autres lignes concernent les réglages du tableau de bord que nous n’aborderons pas dans cet article.
Le rôle, le niveau et les réglages de l’utilisateur sont spécifiques à l’installation de WordPress et sont identifiés par la même valeur $pref. C’est un élément d’information important lorsque notre objectif est de partager les utilisateurs entre des sites web, car nous devrons dupliquer ces lignes et modifier le champ meta_key en conséquence.

C’est tout ce que nous avons à savoir sur les tables d’utilisateurs lorsque nous voulons partager les identifiants et les utilisateurs entre les nouvelles installations WordPress. Lorsque nous travaillons sur des sites Web existants, nous devrions tenir compte du fait que de nombreuses extensions ajoutent des lignes supplémentaires à {$pref}usermeta, et nous pourrions être amenés à examiner plus en profondeur les tables de base de données.

Cela dit, en ce qui concerne les tables d’utilisateurs, nous pouvons faire un pas en avant. Maintenant nous devons définir deux constantes spécifiques dans le fichier wp-config.php.

Définition de Tables Utilisateur Personnalisées – Partager les Identifiants

WordPress nous permet de définir des tables personnalisées au lieu de {$pref}utilisateurs et {$pref}usermeta. Cela signifie que si deux (ou plusieurs) sites Web WordPress partagent une base de données nous pouvons définir les mêmes utilisateurs et tables usermeta pour tous. Par conséquent, tous les sites Web qui partagent ces tables partageront les mêmes utilisateurs.

Note : Afin de partager les mêmes utilisateurs et tables usermeta, les installations WordPress doivent partager la même base de données.

Il suffit de définir CUSTOM_USER_TABLE et CUSTOM_USER_META_TABLE dans le fichier wp-config.php, comme indiqué dans le code suivant :

// custom users and usermeta tables
define( 'CUSTOM_USER_TABLE', 'my_users_table' );
define( 'CUSTOM_USER_META_TABLE', 'my_usermeta_table' );
Remarque : Sur les sites Web existants, il est obligatoire de sauvegarder les installations WordPress avant d’apporter des modifications aux fichiers wp-config.php et aux tables de données.

Maintenant que nous savons ce qu’il faut faire, il est temps d’exécuter nos deux installations WordPress.

Installation de WordPress

Pour des raisons de commodité, je nommerai les dossiers racine de WordPress premier et second. first_ et second_ seront les préfixes respectifs de table.
Exécutons maintenant la première installation.

Dans cet exemple, nous avons défini le champ de préfixe de table sur first_

Dans cet exemple, nous avons défini le champ de préfixe de table sur first_

Note : Toutes les installations partageront une seule base de données, et nous devrons fournir à chaque installation un préfixe de table unique.

Lorsque le premier site WordPress est opérationnel, nous pouvons modifier son fichier de configuration. Ouvrez /first/wp-config.php et ajoutez les lignes suivantes au-dessus du commentaire « C’est tout, ne touchez pas à ce qui suit ! Bonne publication. »:

$table_prefix  = 'first_';

define('WP_DEBUG', true);
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// custom users and usermeta tables
define( 'CUSTOM_USER_TABLE', $table_prefix . 'users' );
define( 'CUSTOM_USER_META_TABLE', $table_prefix . 'usermeta' );

/* That's all, stop editing! Happy blogging. */

Nous avons activé le mode de débogage forçant WordPress à stocker les notices d’erreur et les avertissements dans le fichier debug.log (pour en savoir plus à ce sujet, voir Une vue en profondeur sur la façon de configurer WordPress).
Ensuite, nous avons défini les constantes CUSTOM_USER_TABLE et CUSTOM_USER_META_TABLE aux tables first_users et first_usermeta. De cette façon, nous ne changeons pas les réglages par défaut de WordPress.

Nous en avons fini avec la première installation. Ensuite, nous devons copier le fichier wp-config.php depuis le premier dossier d’installation et le coller dans le dossier racine de la deuxième installation. Prenez soin de changer la valeur $table_prefix en conséquence :

$table_prefix  = 'second_';

define('WP_DEBUG', true);
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// custom users and usermeta tables
define( 'CUSTOM_USER_TABLE', 'first_users' );
define( 'CUSTOM_USER_META_TABLE', 'first_usermeta' );

CUSTOM_USER_TABLE et CUSTOM_USER_META_TABLE sont définis sur les valeurs de la première installation : first_users et first_usermeta. C’est tout pour la première installation.

WordPress est au courant des utilisateurs existants et nous devrions définir une adresse e-mail inexistante pour l'utilisateur administrateur.

WordPress est au courant des utilisateurs existants et nous devrions définir une adresse e-mail inexistante pour l’utilisateur administrateur.

Lors de l’exécution de la deuxième installation, nous devrions définir une adresse e-mail inexistante pour l’utilisateur administrateur car WordPress trouve un certain nombre d’utilisateurs existants dans la table first_users.

WordPress crée un nom d'utilisateur administrateur pour la deuxième installation

WordPress crée un nom d’utilisateur administrateur pour la deuxième installation

Connectez-vous au deuxième panneau d’administration de l’installation en tant qu’administrateur et listez les utilisateurs de WordPress. Vous trouverez le nouvel utilisateur admin et tous les utilisateurs du premier site web (ce qui leur permet de partager leurs identifants). À ce stade, les utilisateurs d’un site ne pourront pas se connecter à l’autre site Web.

Les utilisateurs du second site n'hériteront pas de leurs rôles du premier site.

Les utilisateurs du second site n’hériteront pas de leurs rôles du premier site.

Pour accorder aux utilisateurs les mêmes capacités dans les deux sites, nous devons mettre à jour la table {$pref}usermeta.

Vous avez des problèmes de temps d'indisponibilité et de WordPress ? Kinsta est la solution d'hébergement conçue pour vous faire gagner du temps ! Découvrez nos fonctionnalités

Rôles et Capacités

Si vous exécutez de nouvelles installations WordPress, vous n’avez pas à vous soucier de la table {$pref}options. Vous avez juste besoin de mettre à jour la table {$pref}usermeta.

Dans notre exemple, lorsqu’un nouvel utilisateur est créé dans le premier site web, WordPress ajoute les lignes first_capabilities et first_user_level dans la table first_usermeta. Pour donner accès au deuxième site Web, ces lignes doivent être dupliquées, comme le montre l’image ci-dessous :

deuxiemes-champs-usermeta

Lorsqu’un nouvel utilisateur est créé dans le deuxième site Web, les lignes second_capabilities et second_user_level seront ajoutées à la table first_usermeta.
Afin de donner les mêmes rôles et les mêmes capacités aux utilisateurs sur l’ensemble des sites Web, les lignes first_capabilities et first_user_level doivent être dupliquées dans second_capabilities et second_user_level. Avec ces deux paires de lignes dans la même table first_usermeta, les utilisateurs pourraient accéder aux deux sites Web avec les mêmes privilèges.

Pour mettre à jour toutes les lignes usermeta existantes, vous pouvez exécuter une requête SQL ou mettre à jour les tables depuis phpMyAdmin. Mais qu’en est-il des utilisateurs qui s’abonneront dorénavant à nos sites Web ? D’après le Codex WordPress, nous utiliserions une extension ou construirions une fonction personnalisée.
Et c’est parti !

Dupliquer Automatiquement les Capacitiés et les Niveaux avec une Fonction

set_user_role est un crochet d’action qui se déclenche chaque fois qu’un nouvel utilisateur est créé ou qu’un rôle d’utilisateur existant a été modifié. Grâce à cette action, nous pouvons automatiser les mises à jour des tables usermeta.
Ainsi, dans le fichier principal d’une extension ajoutez la fonction suivante :

function ksu_save_role( $user_id, $role ) {

	// Site 1
	// Change value if needed
	$prefix_1 = 'first_';
	
	// Site 2 prefix
	// Change value if needed
	$prefix_2 = 'second_';
	
	$caps = get_user_meta( $user_id, $prefix_1 . 'capabilities', true );
	$level = get_user_meta( $user_id, $prefix_1 . 'user_level', true );

	if ( $caps ){
		update_user_meta( $user_id, $prefix_2 . 'capabilities', $caps );
	}

	if ( $level ){
		update_user_meta( $user_id, $prefix_2 . 'user_level', $level );
	}
}

add_action( 'set_user_role', 'ksu_save_role', 10, 2 );

La fonction de callback conserve trois arguments, dont deux sont nécessaires : $user_id et $role.
Ce que fait la fonction est assez explicite. get_user_user_meta retourne la valeur spécifiée du champ user meta. Nous avons appelé cette fonction deux fois pour récupérer les champs first_capabilities et first_user_level. Ensuite, nous avons utilisé ces valeurs pour ajouter des champs second_capabilities et second_user_level à la table first_usermeta.

Téléversez et activez cette extension dans le premier site web.

Pour que les installations fonctionnent symétriquement, il suffit de téléverser et d’activer l’extension dans n’importe quelle installation, mais en définissant les bonnes valeurs aux préfixes. Par exemple, si nous activons cette fonctionnalité dans le deuxième site Web, nous n’avons qu’à déclarer les variables comme suit :

$prefix_1 = 'second_';
$prefix_2 = 'first_';

Donc, modifiez et installez l’extension dans le deuxième site web et créez un nouvel utilisateur ou modifiez un rôle utilisateur existant. Consultez ensuite le premier site Web. Les rôles des utilisateurs seront exactement les mêmes que ceux du deuxième site Web.

Résumé

Dans cet article, j’ai expliqué comment accorder les mêmes privilèges aux utilisateurs sur des installations WordPress indépendantes. Une fois enregistré sur un site Web, l’utilisateur pourra accéder à tous les sites Web partageant les mêmes tables users et usermeta.
Je suis censé travailler avec de nouvelles installations. Si vous travaillez sur des sites web existants, vous devriez considérer que certaines extensions ont pu mettre à jour la table usermeta, ou même créer de nouvelles tables stockant des données relatives aux utilisateurs. Dans ce cas, une analyse plus précise de la base de données serait appropriée.

Si vous avez des questions sur la façon de partager des identifiants dans WordPress, ou si vous souhaitez partager votre expérience avec nous, n’hésitez pas à vous joindre à la conversation en publiant vos commentaires.

Le code complet de notre extension est disponible dans ce Gist public


Si vous avez aimé cet article, alors vous allez adorer la plateforme d’hébergement WordPress de Kinsta. Accélérez votre site Web et obtenez le support 24/7 de notre équipe de vétérans de WordPress. Notre infrastructure propulsée par Google Cloud met l’accent sur la mise à l’échelle automatique, la performance et la sécurité. Laissez-nous vous montrer la différence de Kinsta ! Découvrez nos plans