Block WordPress affichage conditionnel avec IA : guide complet

RÉPONSE DIRECTE : Le block WordPress affichage conditionnel avec IA permet d’afficher du contenu public ou privé selon le statut utilisateur en utilisant l’intelligence artificielle pour accélérer le développement.

DÉFINITION RAPIDE : Un block conditionnel WordPress affiche différents contenus selon des conditions (utilisateur connecté, rôle, mot de passe) et peut être développé efficacement avec l’aide de l’IA.

Tu veux créer du contenu à plusieurs niveaux d’accès sur une même page, le tout avec l’IA ? Cette approche s’inscrit parfaitement dans le vibe coding, cette méthode qui change notre façon de développer avec l’IA.

Table des matières

• Les métriques du projet
• Initialisation du block WordPress
• Développement de l’interface d’édition
• Rendu côté frontend
• API REST pour la vérification
• JavaScript frontend
• Questions fréquentes

Les métriques du projet : 1 heure pour un block complet

Développer un block WordPress affichage conditionnel avec IA prend exactement :

• Temps de développement : 1 heure chrono
• Outils utilisé : Cursor (autocomplétion) & Agent blockCraft (détaillé dans ce guide de prompt engineering)
• Méthode : Itération et validation continue

Le principe reste le même : on utilise un agent bien prompté, on travaille par itérations, et surtout – on contrôle tout le temps. Tu dois comprendre, valider, vérifier la sécurité et pouvoir intervenir quand nécessaire.

Exemple concret : quand l’IA part en vrille

Voici ce que l’IA m’a proposé initialement pour le block WordPress affichage conditionnel :

window.conditionalContentBlocks = window.conditionalContentBlocks || {};
window.conditionalContentBlocks['<?php echo esc_js($block_id); ?>'] = {
    blockId: '<?php echo esc_js($block_id); ?>',
    conditionType: '<?php echo esc_js($condition_type); ?>',
    restUrl: '<?php echo esc_js(rest_url('conditional-content/v1/unlock')); ?>',
    nonce: '<?php echo esc_js($rest_nonce); ?>',
    password: <?php echo json_encode($password); ?>,
    allowedRoles: <?php echo json_encode($allowed_roles); ?>
};

Gros problème : toutes les informations d’accès sont exposées en JavaScript ! C’est exactement l’inverse de ce qu’on veut pour un système de protection.

Étape 1 : initialisation du block WordPress

Création de la structure de base

Pour créer notre block WordPress affichage conditionnel IA, on exécute cette commande dans wp-content/plugins :

npx @wordpress/create-block conditional-content --variant="dynamic"

Cette commande génère automatiquement toute la structure en respectant les standards WordPress (WordPress Developer Handbook).

Ce que doit faire le block

Notre block doit permettre :

• d’ajouter tous les blocks disponible,
• de configurer la sécurité : soit par mot de passe soit par rôle(s) utilisateur

Configuration du block.json : la fondation

Le fichier block.json définit nos paramètres, dans la globalité l’agent fait tout ce qu’il nous faut. Il propose une validation enum que je trouve pertinente et c’est dans la doc WordPress donc on utilise :

{
	"$schema": "https://schemas.wp.org/trunk/block.json",
	"apiVersion": 3,
	"name": "create-block/conditional-content",
	"version": "0.1.0",
	"title": "Conditional Content",
	"category": "widgets",
	"icon": "lock",
	"description": "Display content based on password or user role with cache-safe loading.",
	"example": {},
	"supports": {
		"html": false
	},
	"attributes": {
		"conditionType": {
			"type": "string",
			"default": "password",
			"enum": ["password", "role"]
		},
		"password": {
			"type": "string",
			"default": ""
		},
		"allowedRoles": {
			"type": "array",
			"default": []
		},
		"placeholder": {
			"type": "string",
			"default": "Contenu protégé - Authentification requise"
		},
		"blockId": {
			"type": "string",
			"default": ""
		}
	},
	"textdomain": "conditional-content",
	"editorScript": "file:./index.js",
	"editorStyle": "file:./index.css",
	"style": "file:./style-index.css",
	"render": "file:./render.php",
	"viewScript": "file:./view.js"
}

Étape 2 : développement de l’interface d’édition (Edit.js)

