Share
Outre le résumé que nous allons fournir dans le dernier article de cette série, il s’agit de la dernière explication des normes de codage WordPress que nous allons couvrir dans cette série..
Nous allons couvrir les nuances des requêtes de base de données et comment formater SQL dans le contexte de votre code.
Bien sûr, cela ne serait pas sans ses propres mises en garde: En règle générale, il existe déjà des API qui peuvent nous éviter d'avoir à écrire du code SQL par nous-mêmes; cependant, ces API ne couvrent pas tous les cas dont nous avons réellement besoin.
Après tout, comment les développeurs implémentant des API peuvent-ils savoir exactement quoi et comment nous allons construire quelque chose??
À cette fin, nous allons examiner les API disponibles pour exécuter des requêtes de base de données, comment les utiliser, puis comment définir nos propres requêtes lorsque les API ne fonctionnent plus..
Comme mentionné dans l'introduction de cet article, un certain nombre d'API nous permettent de concevoir nos propres requêtes sans avoir à écrire du code SQL..
La raison pour laquelle il est important de se familiariser et d'apprendre ces API est que le code que vous écrivez sera écrit au-dessus du niveau d'abstraction fourni par WordPress pour vous assurer que les requêtes sont aussi optimisées que possible (en fonction de la version actuelle)..
De plus, cela augmente la probabilité que le code que vous écrivez aujourd'hui soit compatible avec les versions futures de WordPress, principalement parce que, encore une fois, il est écrit par rapport au niveau d'abstraction fourni par WordPress..
Si le schéma de la table change, les paramètres sont mappés sur différentes clauses du code SQL, etc., vous n'avez pas à vous en soucier, car l'API s'en chargera pour vous..
Et alors sont les API de requête définies par WordPress?
Accentsconagua
WP_Query est destiné à être utilisé pour rechercher des informations sur tout type de publication et ses attributs d'auteur, catégorie, taxonomies, type, statut, etc..WP_User_Query est destiné à être utilisé lorsque nous avons besoin de récupérer des informations à partir de la table utilisateur et de la table usermeta. Cela nous permet également de travailler avec des rôles, des champs personnalisés, etc..Il existe également d'autres méthodes d'API WordPress qui permettent de récupérer facilement des éléments dans différentes tables de base de données, dont certaines ne nécessitent même pas un nombre important d'arguments:
get_post_meta récupère les métadonnées associées à un identifiant de publication donné. Il peut récupérer toutes les métadonnées ou la valeur d'une clé spécifique.get_comment_meta récupère les métadonnées associées à un ID de commentaire donné. Il peut récupérer toutes les métadonnées ou la valeur d'une clé spécifique.get_user_meta récupère les métadonnées associées à un ID utilisateur donné (commencez-vous à voir un thème ici?). Il peut récupérer toutes les métadonnées ou la valeur d'une clé spécifique.Notez que le but de cet article n’est pas de plonger profondément dans chacune de ces API (et il y en a plus), mais seulement de les faire connaître à ceux d’entre vous qui ne les utilisiez pas auparavant et de leur donner courte définition du moment où ils peuvent être utilisés.
En fin de compte, celles-ci sont les API que vous devriez examiner en premier avant d’écrire votre propre SQL. Pour ce que ça vaut, je parle d'expérience ici: il est arrivé que j'écrive du code (ou même des billets de blog) qui ont été cassés parce qu'ils n'utilisaient pas les meilleures pratiques pour interroger la base de données.
Mais, comme mentionné précédemment, ces API ne peuvent pas prédire tout cas dans lesquels nous devons écrire nos requêtes de base de données. Dans ces situations, WordPress fournit un objet qui nous permet d’interagir directement avec la base de données..
$ wpdb Cela nous amène à $ wpdb. Essentiellement, $ wpdb est un objet disponible dans WordPress qui nous permet d’interfacer directement avec la base de données. Cela signifie que nous sommes en mesure d'écrire du SQL brut et de le faire exécuter sur la base de données sous-jacente..
En plus de cela, nous pouvons sélectionner la manière dont nous voulons que les données soient renvoyées: tableaux, objets, parfois des valeurs uniques, etc. En fait, l'objet offre la possibilité d'exécuter les fonctions suivantes:
SÉLECTIONNER variables, lignes, colonnes et résultats génériquesINSÉRER rangéesMETTRE À JOUR lignes existantesLa principale préoccupation lors de l’introduction de SQL brut dans votre projet est peut-être que vous ouvrez votre projet à un comportement malveillant potentiel. Bien que vous puissiez faire valoir ce point pour toute logique de base de données, la vérité est que les API doivent nous protéger efficacement contre ce type de problème..
De manière générale, ils font.
Mais $ wpdb n'est pas exempt de cela non plus. Il existe des moyens spécifiques d'interagir avec la base de données afin de protéger vos requêtes contre l'injection SQL..
Pour réitérer un point des normes de codage:
Si vous devez toucher à la base de données, contactez certains développeurs en postant un message sur la liste de diffusion wp-hackers. Ils souhaiteront peut-être envisager de créer une fonction pour la prochaine version de WordPress afin de couvrir les fonctionnalités souhaitées..
Donc, en bref, si l’API n’atteint pas ce dont vous avez besoin, alors $ wpdb peut être votre meilleure option, mais je vous recommande de ne l'utiliser que si vous avez épuisé le reste de vos options.
À ce stade, nous avons examiné les normes de codage avec un niveau de détail qui, je l’espère, vous fournit des informations que vous n’aviez pas auparavant au moment de démarrer cette série..
Pour conclure ce post particulier, le plus gros plat que je souhaite à tout le monde est le suivant:
Si vous faites cela, alors vous devriez avoir vos bases couvertes.
Dans le dernier article de cette série, nous aurons un guide rapide résumant tout ce dont nous avons parlé tout au long de la série..
