Créer une fenêtre modale de recherche pour les sites WordPress à accès restreint

La plupart des tutoriels de recherche WordPress s'arrêtent après l'ajout d'un widget dans un en-tête.

Cela échoue lorsque vous avez du contenu protégé, comme des cours payants ou des vidéos privées. Une recherche par défaut divulguera les titres de votre contenu privé aux visiteurs non connectés.

J'ai conçu une fenêtre modale de recherche en direct pour un site d'adhésion de fitness. Le site utilise WordPress, WooCommerce, Divi, LearnDash et WishList Member.

Voici comment créer une recherche qui respecte votre mur de paiement (paywall).

L'architecture

J'ai utilisé un index unifié avec un filtrage tenant compte des accès. J'ai choisi cette approche pour garantir qu'un utilisateur non connecté ne voie jamais le titre ou l'extrait d'un article réservé aux membres.

L'interface utilisateur utilise une icône qui ouvre une superposition plein écran. Cela permet d'économiser de l'espace sur mobile et offre un rendu plus propre qu'une barre de saisie encombrée.

Le backend

Tout fonctionne via une seule route REST personnalisée dans un thème enfant.

Règles techniques clés :

  • Protéger les dépendances : Utilisez une vérification de fonction pour les plugins de recherche comme Relevanssi. Si le plugin est absent, la recherche doit basculer sur le cœur de WordPress au lieu de faire planter le site.
  • Filtrage côté serveur : Ne filtrez jamais les résultats à l'aide de JavaScript. Si vous masquez un résultat dans le navigateur, la donnée est déjà présente dans la réponse réseau. N'importe qui utilisant les DevTools peut la voir. Filtrez les données avant que le serveur n'envoie la réponse.
  • Exclusion du cache : Vous devez exclure votre route REST de recherche de la mise en cache des pages. Si vous mettez les résultats en cache, la recherche d'un membre pourrait être servie à un invité, divulguant ainsi du contenu privé.

Le frontend

Le côté client utilise du vanilla JavaScript.

Trois éléments assurent une bonne expérience utilisateur (UX) :

  • Debounce : Attendez 250 ms après une frappe de touche avant d'envoyer une requête. Cela évite une charge inutile sur le serveur.
  • AbortController : Annulez les requêtes précédentes lorsque l'utilisateur continue de taper. Cela empêche les anciens résultats d'écraser les nouveaux.
  • États d'erreur : Affichez un message clair si un fetch échoue. Un indicateur de chargement qui tourne sans fin est une mauvaise UX.

La leçon mobile

J'ai essayé d'injecter le bouton de recherche dans le menu mobile de Divi. Le thème interceptait les clics, rendant le bouton incliquable.

La solution était simple : arrêtez de lutter contre le thème.

Au lieu de placer le bouton à l'intérieur du menu, je l'ai injecté dans l'en-tête en tant qu'élément autonome. Cela l'a maintenu hors du contrôle du thème et l'a rendu facile à cliquer.

Résumé

  • Le contrôle d'accès doit s'effectuer sur le serveur.
  • Excluez les points de terminaison (endpoints) de recherche de votre cache.
  • Utilisez le debounce et AbortController pour gérer les requêtes.
  • Échappez toutes les données de l'API avant de les injecter dans le DOM pour prévenir les attaques XSS.
  • Si un constructeur de page (page builder) résiste à votre code, placez votre élément à côté plutôt qu'à l'intérieur.

Source : https://dev.to/highcenburg/building-a-search-modal-for-a-membership-gated-wordpress-site-b92