L’interface d’édition du block conditionnel WordPress utilise les composants standard :

1. InspectorControls pour les paramètres
2. PanelBody pour organiser l’interface
3. SelectControl, TextControl, CheckboxControl pour les inputs

Pas la peine de rentrer dans le détail, c’est de l’archi-classique.

Prévention de l’auto-inclusion

Pour éviter qu’un block conditional-content se retrouve dans lui-même, on pense à l’exclure de tous les blocks disponible :

const { allBlockTypes } = useSelect((select) => {
	return {
		allBlockTypes: select('core/blocks').getBlockTypes()
	};
}, []);

const allowedBlocks = allBlockTypes
	? allBlockTypes
		.filter(blockType => blockType.name !== 'create-block/conditional-content')
		.map(blockType => blockType.name)
	: [];

Comment récupérer les rôles utilisateurs ?

D’après ce que je sais, WordPress ne propose rien en natif côté React pour récupérer les rôles utilisateur.

Du coup, on fait comment ? On passe par la bonne vieille méthode PHP :

• On utilise wp_localize_script pour injecter les données nécessaires
• Ces infos deviennent alors disponibles côté JavaScript

function conditional_content_enqueue_editor_assets() {
    global $wp_roles;
    $roles_data = array();
    if (!isset($wp_roles)) {
		$roles_data = array(
			array(
				'value' => 'administrator',
				'label' => translate_user_role('Administrator')
			),
			array(
				'value' => 'editor',
				'label' => translate_user_role('Editor')
			),
			array(
				'value' => 'author',
				'label' => translate_user_role('Author')
			),
			array(
				'value' => 'contributor',
				'label' => translate_user_role('Contributor')
			)
		);
    } else {
		foreach ($wp_roles->roles as $role_key => $role_info) {
			$roles_data[] = array(
				'value' => $role_key,
				'label' => translate_user_role($role_info['name'])
			);
		}
	}

    wp_localize_script(
        'create-block-conditional-content-editor-script',
        'conditionalContentData',
        array(
            'roles' => $roles_data,
            'ajaxUrl' => admin_url('admin-ajax.php'),
            'nonce' => wp_create_nonce('conditional_content_nonce')
        )
    );
}
add_action('enqueue_block_editor_assets', 'conditional_content_enqueue_editor_assets');

Rien de révolutionnaire dans cette approche !

Voici la logique :

• Le bon hook : on se place au bon endroit dans le cycle WordPress
• La global $wp_roles : on tape directement dans cette variable globale pour récupérer tous les rôles
• Structure adaptée : on formate le tableau pour qu’il soit directement utilisable côté JS (pas besoin de le retourner dans tous les sens après)
• Valeurs par défaut : on prévoit le coup : si pas de rôle on en donne par défaut

C’est du code défensif de base – on anticipe les cas foireux pour éviter que tout plante si WordPress décide de faire des siennes.

L’idée c’est d’avoir un tableau propre, structuré et prêt à consommer côté React sans se prendre la tête avec des transformations de données.

C’est beaucoup plus simple comme ça 🙂

const roleOptions = window.conditionalContentData?.roles || [];

[...]
 
{roleOptions.map((role) => (
    <CheckboxControl
        key={role.value}
        label={role.label}
        checked={allowedRoles.includes(role.value)}
        onChange={(isChecked) => handleRoleChange(role.value, isChecked)}
    />
))}

Étape 3 : le rendu côté frontend (render.php)

Le fichier render.php de notre block WordPress affichage conditionnel IA gère :

• La récupération des attributs Gutenberg
• L’affichage conditionnel selon les paramètres
• La génération d’identifiants uniques (wp_generate_uuid4())

Ce fichier est banal ^^ l’agent a fait ce qu’il fallait, je n’ai rien à redire sur la partie php.

Par contre, le petit JavaScript de fin m’a fait vriller (le code que j’ai présenté au début de l’article) :

window.conditionalContentBlocks = window.conditionalContentBlocks || {};
window.conditionalContentBlocks['<?php echo esc_js($block_id); ?>'] = {
    blockId: '<?php echo esc_js($block_id); ?>',
    conditionType: '<?php echo esc_js($condition_type); ?>',
    restUrl: '<?php echo esc_js(rest_url('conditional-content/v1/unlock')); ?>',
    nonce: '<?php echo esc_js($rest_nonce); ?>',
    password: <?php echo json_encode($password); ?>,
    allowedRoles: <?php echo json_encode($allowed_roles); ?>
};

