Share
Afgezien van de samenvatting die we als het laatste artikel in deze serie gaan geven, is dit de laatste explicatie van de WordPress-coderingsnormen die we in deze serie zullen behandelen.
We gaan de nuances van databasequery's behandelen en SQL formatteren in de context van uw code.
Dit zou natuurlijk niet zonder zijn eigen restricties: in het algemeen zijn er API's die al beschikbaar zijn en die kunnen voorkomen dat we zelf SQL moeten schrijven; Deze API's vangen echter niet elk geval dat we echt nodig hebben.
Hoe kunnen ontwikkelaars die API's implementeren immers precies weten wat en hoe we iets gaan bouwen?
Daartoe gaan we de API's bekijken die beschikbaar zijn voor het uitvoeren van databasequery's, hoe deze te gebruiken en vervolgens hoe we onze eigen query's kunnen definiëren wanneer de API's tekortschieten..
Zoals vermeld in de introductie van dit artikel, zijn er een aantal API's die het ons mogelijk maken om onze eigen query's te maken zonder dat u SQL hoeft te schrijven.
De reden dat het belangrijk is om bekend te raken en deze API's te leren, is dat de code die u schrijft, wordt geschreven op het abstractieniveau van WordPress om ervoor te zorgen dat de query's zo optimaal mogelijk zijn (gegeven de huidige versie).
Bovendien vergroot dit de kans dat elke code die u vandaag schrijft, compatibel is met toekomstige versies van WordPress, omdat deze opnieuw is geschreven tegen het abstractieniveau van WordPress..
Als het tabelschema verandert, parameters worden toegewezen aan verschillende clausules in de SQL enzovoort, hoeft u zich daar geen zorgen over te maken, omdat de API dit voor u zal regelen..
En dan zijn de query-API's die WordPress definieert?
Accentsconagua
WP_Query is bedoeld voor het opvragen van informatie over elk berichttype en de bijbehorende kenmerken van auteur, categorie, taxonomieën, type, status enzovoort.WP_User_Query is bedoeld om te worden gebruikt wanneer we informatie moeten ophalen uit de gebruikerstabel en de usermetatabel. Het stelt ons ook in staat om te werken met rollen, aangepaste velden en meer.Er zijn ook andere WordPress API-methoden die het heel gemakkelijk maken om dingen uit verschillende databasetabellen te halen waarvan sommige niet eens een aanzienlijk aantal argumenten vereisen:
get_post_meta haalt metagegevens op die zijn gekoppeld aan een gegeven bericht-ID. Het kan alle metadata of de waarde voor een specifieke sleutel ophalen.get_comment_meta haalt metagegevens op die zijn gekoppeld aan een gegeven opmerking-ID. Het kan alle metadata of de waarde voor een specifieke sleutel ophalen.get_user_meta haalt metagegevens op die zijn gekoppeld aan een bepaalde gebruikers-ID (begin je hier een thema te bekijken?). Het kan alle metadata of de waarde voor een specifieke sleutel ophalen.Merk op dat het doel van dit artikel niet is om een diepe duik te nemen in elk van deze API's (en er zijn er meer) - alleen om ze kenbaar te maken aan degenen onder u die ze nog niet eerder hebben gebruikt, en om een korte definitie van wanneer ze kunnen worden gebruikt.
tenslotte, deze zijn de API's die u eerst moet bekijken voordat u uw eigen SQL schrijft. Voor wat het waard is, spreek ik uit ervaring hier: Er zijn tijden geweest dat ik code (of zelfs blogposts) heb geschreven die kapot zijn gegaan omdat ze geen gebruik maakten van de best practices voor het bevragen van de database.
Maar zoals eerder vermeld, kunnen deze API's niet voorspellen allemaal gevallen waarin we onze databasequery's moeten schrijven. In die situaties biedt WordPress een object waarmee we rechtstreeks kunnen communiceren met de database.
$ wpdb Dat brengt ons ertoe $ wpdb. In wezen, $ wpdb is een object dat beschikbaar is in WordPress en waarmee we rechtstreeks kunnen communiceren met de database. Dit betekent dat we onbewerkte SQL kunnen schrijven en deze tegen de onderliggende database kunnen laten uitvoeren.
Bovendien kunnen we selecteren hoe we de gegevens willen retourneren: arrays, objecten, soms enkele waarden, enzovoort. In feite biedt het object de mogelijkheid om de volgende functies uit te voeren:
SELECT variabelen, rijen, kolommen en generieke resultatenINSERT rijenBIJWERKEN bestaande rijenMisschien is de grootste zorg bij het introduceren van onbewerkte SQL in uw project dat u uw project opent voor potentieel kwaadaardig gedrag. Hoewel u dit zou kunnen doen voor elke database-logica, is het waar dat API's ons goed moeten beschermen tegen zoiets.
Over het algemeen doen ze dat.
Maar $ wpdb is daar ook niet van vrijgesteld. Er zijn specifieke manieren om met de database te communiceren, zodat u uw vragen kunt beschermen tegen SQL-injectie.
Om een punt uit de coderingsnormen te herhalen:
Als u de database moet aanraken, neem dan contact op met sommige ontwikkelaars door een bericht te plaatsen op de mailinglijst van wp-hackers. Misschien willen ze een functie voor de volgende versie van WordPress maken om de gewenste functionaliteit te dekken.
Kortom, als de API niet voldoet aan wat u nodig heeft, dan $ wpdb is misschien de beste optie, maar ik raad u aan deze alleen te gebruiken als u de rest van uw opties hebt uitgeput.
Op dit punt hebben we de coderingsstandaarden onderzocht in een detailniveau dat u hopelijk uitrust met informatie die u niet eerder had bij het starten van deze serie.
Om dit specifieke bericht af te sluiten, is de grootste take-away die ik wil dat iedereen heeft:
Als u dat doet, moet u uw bases laten dekken.
In het laatste artikel in deze serie hebben we een korte handleiding met een samenvatting van alles wat we in de serie hebben besproken.
