Comprendre "côté serveur" et "côté client" dans WordPress • WPShout

Cet article explique «côté serveur vs côté client» dans le développement WordPress. Cette distinction, et la façon dont le côté serveur et le côté client interagissent, est au cœur non seulement du développement WordPress, mais de toute compréhension réelle du fonctionnement du Web.

Donc, si vous voulez savoir ce qui sur un site WordPress est côté serveur et ce qui est côté client – et ce que ces termes eux-mêmes signifient – alors attachez votre ceinture. Et si vous vous êtes déjà demandé "est-ce que PHP est côté serveur ou côté client?" (toujours côté serveur!), ou "est-ce que JavaScript est côté serveur ou côté client?" (presque toujours côté client! allez-y NodeJS!), alors c'est aussi pour vous.

Nous avons emballé cet article avec une vidéo de présentation utile, des points clés, une infographie détaillée, un quiz et même un résumé limerick (!). C'est parce que ce n'est pas seulement un de nos articles normaux: c'est un exemple de chapitre de notre cours "apprendre le développement WordPress" Opérationnel, maintenant dans sa 3e édition révisée et étendue.

Si vous aimez cet article, assurez-vous de vérifier Opérationnel. Il y a environ 40 chapitres supplémentaires d'où celui-ci est issu. Nous le soutenons comme le meilleur guide pour le développement de WordPress.

---

Si vous cherchez à comprendre le fonctionnement interne de WordPress, l'une des choses les plus importantes que vous devrez comprendre est la distinction entre du côté serveur et côté client langages, environnements et processus.

Peut-être plus que tout autre élément de connaissance, comprendre cette distinction m'a aidé à comprendre comment WordPress fait sa magie. C'est la clé pour comprendre les "tripes" de tout site WordPress, ainsi que le rôle unique des différents langages techniques utilisés dans WordPress. Il est également profondément ancré dans toute discussion sur les thèmes, les plugins, la boucle et les autres structures sur lesquelles WordPress est construit.

En d'autres termes, vous ne pouvez tout simplement pas comprendre WordPress sans lui. Alors jetons un œil!

Terminologie clé

Nous présentons la relation entre le côté serveur et le côté client dans un grand diagramme, que nous présenterons dans une minute. Mais avant cela, nous aurons besoin de quelques éléments de terminologie essentiels:

• Utilisateur: une personne qui souhaite afficher et interagir avec des pages Web à l'aide d'un appareil compatible Internet, comme un ordinateur ou un smartphone.
• Client: le navigateur Internet de l'utilisateur, exécuté sur son appareil.
• Serveur: l'ordinateur, situé n'importe où dans le monde, où se trouve le site Web souhaité hébergé (stockée).
• Local: stocké sur, se produisant dans ou se rapportant à l'environnement de l'appareil de l'utilisateur.
• Éloigné: stocké sur, se produisant dans ou se rapportant à l'environnement du serveur.

De plus, pour un rappel, nous examinerons le rôle joué par chacune des langues suivantes qui constituent le cœur de WordPress:

1. HTML: Ce que les navigateurs Web lisent pour transformer du texte en pages Web entièrement formatées.
2. CSS: Un langage de style qui rend les règles de style HTML plus flexibles et reproductibles.
3. PHP: L'épine dorsale de WordPress; le langage de programmation principal du progiciel WordPress, et de presque tous les thèmes et plugins WordPress.
4. Javascript: Langage polyvalent couramment utilisé pour rendre les pages Web plus dynamiques et interactives.
5. MySQL: Le logiciel qui structure WordPress bases de données. La façon de parler à une base de données MySQL passe par Requêtes SQL. Cependant, étant donné que les développeurs WordPress peuvent presque toujours utiliser des fonctions PHP prédéfinies intégrées à WordPress lui-même au lieu d'écrire directement des requêtes, vous n'avez pas besoin de connaître MySQL en profondeur pour être un développeur WordPress fondamentalement compétent.

Bon, maintenant pour le grand diagramme:

Ne vous inquiétez pas, nous passerons le reste de cet article à expliquer le fonctionnement du diagramme. Vous pouvez également le voir en taille réelle Côté serveur et côté client dans les ressources.

Les étapes impliquées dans le chargement d'une page WordPress

Le diagramme montre le flux requis pour générer n'importe quelle page dans WordPress. Depuis quel WordPress Est-ce que est de générer des pages Web pour les clients (navigateurs) qui en font la demande, comprendre ce flux équivaut à comprendre les tripes de WordPress lui-même.

Le flux fonctionne comme suit:

