Est-il possible de changer la couche de données dans WordPress?
WordPress est sans aucun doute très personnalisable en utilisant des plugins, mais chaque possibilité de personnalisation a sûrement des limites définies par l'architecture sous-jacente.
Pour ceux qui connaissent l’architecture WP et le code source:
Quels seraient les efforts requis pour personnaliser la couche de données utilisée par WP afin d’utiliser un autre magasin de données (par exemple, des fichiers (ou un autre système de base de données) au lieu de MySQL?). L'architecture WordPress est-elle superposée dans le sens où il est possible de changer de couche? La couche d'interface utilisateur est apparemment très facile à changer (n'importe quel thème le fait), mais qu'en est-il des autres couches, à savoir la couche de données?
Wordpress est pas conçu pour avoir une couche de base de données remplaçable. L'informatique a dans sa poitrine des concepts différents pour traiter différentes bases de données dans la même application à différents niveaux d'abstraction. Wordpress n'a pas tendance à en faire usage. Pour le dire en termes plus simples: Pas du tout.
Mais wordpress offre la possibilité de remplacer son propre code par un autre code, par exemple la classe entière de la base de données. Cela ne suffit pas toujours (normalement) à remplacer la couche entière de la base de données, mais aide à bricoler. La classe WPDB remplaçant HyperDB , par exemple, n’ajoute pas une nouvelle couche de base de données mais gère plusieurs serveurs MySQL au lieu d’un, ce qui est un exemple bien connu. (Ceci est considéré comme une mauvaise pratique à faire avec PHP, , il existe de meilleures méthodes , mais c'est un bon exemple de ce qui peut être fait).
En plus de remplacer la classe de base de données, Wordpress a la capacité de remplacer encore plus de code et de le modifier complètement, par exemple. créer une propre distribution qui s'occupe de tout ce qui concerne la couche de base de données.
Si vous voulez voir un exemple concret sur la façon de remplacer la couche de base de données entière, pour que Wordpress utilise un type de serveur de base de données totalement différent (ici: MSSQL au lieu de MySQL codé en dur), vous trouverez ici une distribution complète et un correctif. :
WordPress sur SQL Server Distro & Patch
C'est un logiciel gratuit sur lequel vous pouvez étudier comment une telle couche de base de données peut être mise en œuvre. Le site Web fournit également plus d'informations sur ce sujet.
Conseil: ne vous battez pas contre Wordpress. S'en tenir à MySQL et c'est tout. Sinon, cherchez quelque chose d'autre mieux conçu pour répondre à vos besoins. Il suffit de prendre le bon outil pour le travail.
C'est possible: voir le remplacement HyperDB pour wpdb. HyperDB ajoute le partitionnement et la réplication à WordPress. Le partitionnement fonctionne en se connectant à plusieurs bases de données et en utilisant le nom de la table pour déterminer quelle base de données doit exécuter la requête.
En fin de compte, $wpdb obtient simplement une requête SQL et il est libre de faire ce qu'il veut avec les données de cette requête. HyperDB interroge MySQL exactement comme la classe wpdb originale. Étendre cela à différentes bases de données nécessiterait de modifier les requêtes non conformes avant leur exécution. Si votre magasin de données n'accepte pas du tout le code SQL, vous devez traduire la requête entrante en une autre API que vous utilisez. Tout est possible avec suffisamment de temps et d'efforts, mais cela me semble être une entreprise assez misérable. ;)
Je viens de trouver cette page du Codex qui le résume bien, y compris un aperçu des solutions proposées et/ou envisagées par les développeurs de WordPress. Voyons comment ça se passe.