par Anne-Laure DELPECH | 2 Oct 2016 | Plugin (extension) WordPress
Lorsque nous voulons réserver certains contenus d’un site WordPress à des personnes (ou groupes de personnes) spécifiques, il faut rendre certains contenus privés. Nous allons voir comment le faire avec trois extensions.
Chris Lema, une référence pour les extensions de « membership »
Chris Lema est un auteur prolifique, très connu dans le monde WordPress anglophone. Il a, entre autres, examiné une trentaine d’extensions de gestion des « memberships », qui permettent de créer des espaces réservés dans un site web. Et chacun des articles dédié à l’une de ces extensions est incroyablement complet et détaillé.
« Membership » ou « subscription » ?
Une extension de « membership » gérera toujours l’enregistrement d’utilisateur (moyennant paiement ou non) et la possibilité pour ces utilisateurs connectés de voir des contenus protégés.
Certaines gèreront également d’autres fonctionnalités utiles telles que :
- gestion des renouvellement d’abonnement (payant ou pas) ;
- créer une liste des abonnés ;
- créer une page spéciale pour chaque abonné ;
- associer des systèmes de paiement ;
- gérer des évènements ;
- …
Pour en savoir plus, on peut lire Don’t confuse Memberships and Subscriptions. Chris Lema y explique que les extensions de membership gère l’accès à des contenus. Mais l’inscription, ou le renouvellement d’un abonnement nécessite une extension de « subscription ».
Créer un espace réservé sur un site avec Members
Dans mon cas, je suis en phase d’expérimentation. Je privilégie donc le côté gratuit, ainsi que la possibilité de créer des extensions moi même pour étendre ses fonctions. J’ai donc choisi d’utiliser l’extension « Members », de Justin Tadlock. L’article de Chris Lema, Membership Plugin Review: Members, explique comment l’utiliser avec deux autres extensions pour créer des contenus réservés, gérer les login et mise à jour des profils des abonnés et enfin définir des menus pour les abonnés et les autres. C’est donc un excellent moyen de se familiariser avec la création d’un site à contenus réservés.
Je ne vais pas reprendre le contenu de l’article de Chris Lema de manière détaillée. J’ai réalisée les étapes telles qu’il les décrit.
étape 1, installer les trois extensions nécessaires
Installer (sans les activer) Members, Nav Menu Roles et Profile Builder.
« Members » permettra d’attribuer des rôles aux utilisateurs du site puis de restreindre l’accès ou la modification de contenus (ou du site tout entier) selon les rôles.
« Nav Menu Roles » va permettre de définir quels menus sont vus par qui (quels rôles).
« Profile Builder » facilite la gestion des comptes des utilisateurs. L’extension permet d’avoir une page spécifique pour se connecter ou s’enregistrer (en évitant l’affreuse page wp-login.php de WordPress). Elle autorise également l’utilisateur à mettre à jour son profil et son mot de passe.
Etape 2, activer « Members » et la paramétrer
Après avoir activé « Members », je crée un rôle spécifique « membre-site ». En dessous du champs dans lequel je crée le nom de ce rôle, je vois écrit « Rôle : membresite« , que je peux modifier. C’est ce nom qui servira ensuite pour définir dans du code ou des shortcode des actions spécifiques à ce rôle. Dans « modifier les capacités », je laisse la seule case cochée : « read ». Les personnes aux rôles « membre-site » ne pourront que lire des contenus.
Etape 3, activer « Profile Builder » et la paramétrer
Les shortcode utilisables avec cette extension sont visibles dans le nouveau menu « Profile Builder » > « Informations de base ». D’autres shortcodes sont également listés dans la description de l’extension, sur WordPress.org.
Je crée les pages suivantes :
- « accueil », qui sera réglée comme page d’accueil du site ;
- « Connexion » contenant le short code [[wppb-login register_url= »http://exemple.com/page-enregistrement/ » lostpassword_url= »http://exemple.com/lost-password/ »] ] ;
- « Enregistrement » avec le short code [[wppb-register role= »membresite »] ] ;
- « votre profil » avec le short code [[wppb-edit-profile] ] ;
- « renouvellement du mot de passe » avec le short code [[wppb-recover-password] ]
- « contenu protégé », avec le contenu protégé, et par exemple des liens vers d’autres contenus protégés.
Attention, sur la page d’enregistrement, il faut préciser le rôle des personnes qui pourront s’enregistrer. On doit donc placer le short code [[wppb-register role= »desired_role »]], avec desired_role remplacé par le rôle correspondant.
La page « contenu protégé » est protégée en cliquant sur « membre-site » sous l’éditeur de la page. On peut également définir un message d’erreur qui sera affiché si une personne non connectée tente d’accéder à cette page. Si on veut un message d’erreur commun à toutes les pages dont le contenu est protégé, on la définit dans « Réglages » > « Members ».
Dans un widget de la barre latérale, on peut ajouter le widget « Profile Builder Login Widget » afin de permettre aux utilisateurs de se connecter, déconnecter, être redirigé sur les contenus protégés une fois connecté.
Etape 4, gestion des menus
La structure de menu doit permettre d’avoir des éléments affichés seulement pour les membres, d’autres pour tous.
Après activation de « Nav Menu Roles« , lorsqu’on va dans « Apparence » > « Menus », on peut choisir ce qui s’affiche selon les rôles.
Par exemple, pour l’élément « contenu protégé », on clique sur « utilisateurs connectés » et on choisit les rôles « membre-site » et « administrateur ».
Par contre, l’élément « login » doit être visible pour les utilisateurs non connectés seulement.
Et voilà, j’ai maintenant un site web avec du contenu protégé !
Exploration rapide des fonctionnalités
Profile Builder a d’autres fonctionnalités utiles :
- Dans « Profile Builder » > « Paramètres généraux », on peut définir la Longueur minimale du Mot de Passe et surtout régler la Sûreté minimale du Mot de Passe. J’ai essayé avec 8 caractères minimum et une sureté minimale sur « moyen » ;
- Dans « Profile Builder » > « Paramètres généraux », on peut cocher « Confirmation par e-mail » puis régler le contenu des emails expédiés ;
- Dans « Profile Builder » > « Paramètres de la barre Administration », on peut (et on devrait) régler sur « masquer » pour tous les rôles qui ne sont pas administrateur ou éditeur.
Il est possible d’autoriser l’enregistrement en ligne via les réglages de WordPress (« Réglages » > « Général ») : il suffit de cocher « tout le monde peut s’enregistrer » et de définir le rôle par défaut des personnes qui s’enregistrent. Mais avec les extensions installées, il n’est pas possible de limiter les enregistrements à ceux qui sont autorisés par l’administrateur. Profile Builder propose de recourir à une extension payante pour celà.
Il serait intéressant d’essayer l’extension (gratuite) New User Approve. Sur cette extension, voir aussi « How to Moderate New User Registrations in WordPress« .
Members a également d’autres fonctionnalités intéressantes :
- On peut activer des widgets spécifiques dans la page « Réglages » > « Members », en cochant « Activer le widget du formulaire de connexion » et/ou « Activer le widget utilisateurs ». Le deuxième widget permet de voir la liste des autres utilisateurs qui ont le rôle défini dans le widget. Je préfère les widgets de Profile Builder.
- on peut cocher « Activer site privé » : lorsque la case est cochée, c’est l’ensemble du site qui devient privé. Toute personne non connectée qui essaie de lire un contenu du site est automatiquement redirigée sur la page de connexion WordPress par défaut ;
- on peut cocher « Désactiver le flux » : pour afficher un message d’erreur pour le flux RSS du site. Ça paraît essentiel en effet ;
- Si on restreint l’accès à une page, toutes ses pages « enfant » ont par défaut le même réglage (cf cette question sur le forum themehybrid.com).
- Avec un peu de code additionnel, on peut régler WordPress pour afficher les résumés à tous les internautes et restreindre l’accès au reste de l’article (ou de la page) : cf cette question et cette autre question sur le forum themehybrid.com ;
Autres extensions en complément
Si je veux faire payer l’accès au contenu réservé, je pourrai utiliser Membership & Content Restriction – Paid Member Subscriptions, qui fonctionne avec Profile Builder que j’utilise ici. Mais logiquement je peux utiliser n’importe quel autre extension de « souscription ».
Le gros avantage de Members est qu’il s’intègre très bien avec d’autres extensions, même si elles ne le disent pas explicitement. En effet, Members utilise des fonctions de WordPress pour créer les rôles. Par exemple Event espresso 4 permet aux différents rôles créés avec Members d’accéder aux contenus liés aux événements selon leurs rôles. Il est également possible d’utiliser Learndash avec Members, comme indiqué dans cette question sur le forum themehybrid.com.
L’extension gratuite MailChimp User Sync devrait permettre de synchroniser des listes MailChimp selon les rôles.
Et maintenant ?
Je vais créer un site à contenu privé pour explorer un peu plus ce qu’il est possible de faire.
par Anne-Laure DELPECH | 30 Sep 2016 | Hébergement web
Ce billet est le troisième de la série Gérer tous ses emails avec Gmail. Nous avons vu comment utiliser Gmail dans deux cas déjà :
- Le cas où on fait gérer les mails d’un nom de domaine par OVH (hébergement ou plan MX) et on utilise Gmail dans sa version gratuite pour lire et expédier des mails venant de, ou provenant de, l’une de ces adresses créées sur OVH. C’était l’objet du premier article de cette série, Utiliser sa boîte gmail avec des mails d’un hébergement OVH ;
- Un cas où l’on gère les mails d’un nom de domaine par OVH et où l’on a un compte Google Apps (son nom est devenu récemment G Suite) et l’on utilise un alias de nom de domaine pour faire gérer certaines adresses du domaine directement par Google. C’est ce dont il était question dans l’article Transférer la gestion des emails d’un domaine de google apps à OVH
Nous allons maintenant voir un troisième cas : le cas où on a un compte Google Apps ET des noms de domaine sans hébergement et sans plan MX chez OVH.
Le contexte
Sur OVH, j’ai un nom de domaine, potentiel-web.com, qui n’a pas son propre hébergement. Je ne peux donc pas y créer d’adresse mail.
Mais comme j’ai un compte Google Apps, je peux créer des adresses mail pour ce domaine et Google les gère !
Etape 1 : régler les enregistrements MX du domaine
Dans l’espace client OVH, menu Domaines / le domaine qu’on veut régler, aller dans l’onglet « zones DNS ».
Au dessus de la liste des zones DNS, remplacer « tous » dans le filtre par « MX ». On ne voit plus que les enregistrements MX pour le domaine et ses sous-domaines éventuels.
Modifier ou ajouter des enregistrements MX pour avoir :
| MX Adresse du serveur |
Priorité |
| ASPMX.L.GOOGLE.COM. |
1 |
| ALT1.ASPMX.L.GOOGLE.COM. |
5 |
| ALT2.ASPMX.L.GOOGLE.COM. |
5 |
| ASPMX2.GOOGLEMAIL.COM. |
10 |
| ASPMX3.GOOGLEMAIL.COM. |
10 |
Ces 5 enregistrements MX disent à tout internet « si tu reçois un mail de ce domaine, voici le serveur qui doit le prendre en charge« .
Il semble également préférable de faire les modifications suivantes dans les zones DNS sur le compte OVH :
- supprimer le champ SPF pour le domaine (qui contient « v=spf1 include:mx.ovh.com ~all ») ;
- ajouter un champ TXT pour le domaine avec le contenu « v=spf1 include:_spf.google.com ~all ».
Les deux dernières modifications disent à tout internet « ce mail émis par un serveur google est authentifié par google ». Ca limite le risque de voir ce mail classé en spam.
Il faut attendre 24h pour que ces 7 modifications soient diffusées : on peut regarder sur whatsmydns.net la vitesse de propagation. C’est instructif !
Il vaut donc mieux attendre ces 24h avant de faire la suite de ce tutoriel.
Créer un domaine dans la console Google Apps
Dans la console d’administration google apps, menu Domaines cliquer sur le bouton « ajouter un domaine ou un alias de domaine ».
J’ai ainsi créé potentiel-web.com. Je clique ensuite sur le lien « configurer les enregistrements MX pour Google »
Google Apps (G Suite) Créer un alias de domaine – 2
Comme j’ai déjà fait l’opération sur mon compte OVH, il me suffit de descendre tout en bas e la page qui s’ouvre et cliquer sur « j’ai effectué cette procédure ». Google vérifie puis la ligne correspondante au domaine devient « actif »
Google Apps (G Suite) Vérifier un alias de domaine 2
Créer un alias d’email dans Google Apps
Dans la console d’administration google apps, menu utilisateur, cliquer sur mon nom puis sur « compte »
Je vois alors une liste d’alias. Je peux en ajouter (par exemple contact@potentiel-web.com »).
A ce stade Gmail lit automatiquement tous les mails adressés à l’alias d’email créé. Mais il faut maintenant paramétrer Gmail pour qu’il accepte d’expédier ces mails en tant que l’alias.
Paramétrer pour expédier « en tant que » cet alias
Dans Gmail, paramètres, onglet comptes, cliquer sur « ajouter une autre adresse mail » dans le champs correspondant à « Envoyer des e-mails en tant que : ». La fenêtre suivante s’ouvre (lorsqu’on crée, l’adresse mail est un champ qu’on peut modifier) :
Gmail gérer un alias d’adresse mail 2
On remplit avec l’adresse mail correspondant à l’alias d’e-mail créé précédemment puis on clique sur le bouton « Etape suivante ».
Ca y est, c’est fini ! Gmail lit les mails adressés à contact@potentiel-web.com et en expédie sous ce nom alors qu’OVH gère le nom de domaine mais pas les mails.
Et maintenant ?
Cette série est en principe terminée. J’ai exploré les 3 cas d’utilisation de Gmail.
par Anne-Laure DELPECH | 30 Sep 2016 | Hébergement web
Je gérais les mails du domaine parcours-performance.com avec mon compte google apps. Mais c’était un peu compliqué d’ajouter de nouvelles adresses. J’ai donc supprimé les enregistrements MX du domaine qui transféraient la gestion des mails de ce domaine et OVH les gère de nouveau. J’explique ici comment j’ai procédé, avec l’aide du SAV de Google.
Le contexte
Mon compte google for work (G Suite maintenant) dispose d’un seul utilisateur, dont l’adresse mail pour accéder au compte Google était (ce n’est pas la véritable adresse !) « moi@parcours-performance.com ». Cette adresse mail étant mon adresse professionnelle principale, il n’était pas question de la supprimer.
Les mails du domaine « parcours-performance.com » étaient gérés par Google car j’avais réglé les enregistrements MX d’OVH ainsi :
| Domaine |
TTL |
Type |
Cible |
| parcours-performance.com. |
0 |
MX |
5 alt1.aspmx.l.google.com. |
| parcours-performance.com. |
0 |
MX |
5 alt2.aspmx.l.google.com. |
| parcours-performance.com. |
0 |
MX |
1 aspmx.l.google.com. |
| parcours-performance.com. |
0 |
MX |
10 aspmx2.googlemail.com. |
| parcours-performance.com. |
0 |
MX |
10 aspmx3.googlemail.com. |
Dans Google Apps, j’avais créé deux adresses mail : « moi@parcours-performance.com » et « contact@parcours-performance.com » et j’avais complètement oublié comment.
Dans l’espace client OVH, je pouvais créer de nouvelles adresses sur le domaine parcours-performance.com mais elles ne fonctionnaient pas puisque ce n’était plus OVH qui gérait les mails…
Avec l’aide du SAV de Google (très bien, gratuit pour les abonnés de G Suite), j’ai transféré la gestion des mails à OVH et demandé à gmail de gérer les mails correspondants.
Les actions à mener pour transférer la gestion des mails
Activer la double distribution de Google
Ce document d’aide de Google en explique le principe.
Dans la console d’administration google apps, menu Domaines, cliquer sur le bouton « ajouter un domaine ou un alias de domaine ». J’ai créé whatever.parcours-performance.com.
Google Apps (G Suite) Créer un alias de domaine
Ensuite je clique sur le lien « configurer les enregistrements MX pour Google » pour avoir les instructions.
Dans un autre onglet, je me connecte à l’espace client OVH, menu « domaines » et j’ajoute (ou modifie) les enregistrements MX de cet alias de domaine pour que :
| MX Adresse du serveur |
Priorité |
| ASPMX.L.GOOGLE.COM. |
1 |
| ALT1.ASPMX.L.GOOGLE.COM. |
5 |
| ALT2.ASPMX.L.GOOGLE.COM. |
5 |
| ASPMX2.GOOGLEMAIL.COM. |
10 |
| ASPMX3.GOOGLEMAIL.COM. |
10 |
Lorsque c’est fait dans OVH, je retourne dans l’onglet Google Apps, et tout en bas de la page « configurer les enregistrements MX pour Google », je clique tout en bas sur « j’ai effectué cette procédure ». Google vérifie puis la ligne correspondante au domaine devient « actif »
Google Apps (G Suite) Vérifier un alias de domaine
Il vaut mieux attendre 24 h que les enregistrements MX se diffusent dans le monde. Une fois que c’est fait, tout mail adressé @whatever.parcours-performance.com sera géré par Google et non par OVH.
Pour l’adresse principale créer un alias d’adresse email dans google apps
Dans mon compte Google Apps (console d’administration google apps, menu utilisateurs), je clique sur le nom de mon compte. Ca ouvre une fenêtre avec des informations sur ce compte. En cliquant sur l’élément « compte », je vois les alias d’email que j’ai déjà.
A ce stade, « moi@parcours-performance.com » est défini parmi les alias dans Google Apps. Je n’y touche pas.
Ensuite, dans le compte OVH, je crée un compte « test.al@parcours-performance.com ». Toujours dans OVH, je crée une redirection de ce compte vers « test@whatever.parcours-performance.com » (noter que j’utilise l’alias de nom de domaine, pas le nom de domaine) :
A ce stade, si j’envoie un mail à « test.al@parcours-performance.com », je ne le reçois pas car je n’ai pas défini où il doit être lu.
Pour qu’il arrive automatiquement dans ma boîte mail GMail, il faut que je paramètre Gmail pour qu’il lise test@whatever.parcours-performance.com :
Dans gmail, Paramètres puis onglet comptes, cliquer sur « ajouter une autre adresse mail »
Noter que j’indique l’alias de domaine pour l’adresse email.
Lorsque je clique sur le bouton « étape suivante », c’est fini. Gmail est maintenant capable de gérer cet alias d’email.
Maintenant si quelqu’un envoie un mail à l’adresse test.al@parcours-performance.com, gérée par OVH, elle est automatiquement redirigée dans ma boîte gmail. Pour moi c’est totalement transparent (je n’ai même pas à me souvenir du nom de l’alias) et je réponds en tant que test.al@parcours-performance.com par défaut.
Evidemment, ceci était un test pour vérifier le bon fonctionnement du système avec alias et je peux supprimer l’adresse test.al@parcours-performance.com dans l’espace OVH. Il faut maintenant qu’OVH reprenne la gestion des mails du domaine Parcours-Performance.com.
Gérer mon adresse principale par OVH et non google
Dans mon espace client OVH, menu « Emails » du domaine (parcours-performance.com pour moi), enlever le filtrage qui transfère la gestion des mails à Google. Merci au support OVH de m’avoir expliqué celà !
Il suffit d’éditer le champ « filtrage antispam/antivirus et le régler sur « OVH sans protection ». On notera que si ce n’est pas Gmail qui est utilisé ensuite pour recevoir les mails, il vaut sans doute mieux mettre une protection antispam.
Tout à l’heure, on avait regardé les alias d’emails dans le compte Google Apps. J’avais noté que deux adresse du domaine parcours-performance.com étaient définies comme des alias : « moi@parcours-performance.com » et « contact@parcours-performance.com ».
Je ne touche pas aux alias d’emails définis dans Google Apps pour l’instant.
Mais je vais créer dans l’espace OVH les deux mêmes adresses mail. Je crée les deux adresses dans OVH puis je les redirige respectivement vers moi@whatever.parcours-performance.com et contact@whatever.parcours-performance.com (noter que c’est toujours l’alias de nom de domaine que j’utilise.
OVH : rediriger une adresse mail ovh vers un alias de domaine
On peut préférer que la redirection fasse conserver une copie du mail dans les boîtes OVH pour gérer les prochaines 24h et être certains que les mails ne se perdront pas.
A ce stade, comme mon Gmail récupérait déjà les adresses « moi@parcours-performance.com » et « contact@parcours-performance.com », il récupère sans difficulté les mails.
supprimer des alias du compte Google Apps
Pour faire cette opération, il faut IMPERATIVEMENT attendre 24h après la modification des enregistrements MX de parcours-performance.com d’une part, et de l’alias whatever.parcours-performance.com.
Lorsque les 24h depuis le changement le plus récent sont finies, on va supprimer les alias « moi@parcours-performance.com » et « contact@parcours-performance.com » dans notre compte Google Apps.
Et si on avait fait une redirection sur OVH qui conservait une copie des mails, on peut maintenant aller la modifier (il suffit de supprimer la redirection de « moi@parcours-performance.com » vers « moi@parcours-performance.com » et conserver celle qui va vers « moi@whatever.parcours-performance.com »
Et si je veux créer une nouvelle adresse mail ?
Deux options : si c’est une adresse très utilisée, pour laquelle il faut prévoir un gros espace disque, il est plus simple d’utiliser un alias de domaine, avec gestion des mails de ce domaine par google. Pour les autres cas, on paramètre simplement Gmail.
Par exemple, j’ai créé test-al2@parcours-performance.com dans OVH, avec redirection sans copie vers moi@whatever.parcours-performance.com.
Ensuite, je suis allée dans Gmail « paramètres, onglet compte » et j’ai choisi « ajouter une autre adresse mail ». Ca se passe ensuite exactement comme pour un compte gmail classique (cf le premier article de cette série, « Utiliser sa boîte gmail avec des mails d’un hébergement OVH« ), sauf que si le domaine de l’email fait partie des domaines enregistrés pour le compte Google Apps, il n’y a pas l’écran dans lequel on doit définir les paramètres SMTP. Et comme j’ai fait une redirection, je reçois le mail avec le code de confirmation directement dans ma boîte gmail.
Et maintenant ?
Il reste un cas particulier d’utilisation de google Apps (G Suite), c’est le cas où on a un domaine chez OVH mais pas d’hébergement et pas de « plan MX ». G Suite nous permet de créer des adresses mail sans supplément de coût, avec un paramétrage plutôt simple. Ce sera l’objet du troisième article de cette série Gérer tous ses emails avec Gmail.
par Anne-Laure DELPECH | 30 Sep 2016 | Hébergement web
Vous avez crée votre réseau de site WordPress avec la fonctionnalité multisites. Jusqu’à présent, il était possible d’avoir le même identifiant (même adresse mail) en tant qu’utilisateur de différents sites. Mais sur un multisite, si j’utilise le même identifiant pour créer des contenus dans plusieurs sites, ils auront tous les mêmes renseignements biographiques.
Pourquoi éviter d’avoir un seul identifiant ?
Pour des renseignements biographiques ciblés sur les thématiques du site
Par exemple sur ce site, knowledge.parcours-performance.com, j’utilise la même adresse mail comme administrateur que pour mon site parcours-performance.com et je n’y ai pas mis les mêmes renseignements biographiques. C’est logique puisque mon parcours « maker » n’intéresse pas les lecteurs de l’autre site et mon parcours « organisation et lean management » ne vous intéresse pas. En multisite, si je veux avoir des renseignements biographiques différents pour le même auteur, il faut des identifiants différents (donc des adresses mail différentes).
Car WordPress est fait comme ça…
WordPress gère les utilisateurs pour l’ensemble des sites du réseau avec un identifiant unique et une adresse mail unique. On ne peut donc pas se créer plusieurs fois…
Pour des raisons de sécurité
Les identifiants et mots de passe des super administrateurs donnent l’accès à toute la machinerie du site. Ils doivent donc être protégés, et jamais enregistrés sur l’ordinateur. Imaginez ce qui se passerait si votre nièce ou votre fils allait modifier des éléments du tableau de bord du réseau !
Pour éviter les erreurs
https://c5.staticflickr.com/9/8085/8562448300_2a5c7b1e59.jpg
Une erreur sur un site isolé est déjà très embêtante, alors sur un ensemble de sites…
Lorsqu’on met notre « casquette » d’éditeur, on peut rédiger et publier des contenus.
Lorsqu’on met notre « casquette » d’administrateur d’un site, on peut modifier la structure du site (avec quelques limites).
Et lorsqu’on est enregistré en tant que super administrateur, on a tous les droits : on peut ajouter des extensions sans même s’être préoccupé de leurs compatibilité multisite ou de leur sécurité, on peut faire des mises à jour sans avoir au préalable vérifié les impacts sur un site de développement, …, on peut casser plusieurs sites d’un clic !
Il est donc préférable d’avoir l’esprit tranquille lorsqu’on est éditeur : on ne peut rien faire de très grave. Lorsqu’on est administrateur, on doit déjà réfléchir à deux fois aux conséquences d’un clic. Et lorsqu’on est super administrateur, on doit être ultra-vigilant, presque paranoïaque, et systématiquement tester nos choix avant de les mettre en oeuvre.
Les bonnes pratiques adoptées sur mes sites multisites
Principe n°1 : une même personne peut avoir plusieurs rôles mais elle a un identifiant par rôle (et donc une adresse mail différente par rôle).
Principe n°2 : sur deux sites différents d’un même multisite, un même auteur (ou éditeur) a un identifiant différent et donc une adresse mail différente. Il/elle peut ainsi avoir des renseignements biographiques différents et choisir des couleurs de tableau de bord différentes pour limiter les erreurs.
Principe n°3 : une personne qui peut avoir accès à l’ensemble du multisite est super administrateur. Elle peut avoir les fonctions d’administrateur dans n’importe quel site sans changer d’identifiant. A l’inverse, une personne qui peut être administrateur d’un ou plusieurs sites ne dispose pas des droits de super-administrateur.
Nota : pour éviter de mémoriser un nombre délirant d’identifiants et mots de passe, il est possible d’utiliser une extension comme « user switching« , qui permet de changer de rôle simplement. On peut aussi explorer des gestionnaires de mot de passe comme LastPass ou KeePass, voire Dashlane.
Créer les bons utilisateurs aux bons endroits dans un multisite
Pour l’instant, je vais considérer que nous avons assez d’adresses mail distinctes, et que nous en recevons tous les messages au fur et à mesure. Dans un article à venir, j’en parlerai plus précisément.
Le contexte :
Je suis dans un multisite dont le site principal contient une centaine d’articles écrits par moi lorsque je n’étais que « administrateur » de ce site solo. Maintenant, ce même identifiant est devenu « super administrateur ».
D’autres sites sont venus s’ajouter dans le multisite et il faut que je reste l’auteure de ses contenus, mais avec un autre profil pour ne pas être obligée d’avoir des renseignements biographiques uniques.
Ce que je vais faire :
Je vais définir des adresses différentes pour tous les rôles suivants.
Pour le site principal (PRINCIPAL.com) :
| rôle |
adresse mail correspondante |
| Super administrateur |
SUPER-ADMIN@PRINCIPAL.com |
| administrateur |
ADMIN@PRINCIPAL.com |
| éditeur (ou autre) |
EDITEUR@PRINCIPAL.com |
pour les « sous » sites du réseau « SOUS.PRINCIPAL.com, on peut être administrateur avec l’identifiant du site principal mais si on produit des contenus on le fera sous l’identifiant de l’éditeur spécifique à ce sous site.
| rôle |
adresse mail correspondante |
| éditeur (ou autre) |
EDITEUR-SOUS@PRINCIPAL.com |
|
|
Mon site de test est composé de trois sites :
- le site principal, potentiel-web.com
- un site secondaire, test1.potentiel-web.com
- un site secondaire, test1.parcours-performance.com
Il va donc falloir que je crée les utilisateurs avec des mails ressemblant à ce qui suit :
Pour potentiel-web.com :
| Super administrateur |
super-admin[a]potentiel-web.com |
| administrateur |
admin[a]potentiel-web.com |
| éditeur |
editeur[a]potentiel-web.com |
Pour test1.potentiel-web.com
| éditeur |
editeur-test1[a]potentiel-web.com |
Pour test1.parcours-performance.com, j’utilise le nom de domaine principal, pas celui du site principal.
| éditeur |
editeur-test1[a]parcours-performance.com |
Comment je le fais :
Comme les deux sites ajoutés dans le réseau sont des sites tous neufs, il n’y aucun contenu dedans. Je n’ai donc pas à me préoccuper de transférer les contenus à un nouvel utilisateur. Mais pour le site principal, il faut que je puisse transférer le contenu du super administrateur actuel à un simple éditeur.
créer les utilisateurs dans l’administration du réseau
Pour tous les sites, principal ou pas, je vais dans « Mes sites » > « Admin du réseau » > « Utilisateurs » et j’y crée un à un les 7 comptes indiqués ci-dessous avec le bouton « ajouter ».
Lorsque j’ai créé les trois premiers, la liste de mes utilisateurs devient comme ci-dessous. Pour des raisons évidentes de sécurité, ce sont des identifiants que je n’utiliserai pas, pas plus que les adresses mails indiquées. Et il faut noter que je suis connectée en tant que super administrateur avec un identifiant qui n’est pas affiché dans cette liste mais qui le sera pour vous.
Pour l’instant ces utilisateurs n’ont aucun rôle (et ils n’en auront jamais puisque les adresses mail n’existent pas, je ne pourrai donc jamais générer un mot de passe…).
Pour le super administrateur, je clique sur modifier puis je coche la case « Donner les privilèges de super-admin à cet utilisateur pour le réseau. ». superadminwhatever est maintenant devenu super administrateur !
Donner des rôles aux utilisateurs dans les différents sites
Les 2 autres utilisateurs ci-dessus doivent avoir des rôles dans le site primaire, potentiel-web.com.
Dans « Mes sites » > « Admin du réseau » > « Sites », j’ai la liste des sites du réseau. Lorsque je survole le nom d’un site, je vois apparaître des liens.
Je clique sur « modifier » en dessous du nom du site principal. Je vois alors un écran avec 4 onglets. Je vais dans « utilisateurs ».
Sous la liste des utilisateurs déjà affectés, il y a la possibilité d’ajouter un utilisateur existant. Je tape les premiers caractères d’un utilisateur et WordPress me propose un utilisateur. Je lui donne le rôle correspondant. Je fais ça pour l’éditeur et l’administrateur de chaque site.
transférer les contenus du super administrateur actuel à l’éditeur
Il faut avant avoir rempli le prénom et le nom de l’utilisateur, relié le compte à une photo (gravatar), et rempli les renseignements biographiques du compte éditeur.
Lorsqu’on supprime le super administrateur (il faut s’être reconnecté au préalable sous l’identifiant du nouveau superadministrateur), WordPress demande à qui on veut attribuer le contenu de cet utilisateur. On l’attribue à editeurwhatever et le tour est joué !
Et maintenant ?
Il faudra apprendre à gérer de nombreux identifiants et mots de passe…
par Anne-Laure DELPECH | 26 Sep 2016 | Hébergement web
Je souhaite transformer un site existant (https) en un site multisite WordPress. En principe, c’est exactement comme ce que j’ai fait avec le site de test dans le premier article de cette série. La seule différence, c’est que je ne peux pas me permettre d’erreur puisque le site est utilisé…
Je fais comme indiqué dans le premier article de cette série WordPress Multisite sur OVH mutualisé, avec en plus des sauvagardes et la gestion des extensions existantes.
Sauvegarder les éléments du site existant
- En premier, faire une sauvegarde de la base de données du site et la conserver dans un endroit sûr.
- Avec Filezilla ou équivalent, faire une copie des fichiers .htaccess (en .htaccessOLD) et wp-config.php (en wp-configOLD.php).
- Dans le tableau de bord WordPress du site existant, aller dans le menu « extensions » puis choisir la vue « extensions activées ». Copier le tableau dans Word ou autre pour disposer d’une liste de toutes les extensions activées du site.
Transformer le site en site multisite WordPress
Ca fonctionne exactement comme dans l’article « Un site ‘multisite’ WordPress sur OVH mutualisé ».
(1) Dans wp-config.php , j’ajoute les deux lignes suivantes :
/* Multisite */
define('WP_ALLOW_MULTISITE', true);
Dans le tableau de bord WordPress, (2) je désactive toutes les extensions puis je vais dans le menu « outils » > « création du réseau ». Là je ne peux que choisir « sous-domaines », je met mes coordonnées d’administrateur comme nom de super-administrateur et je sauvegarde.
(3) Je modifie wp-config.php pour que les lignes correspondant aux multisite soient maintenant (attention dans la ligne 6 surlignée, le nom du domaine doit être le bon) :
/* Multisite */
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'monsite.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
/* HTTPS only for admin access */
define( 'FORCE_SSL_ADMIN', true );
define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');
(4) Je modifie .htaccess qui contient maintenant (c’est un site en https) :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
# direct everything to https
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress
(5) Je me reconnecte au tableau de bord WordPress du site.
Je sélectionne toutes les extensions qui doivent être réactivées puis (6), je les active pour les reseau.
Je vérifie et tout va bien. Du point de vue de l’internaute, le site est comme avant. Evidemment, du point de vue de l’administrateur devenu super-administrateur, il y a quelques changements.
Et maintenant ?
Il faut que je voies quelles sont les différences entre ‘super-administrateur’ et ‘administrateur’ pour voir quels sont les points de vigilance à prévoir. Ce sera l’objet d’un autre article de cette série WordPress Multisite sur OVH mutualisé.
Commentaires récents