Imaginez la situation: vous lancez un portail d'entreprise sur WordPress, vous créez un type de publication personnalisé appelé «Équipement» et vous le remplissez avec votre documentation interne. Une semaine plus tard, vous découvrez que toutes ces pages sont indexées par les moteurs de recherche et visibles par n'importe quel internaute. L'accès devrait être limité aux employés autorisés, mais le vôtre est grand ouvert.

Les outils natifs de WordPress ne permettent pas de restreindre de manière sélective un type de publication personnalisé spécifique aux utilisateurs non enregistrés. Les rôles et les capacités existent, mais la liaison «les visiteurs ne peuvent pas voir le CPT X» n'est pas disponible par défaut. La solution comprend trois composants: l'enregistrement du CPT, la configuration des rôles et une extension de restriction de lecture. Le quatrième composant (optionnel) est la connexion sociale, pour que les employés n'aient pas à saisir de mot de passe à chaque fois.

Voici une décomposition étape par étape de chaque composant, avec des extensions et des paramètres spécifiques. Tous les outils sont gratuits, disponibles dans le répertoire officiel WordPress.org et ne nécessitent aucun codage, bien qu'une approche purement basée sur le code soit abordée à la fin pour ceux qui souhaitent éviter les extensions.

💡 Aperçu rapide:

• Enregistrez un type de publication personnalisé via Custom Post Type UI sans écrire une seule ligne de code
• Créez un rôle personnalisé dans PublishPress Capabilities et attribuez-le aux employés
• Restreignez l'accès au CPT pour les visiteurs en utilisant l'extension WP Access Areas: les visiteurs non autorisés sont redirigés vers la page de connexion
• Activez éventuellement la connexion sociale via Super Socializer pour une connexion sans mot de passe avec un compte Google

Étape 1: Enregistrer un type de publication personnalisé

La première étape, la plus simple, consiste à créer le CPT lui-même. Vous n'avez pas besoin de toucher au fichier functions.php pour cela: l'extension Custom Post Type UI sur WordPress.org fournit une interface graphique pour enregistrer tous les types de publication et taxonomies.

L'installation est standard: «Extensions → Ajouter», recherchez par nom, activez. Après l'activation, un nouvel élément de menu apparaît dans la barre latérale: «CPT UI → Ajouter/Modifier des types de publication». Remplissez les champs: identifiant (par exemple, equipment), noms au pluriel et au singulier, libellés, puis cliquez sur «Ajouter le type de publication».

L'extension appelle register_post_type() avec les bons paramètres automatiquement. Aucun code manuel n'est requis: vous obtenez un type de publication entièrement fonctionnel avec le support de l'éditeur, des archives et de l'API REST. Si vous devez ultérieurement déplacer l'enregistrement dans functions.php, CPT UI affiche le code PHP généré dans l'onglet «Outils».

Lors de l'enregistrement, soyez attentif à deux options critiques liées à la sécurité. Dans le bloc «Paramètres» de CPT UI, il y a une option «Interrogeable publiquement» qui détermine si les publications peuvent être ouvertes via des liens directs. Elle est activée par défaut, et même après avoir restreint la lecture via une extension, vous devez la laisser activée; sinon, WordPress renverra une erreur 404 au lieu de rediriger vers la page de connexion, et les utilisateurs ne comprendront pas ce qui s'est passé. Le second paramètre, «A une archive», active une page d'archive listant toutes les publications du CPT. Si vous n'avez pas besoin d'archive, désactivez-la pour que les moteurs de recherche n'indexent pas une page de service avec des aperçus de documents restreints.

Étape 2: Créer un rôle personnalisé

Il ne suffit pas de restreindre l’accès des visiteurs au CPT: vous avez besoin d’un rôle qui y aura accès. Par défaut, WordPress propose un ensemble fixe: Administrateur, Éditeur, Auteur, Contributeur, Abonné. Nous allons créer un nouveau rôle avec l’extension PublishPress Capabilities (anciennement Capability Manager Enhanced, même slug, mêmes fonctionnalités, seul le nom a changé).

Après activation, allez dans «Capabilities → Roles». Sur la partie droite de l’écran, vous trouverez le bloc «Create New Role»:

Saisissez un nom (par exemple «Equipment Reader»), choisissez un rôle de base à cloner (Abonné est le plus adapté, car il a le minimum de permissions), puis cliquez sur «Create». Le nouveau rôle existe maintenant et vous pouvez le doter de capacités. Pour lire un CPT, la combinaison standard read + read_equipment (la capacité enregistrée par CPT UI) est suffisante.

Attribuez le rôle créé aux collaborateurs qui ont besoin d’accéder au contenu restreint. Ensuite, vous pouvez désactiver l’extension: les rôles et les capacités restent dans la base de données WordPress et ne dépendent pas du fait que PublishPress Capabilities soit actif.

Étape 3: Restreindre l’accès en lecture au CPT

