Migrerer WordPress-databasen En database-primer

Når det gjelder å jobbe med WordPress-baserte prosjekter, er det sikkert at en av de mest frustrerende eller kjedelige aspektene av distribusjon faktisk får databasene på tvers av dine miljøer i synkronisering med hverandre.

Visst, det er noe å si om å bruke testdata i utvikling, brukerdata i lagring og faktiske data i produksjonen, men det er ikke noe som en sølvkule, ikke sant? Det betyr det noen ganger testdata kommer til å fungere; andre ganger, vil det ikke.

For eksempel, la oss si at du arver et prosjekt som du må trekke ned en database og så begynne å jobbe med eksisterende data. Eller la oss si at du må overføre et helt nettsted eller program fra en server til en annen.

I slike tilfeller hjelper testdataene ikke mye. I stedet trenger du et verktøy for det. Og sikker på at WordPress Importer er et rettferdig verktøy for grunnleggende migreringer, og kjører SQL-eksport og import er greit hvis du er komfortabel med databasefrontender og jobber med SQL selv.

Men hva med de som er et sted i mellom?

Gjør migreringer enklere

Sannheten er når det gjelder å jobbe med WordPress-databasemigrasjoner, det er en blandet pose fordi mange av oss har ferdighetsnivåer som varierer avhengig av hvilken del av stabelen vi jobber med mest.

Med det mener jeg:

De som er langt mer komfortable med front-end-arbeid, vil trolig være mindre kjent med applikasjonslaget og / eller databaselaget
De som er vant til å jobbe med applikasjonslaget, kan være like gode med forsiden, men ikke databasen (eller omvendt)
De som bor i databasen kan ikke være komfortable med lagene ovenfor

Dette er ikke å si at det ikke er fulle stablingsutviklere. Det er åpenbart at det er; Men ikke alle er i den posisjonen.

Så når det gjelder arbeidet med å migrere WordPress-databaser, har noen en mye vanskeligere tid enn andre. Alternativt, til tross for komfortnivået med SQL, kan noen kanskje lete etter et verktøy for å enkelt gjøre hele prosessen enklere.

I denne serien skal vi se på et verktøy som gjør det bare det, men før vi gjør det, la oss få en rask primer på WordPress-databasen for å sikre at vi er alle på samme side.

WordPress Database

Når det gjelder å diskutere WordPress-databasen, kan en hel rekke artikler skrives om hvert bord, hver kolonne, skjemaet, hvordan man skriver optimale spørringer og så videre..

Dette er ikke serien for det.

I stedet skal vi gjøre to ting i denne artikkelen:

Vi skal sørge for at vi alle har en klar, konseptuell forståelse av hva en database er så vi vet hvordan vi skal bilde det i våre sinn
Vi skal ta en titt på hver bord i WordPress-databasen for å forstå hva slags data hver tabell inneholder

Til slutt bør dette bidra til å forklare eller demystifisere noe av det underliggende arbeidet for de som bruker mer tid på forsiden, og det kan hjelpe dem som bruker mer tid på applikasjonslaget som arbeider med WordPress API, forstå hvilke funksjoner som samsvarer med hvilket bord (som til slutt kan føre til å skrive bedre kode).

Hva er en database?

Generelt sett tror jeg at flertallet av leserne av Wptuts + vet hva en database er.

Rett fra Wikipedia:

En database er en organisert samling av data. Dataene er vanligvis organisert for å modellere relevante aspekter av virkeligheten (for eksempel tilgjengeligheten av rom på hotell), på en måte som støtter prosesser som krever denne informasjonen (for eksempel å finne et hotell med ledige stillinger).

Det er en rettferdig definisjon, men jeg tror ikke det gjør en så god jobb med å illustrere WordPress-databasen eller lignende webapplikasjoner - det er litt for generelt. Så, la oss lage vår egen arbeidsdefinisjon som vi kan bruke gjennom resten av serien.

Hvordan databaser er normalt representert.

La oss prøve dette:

En database består av minst ett bord. Et bord består av rader og kolonner som hver lagrer unike opplysninger. Hver rad heter en plate. Flere tabeller kan eksistere i en database, og noen ganger kan tabeller relateres til hverandre.

