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
- Définition de tables utilisateur personnalisées – Partager les identifants
- Installation de WordPress
- Rôles et capacités
- Dupliquer automatiquement les capacités et les niveaux avec une fonction
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
.
- La table
{$pref}options
stocke la liste complète des rôles et capacités disponibles dans une ligne dont le champ option_key est{$pref}user_role
s. - La table
{$pref}users
stocke les données de base des utilisateurs, telles que identifiant, mot de passe, e-mail, url, etc. - La table
{$pref}usermeta
stocke les métadonnées utilisateur.
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.
{$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.
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.
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' );
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.
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.
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
.
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.
Pour accorder aux utilisateurs les mêmes capacités dans les deux sites, nous devons mettre à jour la table {$pref}usermeta
.
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 :
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
Laisser un commentaire