Premiers pas avec la migration d'une base de données WordPress : connaissances de base de la base de données

Lorsque vous travaillez sur un projet basé sur WordPress, l'un des aspects les plus frustrants ou fastidieux du déploiement est sans doute la synchronisation des bases de données de votre environnement les unes avec les autres.

Bien sûr, il est logique d'utiliser des données de test en développement, des données utilisateur en préparation et des données réelles en production, mais il n'y a pas de solution miracle, n'est-ce pas ? Cela signifie que les données de test parfoisfonctionnent ; d'autres fois, elles ne fonctionnent pas.

Par exemple, disons que vous héritez d'un projet pour lequel vous devez extraire la base de données, puis commencer à travailler avec les données existantes. Ou supposons que vous deviez migrer l’intégralité de votre site Web ou de votre application d’un serveur à un autre.

Dans ce cas, les données de test ne sont pas d'une grande aide. Au lieu de cela, vous avez besoin d'un outil. Bien sûr, l’importateur WordPress est un excellent outil pour les migrations de base, et si vous êtes familier avec le front-end de la base de données et que vous travaillez avec SQL lui-même, exécuter des exportations et des importations SQL est très bien.

Mais qu’en est-il de ceux qui se trouvent entre les deux ?

Facilitez la migration

La vérité est qu’en matière de migration de bases de données WordPress, la situation est mitigée, car beaucoup d’entre nous ont des niveaux de compétences différents selon la partie de la pile que nous utilisons le plus.

Je veux dire :

• Ceux qui sont plus familiers avec le travail front-end seront peut-être moins familiers avec la couche application et/ou la couche base de données
• Les personnes habituées à travailler au niveau de la couche application peuvent être bonnes en front-end, mais pas très bonnes en bases de données (et vice versa)
• Ceux qui vivent dans des bases de données peuvent se sentir mal à l'aise avec les couches ci-dessus

Cela ne veut pas dire qu’il n’y a pas de développeurs full-stack. Évidemment, il y en a, mais tout le monde n’est pas dans cette situation.

Ainsi, lorsqu’il s’agit de migrer des bases de données WordPress, certaines personnes se trouvent dans une position beaucoup plus difficile que d’autres. Ou bien, même si les gens sont familiers avec SQL, certains recherchent peut-être simplement un outil pour simplifier l'ensemble du processus.

Dans cette série, nous présenterons un utilitaire qui permet cela, mais avant cela, jetons un coup d'œil rapide à la base de données WordPress pour nous assurer que nous sommes tous sur la même longueur d'onde.

Base de données WordPress

Quand il s'agit de discuter des bases de données WordPress, toute une série d'articles pourrait être écrite sur chaque table, chaque colonne, le schéma, comment rédiger les meilleures requêtes, et plus encore.

Ceci n'est pas une série.

Au lieu de cela, nous ferons deux choses dans cet article :

1. Nous veillerons à ce que nous ayons tous une compréhension conceptuelle claire de la base de données afin de savoir comment l'imaginer dans nos esprits
2. Nous examinerons chaque table de la base de données WordPress pour comprendre quel type de données contient chaque table

En fin de compte, cela devrait aider à expliquer ou démystifier certains des fonctionnements sous-jacents pour ceux qui passent plus de temps sur le front-end, et éventuellement aider ceux qui passent plus de temps sur la couche application en utilisant l'API WordPress à comprendre quelles fonctionnalités correspondent à quelle table. (cela conduit finalement à écrire un meilleur code).

Qu'est-ce qu'une base de données ?

En général, je pense que la plupart des lecteurs de Wptuts+ savent ce qu'est une base de données.

Directement depuis Wikipédia :

Une base de données est une collection organisée de données. Ces données sont généralement organisées pour modéliser les aspects pertinents de la réalité (par exemple, la disponibilité des chambres d'hôtel) afin de prendre en charge les processus qui nécessitent ces informations (par exemple, la recherche d'hôtels avec des chambres disponibles).

C’est une définition juste, mais je ne pense pas qu’elle décrit très bien les bases de données WordPress ou des applications Web similaires – c’est un peu trop général. À partir de maintenant, créons notre propre définition de travail à utiliser dans le reste de cette série.

Essayons ceci :

Une base de données se compose d'au moins une table. Les tableaux sont constitués de lignes et de colonnes, et chaque ligne stocke des informations uniques. Chaque ligne est appelée un enregistrement. Plusieurs tables peuvent exister dans une base de données et parfois les tables peuvent être liées les unes aux autres.

