In deze reeks hebben we gekeken naar de verschillende faciliteiten die het mogelijk maken om WordPress te behandelen als een basis voor de ontwikkeling van webapplicaties.
Tot nu toe hebben we veel terrein afgedekt:
In de meest recente artikelen hebben we gesproken over hoe u met behulp van de query's tegen de WordPress-database kunt omgaan WP_Query
en WP_User_Query
.
In dit artikel gaan we de discussie afronden door te praten over hoe we directe SQL-query's tegen de database kunnen uitvoeren.
Concreet gaan we kijken naar de standaardbewerkingen voor SELECT
, BIJWERKEN
, INSERT
, DELETE
, en meer, we zullen voorbeelden van elk bekijken. Vervolgens zullen we onze discussie afronden door te praten over parametrering, zodat we veilige query's kunnen schrijven.
Laten we, met dat gezegd, eens kijken naar de beschikbare bewerkingen, voorbeelden van elk, en hoe we ze kunnen opnemen in ons werk.
Voor degenen onder u die nog niet vertrouwd zijn met het schrijven van SQL-query's, is het belangrijk om de termen te begrijpen voor elk type query dat we doen om te worden uitgevoerd. ten eerste hebben we het over de SELECT
uitspraak.
Simpel gezegd, SELECT
verklaringen zijn verantwoordelijk voor ophalen gegevens uit de database zodat we de informatie kunnen lezen.
Een van de eenvoudigste voorbeelden die we kunnen geven, is hoe je een berichttitel kunt ophalen uit de wp_posts
tafel:
// Globalize altijd $ wpdb global $ wpdb; // Selecteer een enkele variabele - de berichttitel van de eerste post $ title = $ wpdb-> get_var ("SELECT post_title FROM $ wpdb-> posts WHERE ID = 1;"); echo $ titel;
Toegegeven, dit veronderstelt dat u bekend bent met het databaseschema, maar we hebben dit behandeld in eerdere artikelen.
Natuurlijk kunnen we, binnen de context van WordPress, niet eenvoudig een query definiëren en laten uitvoeren, in plaats daarvan moeten we ervoor zorgen dat we deze doorgeven aan de juiste API. invoeren $ wpdb
.
Rechtstreeks van de Codex:
WordPress biedt een globale variabele, $ wpdb, die een instantiatie is van de klasse die al is ingesteld om te praten met de WordPress-database.
Het $ wpdb-object kan worden gebruikt om gegevens uit elke tabel in de WordPress-database (zoals aangepaste plugin-tabellen) te lezen, niet alleen de standaardtabellen die door WordPress worden gemaakt.
Dus hier is een voorbehoud dat we tot nu toe nog niet tegenkwamen in ons werk: The $ wpdb
globale variabele is globaal, wat betekent dat we op elk gewenst moment dat we er toegang toe willen hebben, ervoor moeten zorgen dat we de prefix gebruiken globaal
zoekwoord ervoor.
globale $ wpdb; // Selecteer een hele rij met informatie uit de eerste post $ info = $ wpdb-> get_row ("SELECT * FROM $ wpdb-> posts WHERE ID = 1;"); print_r ($ info); // Krijg alle titels van berichten (en pagina's en aangepaste berichttypes) met een ID van minder dan 10 $ titels = $ 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 );
Als dit nieuw voor je is, maak je geen zorgen, we zullen hier in dit artikel nauwkeurig bekijken hoe dit moet.
Degenen die meer geavanceerd zijn, zijn meer dan in staat om complexere vragen te behandelen.
Merk ook op dat alle query's worden ingesteld tussen dubbele aanhalingstekens. Dit is zodat we het kunnen gebruiken$ wpdb
variabele binnen de tekenreeks en geen tekenreeksaaneenschakeling hoeft uit te voeren die de manier waarop de code eruit ziet, kan bemoeilijken. Let bovendien goed op bij welk soort query's afzonderlijke variabelen worden geretourneerd en welk type query's collecties retourneren, omdat dit bepaalt hoe u de informatie kunt beheren zodra deze is opgehaald. Misschien herhaal je het terug naar de pagina, of misschien loop je er doorheen.
Natuurlijk is het achterhalen van informatie een manier waarop gegevens worden beheerd in de WordPress-database. Immers, om iets op te halen, moet je data hebben die feitelijk in de databasetabellen is opgeslagen.
Hoewel de WordPress API dit relatief gemakkelijk maakt vanuit een programmeringsperspectief (met name door het gebruik van enkele van de API's die we zojuist in de afgelopen twee artikelen hebben besproken), kan het soms voorkomen dat het schrijven van uw eigen query's om informatie in te voegen de goed gedaan.
Houd er rekening mee dat we in alle voorbeelden die we bekijken, een aantal relatief eenvoudige vragen bekijken. Dit wordt gedaan zodat degenen onder u die nog nooit SQL hebben geschreven in de context van WordPress (of in welke context dan ook), eenvoudig kunnen volgen.
Het invoegen van gegevens moet voorzichtig gebeuren, niet alleen omdat u een tafel schrijft naar één (of meerdere) tabellen, maar omdat u wilt controleren of u niet in botsing komt met gegevens die al bestaan.
Hoewel databases beperkingen kunnen hebben die u toestaan om dit te doen, vind ik dat het altijd veilig is om preventieve maatregelen te nemen op het codeniveau om, laten we zeggen, te controleren of er iets bestaat voordat u het invoegt. Op die manier kunt u een update uitvoeren in plaats van een invoegtoepassing (die we even zullen bekijken).
Maar als u zeker weet dat u klaar bent om informatie in te voegen, zijn hier enkele voorbeelden om u op weg te helpen.
globale $ wpdb; // Voeg in de berichtentabel een gepubliceerde post met een titel en inhoud in met de willekeurige post-ID van 9999 $ wpdb-> insert ('wp_posts', array ('id' => 9999, 'post_title' => 'Ingevoegde post ',' post_status '=>' publiceren ',' post_content '=>' Voorbeeld van inhoud voor een post ingevoegd via directe query. '), array ('% d ','% s ','% s ','% s '));
Net als met de SELECT
vragen, deze voorbeelden zijn bedoeld als fundamenteel - beginners zouden ze gemakkelijk moeten kunnen oppikken, ervaren gebruikers zouden moeten begrijpen hoe ze dit met een kleine inspanning naar het volgende niveau kunnen brengen.
Zoals vermeld in de laatste sectie, kunnen er soms momenten zijn waarop we gegevens willen bijwerken in plaats van nieuwe gegevens in te voegen. In dergelijke gevallen zoeken we eigenlijk naar de BIJWERKEN
omdat we hierdoor een bestaande rij met informatie kunnen opnemen, de gegevens kunnen bijwerken en deze vervolgens in de database kunnen opslaan.
In wezen is dit ideaal in gevallen waar bestaand informatie moet worden aangepast.
globale $ wpdb; // Update de titel en de berichtinhoud van de rij van de berichtentabel heeft de ID van 9999 $ wpdb-> update ('wp_posts', array ('post_title' => 'Inserted Post (Updated)', 'post_content' => 'Voorbeeld inhoud voor een bericht * bijgewerkt * via directe query.'), Array ('id' => 9999), array ('% d', '% s', '% s'), array ('% d' ));
Dit leidt ons natuurlijk naar nog een bewerking - als we niet op zoek zijn naar informatie, informatie invoegen of informatie bijwerken, wat willen we dan nog meer doen??
De DELETE
operatie maakt het voor ons mogelijk om gegevens direct uit de database te verwijderen zonder gebruik te maken van een van de WordPress API's. Het vermogen om dit te doen is dat je in staat bent om de gebruikelijke functies en conditionals die vereist zijn om informatie te verwijderen, door te geven.
Het nadeel is echter dat het gevaarlijk kan zijn om informatie direct uit de database te verwijderen, omdat zonder goede controles en defensieve codering, als de gegevens eenmaal zijn verdwenen, het voorgoed is verdwenen.
globale $ wpdb; // Verwijder de record uit de database waar de ID-kolom de waarde 9999 $ wpdb-> delete ('wp_posts', array ('ID' => 9999), array ('% d')) heeft;
Terwijl we naar deze bewerkingen hebben gekeken, hebben we gezien hoe we direct met de database kunnen werken door de API te omzeilen of te ontwijken (afhankelijk van hoe je ernaar kijkt), maar het laatste dat we nodig hebben om een kijken naar is precies hoe we ervoor kunnen zorgen dat we de meest veilige vragen schrijven die we mogelijk kunnen hebben.
Tot nu toe hebben we gegevens inline aan de query's doorgegeven, wat betekent dat we elke keer dat we gegevens in de database hebben ingevoegd of geüpdatet, dit hebben gedaan zonder er goed aan te ontsnappen.
Als we voorzichtig omgaan met dit soort voorwaarden, dan laat het de deur open voor meer kwaadwillende gebruikers om te profiteren van onze code en mogelijk kwaadaardige gegevens in de databasetabellen te injecteren.
Dus hoe voorkomen we dat dit gebeurt? Kortom, we gebruiken de bereiden
functie die bestaat op de $ wpdb
object en gebruiken we tijdelijke aanduidingen om onze informatie weer te geven. De gemakkelijkste manier om dit te begrijpen is natuurlijk om het in actie te zien, dus laten we een paar voorbeelden bekijken.
globale $ wpdb; $ id = 10000; $ title = "A Parameterized Post"; $ content = "Dit bericht is ingevoegd met behulp van een geparametriseerde query."; $ parameterized_result = $ wpdb-> query ($ wpdb-> prepare ("VOEG IN IN $ wpdb-> posts (id, post_title, post_content) VALUES (% d,% s,% s)", array ($ id, $ title , $ inhoud)));
Als u nu de informatie in dit artikel nauwlettend hebt gevolgd, hebt u al een vergelijkbare functionaliteit van substitutie gezien, zoals % s
, % d
, enzovoort, die elk respectievelijk een reeks en een getal vertegenwoordigen.
Het verschil is in dit geval dat we niet alleen onze waarden in variabelen opslaan voordat we ze aan de query doorgeven, maar we geven ook de hele query door aan de bereiden
functie die de query uitvoert en de juiste SQL-escapering uitvoert op de gegevens om te verzekeren dat we goed voorbereide, beveiligde query's hebben.
De WordPress Codex heeft een diepgaand artikel over gegevensvalidatie dat moet worden gelezen door iedereen die werkt aan plug-ins, thema's en toepassingen. Sterker nog, ik raad aan dit na dit specifieke bericht te lezen omdat het zal uitleggen over de informatie die we hier hebben besproken.
Dit artikel is bedoeld als een inleiding voor het doorsturen van WordPress-databasequery's - het is zeker niet bedoeld als een uitputtende gids; echter, door jezelf vertrouwd te maken met de informatie die hier is, de rest van het materiaal in de Codex te lezen en deze vragen uit te voeren in je eigen werk, zullen verbeter uw vaardigheden als het gaat om het werken met de onderliggende database.
In het volgende artikel sluiten we deze serie af met een overzicht van alles waar we het in de afgelopen paar artikelen over hadden, en hoe we verder kunnen gaan met toekomstige projecten of toepassingen nu we een kijkje hebben genomen op alles wat WordPress te bieden heeft.