Kanskje den mest forvirrende delen av det jeg har delt over er at tabellene kan være relatert til hverandre. Vi kommer tilbake til denne ideen før artikkelen slutter - men først, la oss diskutere WordPress-databasen.

WordPress Database Schema

Kort sagt består WordPress-databasen av elleve tabeller (med mindre du bruker Multisite, men det er utenfor rekkevidden av denne serien).

Nå har hver tabell også sitt eget sett med kolonner som representerer en rekke opplysninger lagret i tabellen. For eksempel, wp_posts bordet har en kolonne kalt POST_CONTENT som representerer det faktiske innholdet som er lagret i et innlegg.

Tabellene og deres beskrivelser er som følger:

wp_users holder listen over brukere som er registrert i WordPress-installasjonen. Dette inkluderer ting som e-postadresse, passord, visningsnavn og så videre.
wp_usermeta inneholder informasjon relatert til hver bruker. Her kan du lagre tilleggsinformasjon om hver bruker.
wp_posts er der all postinformasjon er lagret. Sannheten er, det spiller ingen rolle om det er et innlegg, en side eller en egendefinert innleggstype - all informasjon som tittel, innhold og mer lagres her.
wp_postmeta er der metadataene for hvert innlegg lagres. Denne tabellen lar deg lagre og hente mer informasjon om hvert innlegg.
wp_comments er der kommentarene for hvert innlegg (igjen, uansett type) lagres.
wp_commentmeta Som de andre "meta" -tabellene kan du lagre mer informasjon om hver kommentar enn det som allerede er lagret i kommentarbordet.
wp_terms er der kategoriene og kodene er lagret. Fordi forholdet mellom innlegg, sider, egendefinerte innleggstyper, kategorier og merker kan bli litt mer komplisert, er det noen få ekstra tabeller.
wp_term_taxonomy gir en beskrivelse av kategorien eller taggen (eller til og med linken hvis du fortsatt bruker dem) i wp_terms bord.
wp_term_relationship lagrer forholdene fra et gitt innlegg til sin kategori (eller kategorier) og / eller tag (eller tagger).
wp_options er der alle innstillingene holdes - dette inkluderer de som sendes og er konfigurert med WordPress og de som er opprettet ved hjelp av Innstillinger API.
wp_links er et bord som fremdeles finnes i WordPress-databasen til tross for at det ikke lenger er et brukergrensesnitt for dataene. Hvis du noen gang har brukt denne funksjonen, så er du kjent med koblinger og hvordan de fungerer, og dette er tabellen der de er lagret.

Og det er alt der er til WordPress-databasen. Det er relativt enkelt og greit, rett?

Innlegg holdes i innleggstabellen, Kommentarer i kommentarfeltet, Brukere i brukerbordet og så videre. Jo, det er noen subtile nyanser (som det faktum at Sider er lagret i Innlegg-tabellen); Det er imidlertid et relativt ukomplisert skjema å følge.

Det er en god ting.

Husk også hvordan vi tidligere nevnte at noen tabeller kan referere til hverandre? Et godt eksempel på dette ville være tabellen Kommentarer og Innlegg-tabellen. Siden kommentarer er igjen på et bestemt innlegg, må en kommentar vite hvilken post-ID den er tilknyttet, slik at når et innlegg er lastet, kan kommentarer knyttet til det innleggets ID hentes.

En database og dens tabeller.

Uansett, dette er mer detaljert enn vi vil dykke inn i denne serien, men forhåpentligvis er det nok å gi deg en ide. Hvis du er interessert i mer teknisk informasjon, er forholdene mellom tabellene, kolonnene og mer, så definitivt kassen WordPress Codex-artikkelen på databasen Beskrivelse.

Konklusjon

På dette tidspunktet har vi dekket alt vi trenger for å dekke i vår primer av WordPress-databasen. Forhåpentligvis bidrar dette til å trekke tilbake gardinene for hva som skjer når du lagrer informasjon i WordPress, men nå som vi har dekket dette er det på tide å se på et verktøy som gjør det mulig å jobbe med dataoverføringer svært enkelt.

Og med tanke på at vi nå har en forståelse for hvordan databasen er organisert, bør vi også ha en forståelse for hvordan migrasjoner fungerer.

Kode