Share
Bortsett fra sammendraget som vi skal gi som den siste artikkelen i denne serien, er dette den siste utgaven av WordPress Coding Standards som vi skal dekke i denne serien.
Vi skal dekke nyanser av databasespørsmål og hvordan formatere SQL i sammenheng med koden din.
Selvfølgelig vil dette ikke være uten sitt eget sett med advarsler: Generelt er det APIer som allerede er tilgjengelige, som kan hindre oss fra å måtte skrive SQL alene; Disse APIene tar imidlertid ikke med hver eneste sak vi faktisk trenger.
Når alt kommer til alt, hvordan kan utviklere som implementerer APIer, vite nøyaktig hva og hvordan vi skal bygge noe?
For det formål skal vi se på APIene som er tilgjengelige for å utføre databasespørsmål, hvordan du bruker dem, og hvordan du definerer våre egne spørringer når APIene blir korte.
Som nevnt i introduksjonen til denne artikkelen finnes det en rekke APIer som gjør det mulig for oss å lage egne forespørsler uten å måtte skrive SQL.
Årsaken til at det er viktig å bli kjent og lære disse APIene er slik at koden du skriver, skal skrives på toppen av abstraksjonen som tilbys av WordPress for å sikre at spørringene er optimalt som mulig (gitt gjeldende versjon).
I tillegg øker det sannsynligheten for at noen kode du skriver i dag, vil være kompatibel med fremtidige versjoner av WordPress, hovedsakelig fordi det igjen er skrevet mot abstraksjonsnivået som tilbys av WordPress.
Hvis tabellskjemaet endres, parametere kart til forskjellige klausuler i SQL, og så videre, trenger du ikke å bekymre deg for det fordi API-en vil ta vare på den for deg.
Og så er forespørsels-APIer som WordPress definerer?
Accentsconagua
WP_Query er ment å brukes til å spørre informasjon om en posttype og tilhørende forfatter, kategori, taksonomi, type, status og så videre attributter.WP_User_Query er ment å bli brukt når vi trenger å hente informasjon fra brukerbordet og usermeta bordet. Det tillater oss også å jobbe med roller, tilpassede felt og mer.Det finnes også andre WordPress API-metoder som gjør det veldig enkelt å ta tak i ting fra ulike databasetabeller, hvorav noen ikke engang krever et betydelig antall argumenter:
get_post_meta henter metadata tilknyttet en gitt post-ID. Det kan hente alle metadataene eller verdien for en bestemt nøkkel.get_comment_meta henter metadata tilknyttet en gitt kommentar-ID. Det kan hente alle metadataene eller verdien for en bestemt nøkkel.get_user_meta henter metadata knyttet til en gitt bruker-ID (begynner du å se et tema her?). Det kan hente alle metadataene eller verdien for en bestemt nøkkel.Merk at formålet med denne artikkelen ikke er å ta et dypt dykk inn i hver av disse APIene (og det er flere av dem) - bare for å gjøre dem kjent med de som ikke tidligere har brukt dem, og gitt en kort definisjon når det gjelder når de kan brukes.
Til syvende og sist, disse er APIene som du bør undersøke først før du skriver din egen SQL. For hva det er verdt, snakker jeg av erfaring her: Det har vært tider hvor jeg har skrevet kode (eller blogginnlegg) som har blitt busted fordi de ikke brukte de beste metodene for å spørre databasen.
Men som tidligere nevnt, kan disse APIene ikke forutsi alle tilfeller der vi trenger å skrive våre database spørringer. I disse situasjonene gir WordPress et objekt som lar oss direkte samhandle med databasen.
$ wpdb Det bringer oss til $ wpdb. I bunn og grunn, $ wpdb er et objekt som er tilgjengelig i WordPress som lar oss grensesnitt direkte med databasen. Dette betyr at vi er i stand til å skrive rå SQL og få den til å utføre mot den underliggende databasen.
På toppen av det kan vi velge hvordan vi vil at dataene returneres: arrayer, objekter, noen ganger enkeltverdier og så videre. Faktisk tilbyr objektet muligheten til å utføre følgende funksjoner:
Å VELGE variabler, rader, kolonner og generiske resultaterSETT INN raderOPPDATER eksisterende raderKanskje den største bekymringen når du introduserer rå SQL i prosjektet ditt, er at du åpner prosjektet for potensielt ondsinnet oppførsel. Selv om du kan gjøre dette tilfellet for en database logikk, er sannheten at APIer bør gjøre en god jobb med å beskytte oss fra noe sånt.
Generelt sett gjør de det.
Men $ wpdb er heller ikke fritatt for det. Det er spesifikke måter å grensesnittet til databasen, slik at du kan beskytte dine spørsmål mot SQL-injeksjon.
Å gjenta et punkt fra kodingsstandardene:
Hvis du må røre databasen, ta kontakt med noen utviklere ved å sende en melding til wp-hackers mailinglisten. De vil kanskje vurdere å skape en funksjon for neste WordPress-versjon for å dekke funksjonaliteten du ønsket.
Så kort sagt, hvis API-en faller mindre enn hva du trenger, da $ wpdb kan være ditt beste alternativ, men jeg anbefaler bare å bruke den hvis du har brukt opp resten av alternativene dine.
På dette tidspunktet har vi undersøkt kodningsstandardene i detaljnivå som jeg håper utstyrer deg med informasjon som du ikke tidligere hadde når du startet denne serien.
Å konkludere med dette innlegget, den største ta bort som jeg vil at alle skal ha, er dette:
Hvis du gjør det, bør du ha dekkene dine dekket.
I den endelige artikkelen i denne serien får vi en rask guide som oppsummerer alt vi har diskutert gjennom serien.
