Share
Tout au long de cette série, nous avons examiné les différentes installations permettant de traiter WordPress comme une base pour le développement d’applications Web..
Jusqu'ici, nous avons couvert beaucoup de terrain:
Dans les articles les plus récents, nous avons expliqué comment gérer les requêtes sur la base de données WordPress avec l'utilisation de WP_Query et WP_User_Query.
Dans cet article, nous allons compléter la discussion en expliquant comment exécuter des requêtes SQL directes sur la base de données..
Plus précisément, nous allons examiner les opérations standard pour SÉLECTIONNER, METTRE À JOUR, INSÉRER, EFFACER, et plus encore, nous examinerons des exemples de chacun. Ensuite, nous finaliserons notre discussion en parlant de paramétrage afin que nous puissions écrire des requêtes sécurisées..
Cela dit, regardons les opérations disponibles, des exemples de chacune d'elles, et comment nous pouvons les intégrer à notre travail..
Pour ceux d'entre vous qui débutent dans l'écriture de requêtes SQL, il est important de comprendre les termes de chacun des types de requêtes que nous sommes en train d'exécuter. d'abord, nous parlons de la SÉLECTIONNER déclaration.
Tout simplement, SÉLECTIONNER les déclarations sont responsables de récupération données de la base de données afin que nous puissions lire les informations.
L’un des exemples les plus élémentaires que nous puissions donner est la façon de récupérer un titre de message de la wp_posts table:
Accentsconagua
// Toujours globaliser $ wpdb global $ wpdb; // Sélectionnez une seule variable - le titre du premier message $ title = $ wpdb-> get_var ("SELECT post_title FROM $ wpdb-> posts WHERE ID = 1;"); echo $ title; Certes, cela suppose que vous connaissez le schéma de base de données, mais nous en avons déjà parlé dans de précédents articles..
Bien entendu, dans le contexte de WordPress, nous ne pouvons pas simplement définir une requête et la faire exécuter. Nous devons plutôt nous assurer que nous la transmettons à la bonne API. Entrer $ wpdb.
Directement du Codex:
WordPress fournit une variable globale, $ wpdb, qui est une instanciation de la classe déjà configurée pour communiquer avec la base de données WordPress..
L'objet $ wpdb peut être utilisé pour lire des données à partir de n'importe quelle table de la base de données WordPress (telles que des tables de plug-ins personnalisées), pas uniquement des tables standard créées par WordPress..
Donc, il y a une mise en garde ici que nous n'avons pas encore rencontrée dans notre travail jusqu'à présent: $ wpdb la variable globale est globale, ce qui signifie que chaque fois que nous voulons y accéder, nous devons nous assurer de préfixer le global mot-clé avant.
$ wpdb global; // Sélectionne une ligne complète d'informations du premier message $ info = $ wpdb-> get_row ("SELECT * FROM $ wpdb-> posts WHERE ID = 1;"); print_r ($ info); // Obtient tous les titres d'articles (et les pages et types d'articles personnalisés) dont l'ID est inférieur à 10 $ titres = $ wpdb-> get_col ("SELECT post_title FROM $ wpdb-> posts WHERE ID < 10;" ); print_r( $titles ); // Retrieve a generic result set of post IDs and post titles from the posts table where posts have an ID less than 10 $results = $wpdb->get_results ("SELECT ID, post_title FROM $ wpdb-> posts WHERE ID < 10;" ); print_r( $results ); Si ceci est nouveau pour vous, pas de problème, nous allons voir exactement comment procéder dans cet article..
Ceux qui sont plus avancés sont plus que capables de traiter des requêtes plus complexes.
Notez également que toutes les requêtes sont définies entre guillemets. C’est pour que nous puissions utiliser le$ wpdb variable dans la chaîne et ne pas avoir à effectuer de concaténation de chaîne susceptible de compliquer l'apparence du code. De plus, déterminez de près le type de requête renvoyant des variables uniques et le type de requête renvoyant des collections, car cela dictera la gestion des informations une fois extraites. Peut-être que vous faites écho à la page, ou peut-être que vous finissez par faire une boucle.
Bien sûr, récupérer des informations n’est que un manière dont les données sont gérées dans la base de données WordPress. Après tout, pour récupérer quelque chose, vous devez disposer de données réellement stockées dans les tables de la base de données..
Bien que l’API WordPress rend cela relativement facile à faire du point de vue de la programmation (notamment grâce à l’utilisation de certaines des API que nous venons de passer en revue dans les deux derniers articles), il peut arriver que l’écriture de vos propres requêtes pour insérer des informations marche à suivre.
Notez que dans tous les exemples que nous allons examiner, nous examinons des requêtes relativement simples. Ceci est fait pour que ceux d'entre vous qui n'ont jamais écrit SQL dans le contexte de WordPress (ou dans n'importe quel contexte, vraiment) puissent facilement suivre.
L'insertion de données est quelque chose qui doit être fait avec soin, pas simplement parce que vous écrivez table dans une (ou plusieurs) table (s), mais parce que vous voulez vous assurer que vous n'entrerez pas en conflit avec des données déjà existantes..
Bien que les bases de données puissent avoir des restrictions vous permettant de le faire, je trouve qu'il est toujours prudent de prendre des mesures préventives au niveau du code pour, par exemple, vérifier si quelque chose existe avant de l'insérer. De cette façon, vous pouvez effectuer une mise à jour plutôt qu'un insert (que nous examinerons dans un instant).
Mais si vous êtes sûr d'être prêt à insérer des informations, voici quelques exemples pour vous aider à démarrer..
$ wpdb global; // Dans le tableau des publications, insérez une publication publiée avec un titre et du contenu avec la publication arbitraire. ID 9999 $ wpdb-> insert ('wp_posts', array ('id' => 9999, 'post_title' => 'Posté ',' post_status '=>' publish ',' post_content '=>' Exemple de contenu pour un article inséré via une requête directe. '), tableau ('% d ','% s ','% s ','% s ')); Comme avec le SÉLECTIONNER requêtes, ces exemples sont censés être fondamentaux: les débutants doivent pouvoir les récupérer facilement, les utilisateurs expérimentés doivent comprendre comment passer à l'étape suivante avec un minimum d'effort.
Comme mentionné dans la dernière section, il peut arriver que nous souhaitions mettre à jour des données plutôt que d’en insérer de nouvelles. Dans des cas comme celui-là, nous cherchons en fait le METTRE À JOUR opération car cela nous permettra de prendre une rangée d'informations existante, de mettre à jour les données, puis de les sauvegarder dans la base de données.
Ceci est essentiellement idéal dans les cas où existant l'information doit être peaufinée.
$ wpdb global; // Mise à jour du titre et du contenu de publication de la ligne de publication de la table de courrier a l'ID de 9999 $ wpdb-> update ('wp_posts', array ('post_title' => 'Posté (mis à jour)', 'post_content' => 'Exemple de contenu pour un message * mis à jour * via une requête directe.'), Tableau ('id' => 9999), tableau ('% d', '% s', '% s'), tableau ('% d' )); Bien sûr, cela nous amène à une autre opération: si nous ne cherchons pas à lire des informations, à insérer des informations ou à mettre à jour des informations, que recherchons-nous d'autre??
le EFFACER L’opération nous permet de supprimer directement des données de la base de données sans utiliser aucune des API WordPress. Pour ce faire, vous pouvez contourner les fonctions et les conditions habituelles pouvant être nécessaires pour supprimer des informations..
L'inconvénient, cependant, est qu'il peut être dangereux de supprimer directement des informations de la base de données, car sans contrôles appropriés et sans codage défensif, une fois que les données ont disparu, elles sont définitivement perdues..
$ wpdb global; // Supprime l'enregistrement de la base de données où la colonne ID a la valeur 9999 $ wpdb-> delete ('wp_posts', array ('ID' => 9999), array ('% d')); En examinant ces opérations, nous avons vu comment nous pouvons utiliser la base de données directement en évitant ou en évitant l’API (en fonction de la manière dont vous voulez l’analyser), mais la dernière chose à prendre regarder est exactement comment nous assurer que nous écrivons les requêtes les plus sécurisées que nous pouvons éventuellement.
Jusqu'à présent, nous transmettions des données aux requêtes en ligne, ce qui signifie que chaque fois que nous insérons ou mettons à jour des données dans la base de données, nous le faisons sans l'échapper correctement..
Si nous ne gérons pas ces types de conditions avec précaution, cela laisse la porte ouverte à un plus grand nombre d'utilisateurs malveillants qui peuvent tirer parti de notre code et éventuellement injecter des données malveillantes dans les tables de la base de données..
Alors, comment pouvons-nous éviter cela? En bref, nous tirons parti de la préparer fonction qui existe sur le $ wpdb objet, et nous utilisons des espaces réservés pour représenter nos informations. Bien sûr, le moyen le plus simple pour nous de comprendre cela est de le voir en action, alors jetons un coup d'œil à quelques exemples..
$ wpdb global; $ id = 10000; $ title = "Un poste paramétré"; $ content = "Ce message a été inséré à l'aide d'une requête paramétrée."; $ parameterized_result = $ wpdb-> requête ($ wpdb-> prepare ("INSERT INTO $ wpdb-> posts (id, post_title, post_content)) VALEURS (% d,% s,% s)", array ($ id, $ title) , $ content))); Maintenant, si vous suivez de près le reste des informations contenues dans cet article, vous avez déjà vu des fonctionnalités similaires de substitution telles que % s, %ré, et ainsi de suite, chacun représentant une chaîne et un nombre, respectivement.
La différence, dans ce cas-ci, est que nous stockons non seulement nos valeurs dans des variables avant de les transmettre à la requête, mais que nous transmettons également la requête entière à la commande. préparer fonction qui prendra la requête et effectuera une échappement SQL approprié sur les données pour assurer que nous avons correctement préparé et sécurisé les requêtes.
WordPress Codex contient un article approfondi sur la validation des données qui devrait être lu par toute personne travaillant sur des plugins, des thèmes et des applications. En fait, je vous recommande de lire ceci après le post en particulier, car il exposera les informations dont nous avons parlé ici.
Cet article est destiné à servir de guide pour diriger les requêtes de base de données WordPress. Il ne s'agit en aucun cas d'un guide exhaustif. Cependant, en vous familiarisant avec les informations qui y figurent, en lisant le reste de la documentation du Codex et en répondant à ces questions dans votre propre travail, volonté approfondir vos compétences en ce qui concerne l'utilisation de la base de données sous-jacente.
Dans le prochain article, nous allons terminer cette série en passant en revue tout ce dont nous avons parlé au cours des derniers articles, ainsi que la marche à suivre pour les projets ou applications futurs, maintenant que nous avons jeté un coup d'œil. à tout ce que WordPress a à offrir.