Lorsque vous entrez une URL dans votre navigateur, cela indique à votre navigateur le site que vous souhaitez afficher et la page ou la publication spécifique sur ce site. Votre navigateur (le client) envoie ensuite une demande, appelée Requête HTTP, à la serveur où le site est stocké, en demandant au serveur la page Web que vous avez demandée.

HTTP, pour HyperText Transfer Protocol, est le principal moyen utilisé par les ordinateurs pour communiquer entre eux sur le Web: il s'agit d'un type standard de «prise de contact» entre deux ordinateurs qui leur permet d'échanger des informations. Vous n'avez pas besoin de connaître les détails ici, mais nous les couvrons plus en détail dans Travailler avec les API HTTP dans WordPress.

Le but fondamental du code PHP de WordPress est de servir différents types de pages Web en fonction de différentes requêtes HTTP. Lorsque le serveur reçoit la demande HTTP de votre client, il effectue un traitement PHP initial pour engager son propre environnement interne et interpréter la demande du client pour comprendre ce que le client demande.

Pour récupérer le ou les messages qui forment l'épine dorsale de toute page Web WordPress, WordPress doit dire au serveur de se rendre sur WordPress base de données, où les messages, les métadonnées des messages (comme l'auteur de la publication et la date de publication) et les informations de permalien sont stockés.

Cette base de données vit généralement sur le même serveur que le site WordPress lui-même, mais elle n'est pas directement accessible, sauf via MySQL. (Par exemple, si vous utilisez un client FTP pour afficher les fichiers de votre site sur votre serveur, vous ne trouverez pas la base de données du site parmi ces fichiers.)

En utilisant Requêtes SQL, Les scripts PHP de WordPress récupèrent les informations de base de données de MySQL dont ils ont besoin pour générer la page Web demandée par le client, y compris le contenu de la publication (texte et balisage HTML) qui sera le contenu principal de la page.

Après son voyage dans la base de données, WordPress sait quel modèle PHP utiliser et a un contenu de publication réel qu'il peut écrire sur la page. C'est là que le code PHP écrit dans votre thème et vos plugins entre en jeu.

Cette étape du processus consiste à utiliser votre thème, vos plugins et le reste de la base de code PHP WordPress pour traiter les données de publication récupérées en balisage HTML pur. Il s'agit de l'étape «principale» – la plupart des chapitres de ce livre s'y trouvent – car c'est l'étape qui implique la plupart du code de thème et de plugin qu'un développeur WordPress écrit.

Pourquoi ce traitement est-il nécessaire? Car votre navigateur ne peut pas comprendre PHP, seul un serveur pouvez. Placé différemment, PHP les sorties HTML à renvoyer à un navigateur, car le HTML est ce qu'un navigateur peut comprendre.

Pendant tout ce temps (peut-être une seconde), vous et votre navigateur êtes restés assis là pendant que le serveur s'éloignait. Maintenant, enfin – après avoir fait son chemin vers la base de données, récupéré les publications et alimenté ces publications via les fichiers PHP qui composent le thème et les plugins du site – le serveur est prêt à renvoyer un document HTML propre à votre navigateur. Il le fait en utilisant un Réponse HTTP: un élément de communication utilisant le même protocole HTTP que la demande initiale, mais contenant le code HTML qui satisfait la demande.

Pour la plupart des sites, le navigateur remarquera qu'il a besoin de ressources supplémentaires associées à la page, telles que des feuilles de style CSS, des fichiers JavaScript, des images, des fichiers audio et des polices Web. Il demande ces ressources au serveur à l'aide de requêtes HTTP supplémentaires et attendra par défaut de les recevoir avant de passer au rendu de la page.

Une fois que le navigateur a reçu le code HTML et toutes les ressources associées qu'il a demandées, nous avons enfin terminé avec le serveur. Si le serveur explosait maintenant, vous et votre navigateur auriez toujours la page Web et tout ce qu'elle contenait – au moins jusqu'à ce que vous fermiez la fenêtre.

Maintenant, le navigateur peut faire son travail principal: le rendu HTML et ressources connexes en quelque chose qui ressemble à une page Web.

Maintenant, le navigateur peut faire son travail principal: le rendu HTML et ressources connexes (images, etc.) en quelque chose qui ressemble aux humains comme une page Web. Chaque page Web, telle qu'interprétée par votre navigateur, est une combinaison de texte brut et de ressources associées, organisée visuellement selon diverses règles données au navigateur par HTML et CSS (et, parfois, JavaScript).

