Comment aborder la transition WordPress et JavaScript

Par Thomas DENEULIN - @TDeneulin

Pourquoi... ?

Parce que...

Un écosystème JavaScript de plus en plus présent

WordPress a fait le choix de ReactJS

Le nouvel éditeur Gutenberg est en ReactJS

Et quand on a 125 000 stars sur Github, c'est qu'on n'est pas si mal.

Qu'est-ce qui nous attend avec cette transition ?

Un retour aux fondamentaux

Un système de gestion de contenus.

Partons du principe que votre WordPress ne puisse pas avoir de thème.

Donc, pas de site à afficher en front.

Ça ne l'empêche pas de gérer notre contenu.

Mais si on gère du contenu dont vous ne pouvez pas vous servir, ça ne sert à rien !

L'API Rest

monsite.com/wp-json/

On peut donc récupérer toutes (dans la mesure du possible) les données que l'on souhaite !

WordPress reste un système de gestion de contenus

qui délivre les données dont on a besoin.

Il suffit donc de les consommer

Comment ?

Habituellement, nous consommons les données à travers notre thème WordPress.

En PHP.

Mais la réalité, c'est que l'on peut utiliser ce que l'on souhaite.. Comme du JavaScript

Mes conseils pour utiliser le JavaScript avec un

WordPress tout-en-un

(comme aujourd'hui dans la majorité des cas)
  • Faire le choix de ReactJS pour être sur la même technologie que celle choisie par le core
  • Ne pas surcharger le routeur / la template hierarchy avec votre technologie JS (ReactJS / VueJS)
  • Utiliser ces technologies pour des modules qui demandent une expérience utilisateur "évoluée"
  • Avoir un workflow avec Webpack (ou autre comme Gulp, Grunt, Brunch, ... )
  • Ne pas faire de modules qui peuvent avoir de l'importance pour le SEO (sinon vous allez devoir regarder du côté du Server Side Rendering)
Avec jQuery on manipule le DOM, alors qu’avec React on manipule les données

Utiliser WordPress comme un

Headless CMS

Source : https://www.lafabriquedunet.fr/blog/headless-cms/

Les implications sur votre architecture

1 serveur pour héberger WordPress en tant qu'API

1 serveur pour héberger la partie front

10 sites = ( 1+1 ) * 10 ( 20 serveurs )

1 serveur pour héberger WordPress en tant qu'API ( api.monsite.com )

Le même serveur pour la partie front (monsite.com)

10 sites = 1 * 10 ( 10 serveurs )

Penser au multisite

1 serveur pour les gouverner* tous en tant qu'API

X serveur(s) pour X partie front

10 sites = 1 + ( 1 * 10 ) ( 11 serveurs )

*héberger

Ma stack

  • NextJS (Framework React for App / React / Static website / ...)
  • ReactJS

Faire le front en JavaScript dangereux pour le SEO

Les avantages ne sont pas que dans la "tech" pure

Le découpage d'une équipe

Pas de thème / plugin / WordPress développeur

  • Un développeur Backend (avec une forte orientation sur WordPress, pourquoi pas)
  • Un développeur Frontend

Plus d'ouverture sur le marché du travail

Penser au site statique

Gatbsy JS

Devinez la techno... ?

Du ReactJS

Les implications

  • Un "backend" qui peut être en local ou en ligne
  • Un front totalement statique (performance ++)
  • Un nombre de fichiers considérables (espace disque -)

Au final...

  • Ouvrez-vous aux nouvelles architectures (tout n'est pas mauvais)
  • Formez-vous au JavaScript et à un framework * (pas au jQuery)
  • Suivez le projet Gutenberg et les évolutions de WordPress. On tend vers de +/+ de ReactJS :)

Merci à tous !