C’est l’étape clé. L’extension WP Access Areas vous permet de définir précisément qui peut lire, modifier et commenter les publications de chaque type, jusqu’au niveau de chaque page. Elle compte 400 installations actives et n’a pas connu de mise à jour majeure depuis un certain temps, mais pour la tâche qui consiste à «restreindre l’accès des visiteurs au CPT», elle fonctionne de manière prévisible et sans conflit.

Après l’installation, allez dans «Réglages → Access Areas». Dans la section «Default Behaviour», sélectionnez:

«If not logged in, redirect to login. Otherwise redirect to the fallback page.»

Ce paramètre renvoie les utilisateurs non autorisés vers wp-login.php lorsqu’ils tentent d’ouvrir une page protégée du CPT.

Ensuite, vous voyez un tableau de tous les types de publication enregistrés. Pour votre CPT, dans la colonne «Reading», choisissez «Logged in Users» dans la liste déroulante. C’est tout: à partir de maintenant, tout visiteur qui suit un lien direct vers une page du CPT est redirigé vers le formulaire d’authentification.

Remarque importante: les réglages effectués via le tableau ne s’appliquent qu’aux nouvelles publications. Pour les pages déjà créées, vous devez définir manuellement les permissions dans la barre latérale de l’éditeur, où un bloc «Access Areas» apparaît. Après configuration, pensez à vérifier le résultat en navigation privée dans votre navigateur: l’ouverture d’un lien direct vers une page protégée du CPT doit afficher wp-login.php, et non le contenu.

Alternatives à WP Access Areas si vous avez besoin d’une solution plus activement maintenue: PublishPress Permissions (la version gratuite couvre les CPT et les rôles) ou ContentGate (une extension légère avec des règles basées sur le statut de connexion et les rôles).

Étape 4: Connexion sociale (optionnelle)

Saisir constamment un identifiant et un mot de passe sur un portail d’entreprise crée une friction inutile. La solution logique: une connexion en un clic via un compte Google. L’extension Super Socializer gère cette tâche avec plus de 20 000 installations actives et la prise en charge de Google, Facebook, X (Twitter) et une dizaine d’autres fournisseurs.

Après activation, allez dans «Super Socializer → Social Login»:

Réglages de base: cochez la case «Disable user registration via social networks». C’est important pour que seuls les comptes existants puissent se connecter via les réseaux sociaux, sans en créer de nouveaux. Sélectionnez ensuite le fournisseur (Google) et saisissez le Client ID et le Client Secret. Où les obtenir:

• Ouvrez Google Cloud Console, créez un projet (ou sélectionnez-en un existant)
• Dans la section «APIs & Services → Credentials», cliquez sur «Create Credentials → OAuth client ID»
• Le type d’application est Web application; dans Authorized redirect URIs, collez l’URL de rappel fournie par les paramètres de Super Socializer
• Enregistrez pour obtenir votre Client ID et votre Client Secret

Copiez les clés dans les champs de l’extension:

Point critique: le champ Authorized redirect URIs ne doit pas comporter de slash final, sinon vous obtiendrez une erreur redirect_uri_mismatch. Après l’enregistrement, un bouton «Sign in with Google» apparaît sur la page de connexion.

Important: la version originale de cet article (2020) décrivait l’intégration avec Google+, qui a été arrêté en avril 2019. La version actuelle de Super Socializer utilise le protocole standard Google OAuth 2.0 via Google Identity Services. L’interface de Google Cloud Console a été mise à jour depuis, mais la logique des étapes (projet → Credentials → OAuth client ID → redirect URI) reste la même.

Approche alternative: tout en code

Si vous ne souhaitez pas ajouter de plugins supplémentaires, la tâche peut être réalisée dans le fichier functions.php du thème ou d’un thème enfant. Le code enregistre le CPT, crée un rôle et accroche une vérification d’autorisation au template:

1
// Registering a custom post type
2
function register_equipment_cpt() {
3
    register_post_type('equipment', [
4
        'labels'      => ['name' => 'Equipment', 'singular_name' => 'Equipment'],
5
        'public'      => true,
6
        'has_archive' => true,
7
        'supports'    => ['title', 'editor', 'thumbnail'],
8
        'capability_type' => 'equipment',
9
        'map_meta_cap' => true,
10
    ]);
11
}
12
add_action('init', 'register_equipment_cpt');
13
 
14
// Creating a role on theme activation
15
function add_equipment_reader_role() {
16
    add_role('equipment_reader', 'Equipment Reader', ['read' => true, 'read_equipment' => true]);
17
}
18
add_action('after_switch_theme', 'add_equipment_reader_role');
19
 
20
// Redirecting guests from CPT to login page
21
function restrict_equipment_to_logged_in() {
22
    if (is_singular('equipment') && !is_user_logged_in()) {
23
        wp_redirect(wp_login_url(get_permalink()));
24
        exit;
25
    }
26
}
27
add_action('template_redirect', 'restrict_equipment_to_logged_in');

Ce que fait ce code: le premier bloc enregistre le CPT equipment avec son propre type de capacité (capability_type). Le deuxième bloc crée le rôle Equipment Reader avec les permissions de lecture de ce CPT au moment de l’activation du thème. Le troisième bloc vérifie l’autorisation sur le hook template_redirect et renvoie les visiteurs non connectés vers wp-login.php.