Correction critique : sécurisation des données

Version corrigée et sécurisée :

window.conditionalContentBlocks = window.conditionalContentBlocks || {};
window.conditionalContentBlocks['<?php echo esc_js($block_id); ?>'] = {
    blockId: '<?php echo esc_js($block_id); ?>',
    restUrl: '<?php echo esc_js(rest_url('conditional-content/v1/unlock')); ?>',
    nonce: '<?php echo esc_js($rest_nonce); ?>'
};

On ne laisse surtout pas des choses sensibles. On corrige !

Étape 4 : API REST pour la vérification

La route REST du block conditionnel WordPress :

register_rest_route('conditional-content/v1', '/unlock', array(
  'methods' => 'POST',
  'callback' => array($this, 'unlock_content'),
  'permission_callback' => array($this, 'check_permissions'),
  'args' => array(
    'block_id' => array(
      'required' => true,
      'type' => 'string',
      'sanitize_callback' => 'sanitize_text_field'
    ),
    'password' => array(
      'required' => false,
      'type' => 'string',
      'sanitize_callback' => 'sanitize_text_field'
    ),
    'post_id' => array(
      'required' => true,
      'type' => 'integer',
      'sanitize_callback' => 'absint'
    )
  )
));

Très malin cet agent ! Il a pondu un code qui tient la route avec des fonctions WordPress bien choisies.

Les points forts de son approche :

• parse_blocks() : parfait pour décomposer tout le contenu en blocs exploitables
• render_block() : génial pour forcer le rendu d’un bloc spécifique (même s’il est planqué quelque part)
• search_block_recursive() : là c’est du beau boulot ! Cette fonction récursive qui fouille dans tous les recoins, même dans les blocs imbriqués (Groupe, Colonnes, etc.)

private function search_block_recursive($blocks, $block_id) {
  foreach ($blocks as $block) {
    if ($block['blockName'] === 'create-block/conditional-content') {
      if (isset($block['attrs']['blockId']) && $block['attrs']['blockId'] === $block_id) {
        return $block;
      }
    }

    // Recherche dans les blocs enfants
    if (!empty($block['innerBlocks'])) {
      $found = $this->search_block_recursive($block['innerBlocks'], $block_id);
      if ($found) {
        return $found;
      }
    }
  }
  return null;
}

Étape 5 : JavaScript frontend (view.js)

Ah oui, bien vu ! Pourquoi réinventer la roue quand WordPress nous mâche déjà le travail ?

Avec wp-scripts, on a cette logique native :

• view.js : automatiquement compilé avec le bloc
• Chargement conditionnel : il ne se charge que si le bloc est effectivement présent sur la page
• Standards WordPress : on reste dans l’écosystème officiel

C’est exactement le principe du « moins c’est plus » – autant exploiter ce qui existe déjà plutôt que de bricoler un système de chargement custom.

En plus, ça évite :

• Les scripts orphelins qui traînent sur toutes les pages
• La logique de détection manuelle « est-ce que mon bloc est là ? »
• Les problèmes de timing de chargement

WordPress a déjà pensé à tout ça pour nous. Il suffit de mettre notre code dans view.js et le tour est joué !

Pour notre block WordPress affichage conditionnel IA, l’agent a fait tout ce qu’il fallait, pas difficile faut dire car le JS c’est du classique on va :

• Attendre le DOM : on s’assure que tout est en place
• Event listeners : sur les boutons avec identification propre des block_id
• Fetch vers l’API REST : appel clean vers la route custom
• Gestion des états : contenu/erreur/loader pour une UX nickel

J’ai tout de même apporté une correction, de base l’agent masque le block « conditional content » après déverrouillage. Personnellement, je préfère le supprimer du DOM car une fois déverrouillé :

• Plus besoin du « conditional content » qui traîne
• DOM plus propre
• Moins d’éléments inutiles en mémoire