Lorsque votre navigateur a terminé de rendre toutes les ressources qui lui ont été envoyées, vous pouvez enfin voir la page WordPress que vous avez demandée lorsque vous avez initialement tapé une adresse dans la barre d'URL.

Mais parfois il y en a plus! Sur certains sites, lorsque vous cliquez sur un objet, quelque chose de très interactif se produit: par exemple, lorsque vous cliquez sur un onglet de menu sur un élément de type «accordéon», il se déplie pour afficher le corps entier de cette pièce de l'accordéon. Et certaines pages savent réellement ce que vous faites lorsque vous interagissez avec elles: par exemple, lorsque vous entrez deux fois votre mot de passe pour vous inscrire à quelque chose, la page peut afficher un message d'erreur tant que les deux mots de passe ne correspondent pas, avant même de cliquer sur «Soumettre».

Rien de tout cela n'implique le serveur – qui pourrait encore être un cratère fumant à notre connaissance. Ces effets sont plutôt gérés par script côté client: morceaux de code qui ont été envoyés à votre client (votre navigateur) par le serveur dans le cadre de sa réponse HTTP, mais qui exécuter dans le client lui-même.

Le principal langage de script côté client est Javascript. (Certains effets simples côté client, comme le changement de couleur d'un bouton lorsque vous le survolez avec votre souris, peuvent être gérés via CSS à l'aide de pseudo-sélecteurs.)

JavaScript est donc en quelque sorte l'opposé de PHP: le serveur ne prend pas la peine de le comprendre, mais l'envoie simplement à votre navigateur, qui l'exécute dans le cadre du processus de chargement de la page demandée.

Pour les sites WordPress, du côté serveur veux dire: "Un serveur se produit pendant le traitement interne lorsqu'il essaie de renvoyer une page à un client qui l'a demandée."

En règle générale, PHP et MySQL sont toujours côté serveur: ils s'exécutent uniquement dans un environnement de serveur. Un navigateur Web ne les comprend pas.

C’est pourquoi PHP ne peut pas, par exemple, suivre votre souris. Au moment où votre navigateur suit l'activité de la souris, le serveur n'est plus impliqué.

Côté client signifie "se passe dans votre navigateur, une fois que le serveur a renvoyé les ressources nécessaires." Donc HTML, CSS et JavaScript / jQuery sont tous côté client: ils sont stockés sur le serveur (comme tous les fichiers), mais c'est votre navigateur qui Est-ce que rien avec eux.

Les scripts côté client sont donc bloqués avec ce que le serveur leur a donné: au moment où les scripts côté client sont en mesure de s'exécuter, le serveur a déjà terminé son transfert.

C'est pourquoi, par exemple, vous ne pouvez généralement pas naviguer vers une autre page sur un site WordPress sans rencontrer un scintillement de «rechargement»: obtenir le contenu d'une nouvelle page nécessite une nouvelle requête HTTP, un retour au serveur et WordPress base de données, et une toute nouvelle réponse HTTP (suivie de nombreuses autres demandes et réponses HTTP pour des ressources comme les feuilles de style CSS et les images). Votre navigateur doit ensuite intégrer ce nouvel ensemble de réponses HTTP dans une page.

Cependant, vous remarquerez que les curseurs de page d'accueil passent généralement de manière transparente d'une photo à la suivante. En effet, le serveur les a tous envoyés en même temps dans le cadre du même chargement de page, et ils sont affichés et masqués sur le côté client en utilisant JavaScript.

(Trois notes désactivables sur cette section. Premièrement, une solution pour récupérer "sans scintillement" des données supplémentaires sur le serveur existe et s'appelle Ajax. Deuxièmement, créer des sites Web et des applications Web entiers en une seule page, utilisant des frameworks JavaScript, devient très populaire; une fois la page chargée, vous pouvez alors naviguer instantanément entre différentes parties de celle-ci et «sans scintillement» à l'aide de JavaScript lui-même. Troisièmement, il existe une chose telle que JavaScript côté serveur: JavaScript qui prend le rôle de PHP, comme le fait Node.js. Tous ces sujets sont assez avancés et nous ne nous en inquiéterons pas davantage ici.)

En conclusion: ne vous inquiétez pas si tout cela semble plutôt technique et déroutant. Vous commencerez à avoir une bien meilleure idée lorsque vous programmez dans WordPress lui-même – tout comme vous comprendrez mieux la disposition d'une ville en y vivant pendant un certain temps. Alors faites de votre mieux pour comprendre ce chapitre, mais ne vous arrêtez pas là!

---

Crédit d'image: Ian D. Keating