L’avantage de l’approche en code: zéro plugin supplémentaire, contrôle total. L’inconvénient: la connexion sociale nécessitera toujours un plugin (écrire une intégration OAuth manuellement est chronophage et peu sécurisé), et chaque modification des rôles implique d’éditer le code.

⁉️🤔 Questions fréquentes

Puis-je restreindre un CPT sans plugin, uniquement via le fichier functions.php?

Oui. La combinaison de register_post_type() + add_role() + le hook template_redirect avec une vérification is_user_logged_in() constitue une solution parfaitement fonctionnelle. Le code est fourni dans la section ci-dessus. La connexion sociale sans plugin est nettement plus difficile à mettre en œuvre: une intégration OAuth manuelle exige de gérer les jetons, l’état et la sécurité.

Pourquoi WP Access Areas plutôt qu’un plugin plus récent comme ContentGate?

WP Access Areas est un outil minimaliste pour une tâche spécifique: «restreindre un type de publication aux visiteurs non connectés». Il n’embarque pas de constructeur de règles, d’éditeur visuel ni de système d’abonnement. Si vous avez besoin d’une logique plus complexe (par exemple, des niveaux d’accès différents selon les rôles sur le même CPT), utilisez ContentGate ou PublishPress Permissions, qui sont activement maintenus. Pour le scénario de base de ce guide, WP Access Areas est suffisant.

Que faire si les visiteurs non connectés voient encore les pages du CPT après la configuration?

Trois causes classiques. Premièrement: le paramètre «Logged in Users» dans le tableau de WP Access Areas ne s’applique qu’aux nouvelles publications; pour les pages existantes, vous devez définir les permissions manuellement via la barre latérale de l’éditeur. Deuxièmement: un plugin de cache sert une version en cache de la page aux visiteurs non connectés; videz le cache et configurez des exclusions pour le CPT protégé. Troisièmement: le CPT est enregistré avec 'publicly_queryable' => true et le slug entre en conflit avec une page publique; vérifiez les collisions.

Puis-je utiliser Super Socializer uniquement pour la connexion, sans partage ni commentaires?

Oui, les modules du plugin sont indépendants. Dans l’onglet «Social Sharing», décochez toutes les cases et les boutons «Share» disparaîtront. Dans l’onglet «Social Commenting», désactivez l’intégration. Ne conservez que «Social Login» avec les fournisseurs dont vous avez besoin. Le plugin est léger et la désactivation des modules inutiles n’affecte pas les performances.

Est-il sûr de désactiver PublishPress Capabilities après avoir créé un rôle?

Oui. Les rôles et capacités WordPress sont stockés dans la table wp_options (l’option wp_user_roles) et ne dépendent pas du plugin qui les a créés. Après avoir désactivé PublishPress Capabilities, tous les rôles créés et les permissions accordées sont conservés. Vous pouvez réactiver le plugin si vous avez besoin de modifier les permissions ultérieurement.

Faut-il écrire du code ou s’en tenir aux plugins

Le choix entre les plugins et functions.php se résume à deux facteurs: le nombre de CPT à protéger et la fréquence à laquelle les permissions évoluent.

Si vous n’avez qu’un seul CPT (comme l’exemple de l’équipement), que les rôles sont stables et que vous êtes prêt à écrire 30 lignes de code une fois, l’approche functions.php est plus propre: elle ne génère pas de plugins, ne dépend pas de mises à jour tierces et reste totalement transparente. Vous pouvez conserver Super Socializer pour la connexion sociale, car il résout une tâche précise et n’entre pas en conflit avec le code personnalisé.

Si vous avez plusieurs CPT, que les permissions sont fréquemment révisées ou que le site est géré par une personne non développeuse, optez pour la combinaison de plugins. CPT UI + PublishPress Capabilities + WP Access Areas (ou ContentGate) se configurent depuis l’administration en 15 minutes sans toucher au code. De plus, PublishPress Capabilities sauvegarde automatiquement les rôles à chaque modification, ce qui permet un retour en arrière en deux clics.

Dans tous les cas, appliquez le principe: un outil pour une tâche. N’installez pas une solution tout-en-un puissante pour une simple case à cocher, et ne réinventez pas la roue si un plugin existant fait exactement la même chose plus rapidement et de manière plus sécurisée.

La gestion de version mérite une considération à part. Le code de functions.php vit dans le dépôt du thème, les modifications sont suivies via Git et, lors de la migration du site, les rôles sont automatiquement recréés sur le hook after_switch_theme. L’approche par plugins n’offre pas cette transparence: les rôles sont stockés en base de données et, lors du déploiement d’une copie de staging ou d’un transfert vers un nouveau domaine, ils doivent être recréés manuellement ou via un script de migration. Ce facteur devient souvent déterminant en faveur du code pour les équipes qui pratiquent le CI/CD et le déploiement basé sur Git.