C’est vrai que visuellement ça change rien, mais niveau performance et propreté du code, c’est une bonne habitude. Pas de pollution du DOM avec des éléments qui servent plus à rien.

Du bon sens développeur quoi – on nettoie derrière nous !

Point d’amélioration : récupération du post ID

function getPostId() {
  const bodyClasses = document.body.className;
  const postIdMatch = bodyClasses.match(/postid-(\d+)/);
  if (postIdMatch) {
    return parseInt(postIdMatch[1]);
  }

  const postIdMeta = document.querySelector('meta[name="post-id"]');
  if (postIdMeta) {
    return parseInt(postIdMeta.content);
  }

  const pathParts = window.location.pathname.split('/').filter(part => part);
  const lastPart = pathParts[pathParts.length - 1];
  if (/^\d+$/.test(lastPart)) {
    return parseInt(lastPart);
  }

  if (typeof wp !== 'undefined' && wp.data) {
    const postId = wp.data.select('core/editor')?.getCurrentPostId();
    if (postId) return postId;
  }

  console.warn('Impossible de déterminer l\'ID du post');
  return 0;
}

Le seul point qui me chiffonne, c’est sa méthode pour récupérer le postId 😅

Sa stratégie « essayons tout » n’est pas terrible :

• Classe CSS du body → ça dépend totalement du thème, pas du tout garanti
• Balise meta name="post-id" → franchement, qui utilise ça ? Jamais croisé !
• Analyse de l’URL → fragile et pas très propre comme approche
• wp.data.select('core/editor')?.getCurrentPostId() → là c’est carrément non ! Exposer l’éditeur côté front, c’est pas une bonne idée

Pour ma part, je vais garder juste la classe body et virer le reste. Mais bon, on aurait très bien pu ajouter un data-post-id directement sur notre bloc et le récupérer proprement en JS ! 😊

C’est plus direct et on maîtrise complètement ce qu’on injecte.

Leçon critique : l’IA, oui, mais avec discernement

Oui, j’ai bien prompté l’agent, oui il m’aide énormément et me fait gagner un temps fou MAIS ça ne veut pas dire que je vais tout accepter les yeux fermés.

Quand tu repères des trucs inutiles, pas sécurisés ou bancals : tu corriges ou tu supprimes direct. Pas de quartier !

Ici, j’aurais pu me dire : « les autres méthodes m’impactent pas puisque ça s’arrête à la classe body ». MAIS concrètement, pourquoi garder du code mort ???

Le piège du « ça marche aujourd’hui » :

• Aujourd’hui : le code est frais, l’échange avec l’agent aussi, tu sais que c’est inutile
• Demain ? Dans une semaine ? Tu retombes sur ce code…
• Tu te demandes pourquoi c’est là
• Tu testes pour comprendre ton propre raisonnement
• Tu finis par te dire : « si je l’ai laissé, c’est que ça doit servir »

Résultat ? Tu complexifies sans raison et ta maintenance devient un enfer.

Conclusion : l’IA au service de l’efficacité

En une heure, j’ai créé le block WordPress affichage conditionnel avec IA complet et fonctionnel.

Le vrai succès réside dans la capacité à :

1. Guider intelligemment l’IA avec les bons prompts
2. Contrôler systématiquement le code généré
3. Corriger impitoyablement les erreurs et approximations
4. Simplifier constamment en supprimant l’inutile

L’intelligence artificielle n’est pas votre remplaçant, c’est votre révélateur. Elle amplifie vos compétences si vous savez la maîtriser, mais peut créer plus de problèmes que de solutions si vous l’utilisez aveuglément.

Pensez à votre futur vous qui vous remerciera de pas avoir fait du copier-coller aveugle. L’IA c’est génial, mais faut la maîtriser et garder son esprit critique !

Petit ajout rapide : J’ai découvert après avoir développé le plugin qu’un autre plugin porte déjà ce nom sur le repository WordPress officiel.

Du coup, si vous l’activez chez vous, WordPress vous proposera automatiquement une mise à jour… mais surtout ne la faites pas si vous voulez garder mon plugin !

Mon conseil : dans tous les cas, je vous recommande de :

• Modifier le nom du plugin
• Vous l’approprier complètement

Comme ça, pas de confusion et pas de risque de perdre votre travail ! 😉