La partie la plus déroutante de ce que j'ai partagé ci-dessus est peut-être que les tables peuvent être liées les unes aux autres. Nous reviendrons sur cette idée avant la fin de l’article – mais parlons d’abord de la base de données WordPress.

Architecture de base de données WordPress

En un mot, une base de données WordPress est composée de 11 tables (sauf si vous utilisez Multisite, mais cela dépasse le cadre de cette série).

Désormais, chaque tableau possède également son propre ensemble de colonnes représentant les différentes informations stockées dans le tableau. Par exemple, la colonne wp_posts 表有一个名为 post_content, qui représente le contenu réel stocké dans la publication.

Le formulaire et sa description sont les suivants :

• wp_users Contient la liste des utilisateurs enregistrés pour l'installation de WordPress. Cela inclut l'adresse e-mail, le mot de passe, le nom d'affichage, etc.
• wp_usermeta contient des informations relatives à chaque utilisateur. Vous pouvez stocker ici des informations supplémentaires sur chaque utilisateur.
• wp_posts est l'endroit où toutes les informations de publication sont stockées. En fait, qu'il s'agisse d'une publication, d'une page ou d'un type de publication personnalisé, toutes les informations telles que le titre, le contenu, etc. sont stockées ici.
• wp_postmeta est l'endroit où les métadonnées de chaque publication sont stockées. Ce tableau vous permet de sauvegarder et de récupérer plus d'informations sur chaque publication.
• wp_comments est l'endroit où les commentaires pour chaque publication (encore une fois, quel que soit leur type) sont stockés.
• wp_commentmeta Comme pour les autres tables "méta", vous pouvez stocker plus d'informations sur chaque commentaire que celles déjà enregistrées dans la table des commentaires.
• wp_terms est l'endroit où les catégories et les balises sont stockées. Étant donné que les relations entre les publications, les pages, les types de publication personnalisés, les catégories et les balises peuvent devenir plus complexes, certains tableaux supplémentaires sont requis.
• wp_term_taxonomy fournit des descriptions de catégories ou de balises (ou même des liens, si vous les utilisez encore) dans le tableau wp_terms.
• wp_term_relationship Stocke la relation d'une publication donnée avec sa catégorie (ou ses catégories) et/ou sa ou ses balises.
• wp_options est l'endroit où tous les paramètres sont enregistrés - cela inclut les paramètres expédiés et configurés avec WordPress ainsi que les paramètres créés à l'aide de l'API Paramètres.
• wp_links est une table qui existe toujours dans la base de données WordPress, bien qu'il n'y ait plus d'option d'interface utilisateur pour les données. Si vous avez déjà utilisé cette fonctionnalité, vous connaissez les liens et leur fonctionnement, et c'est dans cette table qu'ils sont stockés.

C’est à cela que sert la base de données WordPress. C'est relativement simple et direct, n'est-ce pas ?

Les publications sont enregistrées dans le tableau des publications, les commentaires sont enregistrés dans le tableau des commentaires, les utilisateurs sont enregistrés dans le tableau des utilisateurs, etc. Bien sûr, il existe quelques différences subtiles (par exemple, les pages sont stockées dans la table Posts), mais il s'agit d'un modèle relativement simple ;

C'est une bonne chose.

De plus, vous vous souvenez que nous avons mentionné précédemment que certains tableaux peuvent se référencer les uns les autres ? Les commentaires et les publications en sont un bon exemple. Étant donné que le commentaire est laissé sur une publication spécifique, le commentaire doit savoir à quel identifiant de publication il est associé afin que lorsque la publication est chargée, les commentaires associés à cet ID de publication puissent être récupérés.

Quoi qu’il en soit, c’est plus de détails que ce que nous avons abordé dans cette série, mais j’espère que cela suffira à vous donner une idée. Si vous êtes intéressé par des informations plus techniques, les relations entre les tables, les colonnes, etc., assurez-vous de consulter l'article du Codex WordPress sur les descriptions des bases de données.

Conclusion

À ce stade, nous avons couvert tout ce que vous devez savoir pour démarrer avec la base de données WordPress. Espérons que cela aide à lever le rideau sur ce qui se passe dans les coulisses lorsque vous enregistrez des informations dans WordPress, mais maintenant que nous avons couvert cela, il est temps de se pencher sur un outil qui rend la migration des données incroyablement facile.

Étant donné que nous comprenons désormais comment les bases de données sont organisées, nous devons également comprendre comment fonctionnent les migrations.