I del 1 af denne serie demonstrerede jeg, hvordan man installerer WordPress lokalt, og hvordan man importerer en WordPress-database til Vertabelo. I denne artikel ser vi nærmere på tabellerne i WordPress-databasen.
Et hurtigt kig på WordPress-databasemodellen og dashboardet
I den forrige del importerede jeg WordPress-databasen til vores online-databasemodelleringsværktøj. For en god ordens skyld er strukturen af databasen som følger:
Der er et par vigtige fakta om WordPress-databasemodellen, du bør forstå, før vi går i gang:
- Hvert WordPress-websted bruger nøjagtig den samme databasestruktur. Den indeholder 11 tabeller, og hver WordPress-side bruger dem i baggrunden. De fleste WordPress-plugins bruger også databasen uden ændringer i databasemodellen. Modellen skal være fleksibel nok til at kunne rumme alle de forskellige plugins. Selvfølgelig kan plugin-skabere tilføje tilpassede tabeller til specifikke plugins, hvis datastrukturen er væsentligt anderledes, eller hvis deres plugin gemmer store mængder data.
- WordPress-databasen mangler fremmednøglebegrænsninger . Dette skyldes, at WordPress bruger MyISAM-lagringsmotoren, som ikke understøtter fremmednøgler. Tabeller løser dette ved at have attributter, der gemmer ikke-forbundne "fremmednøgle"-lignende værdier, så den fremmede nøgle-begrænsning vil ikke blive kontrolleret af databasen. For eksempel
post_author
attribut iwp_posts
tabel er en "reference" til "ID"-attributten iwp_users
tabel. - De fleste af tabellerne bruger en enkelt kolonne primær nøgle. De hedder enten blot "ID" (i
wp_users
ogwp_posts
tabel), ellermeta_id
/umeta_id
(i metatabellerne:wp_postmeta
,wp_commentmeta
ogwp_usermeta
), eller en kombination af tabelnavnet og suffikset "_id" (alle andre tabeller). Den eneste undtagelse fra disse regler erwp_term_relationships
tabel, hvor den primære nøgle består af de to attributter:object_id
ogterm_taxonomy_id
. Attributter, der er primærnøgle eller en del af en primærnøgle, er af typen bigint(20). Primære nøgler med enkelt attribut har også egenskaben for automatisk stigning indstillet til "Ja".
Indlæg og sider
Hovedårsagen til at bruge WordPress er at skabe og manipulere indhold og præsentere det for offentligheden. Til det formål giver WordPress os to indholdstyper:Sider og Indlæg .
Sider bruges til at vise statisk indhold . De bruger ikke tags eller kategorier og er ikke opført efter dato. De tillader heller ikke kommentarer eller deling på sociale medier. Sider kan have undersider. Om os sider er gode eksempler på denne type.
På den anden side, Indlæg er opført efter dato og kan organiseres ved hjælp af kategorier og tags . Indlæg kan bruges i RSS-feeds takket være deres kronologiske rækkefølge. Indlæg kan ikke have "underopslag", men kommentarer og delinger på sociale medier er mulige. Indlæg er i bund og grund blogindlæg. Dette er forståeligt, eftersom WordPress er udviklet fra en bloggingplatform.
Den primære tabel bag indhold på enhver WordPress-side kaldes wp_posts
:
WordPress bruger wp_posts
tabel til at gemme sider, indlæg og vedhæftede filer. Vi kan se på denne tabel som kernen på vores side, det sted hvor det meste af indholdet er gemt. Det er vigtigt at påpege, at vedhæftede filer faktisk er gemt på disken og posten i wp_posts
tabel gemmer flere oplysninger om det (hvem uploadede det og hvornår osv.).
Felterne i wp_posts
tabellen er:
post_author
– en reference tilwp_users
tabel, der angiver forfatteren af indlægget.post_date
– dato og klokkeslæt, hvor posten blev indsat i tabellen.post_date_gmt
– GMT/UTC-datoen og -klokkeslættet, hvor en post blev indsat i tabellen.post_content
– det faktiske indhold af indlægget.post_title
– titlen på indlægget.post_excerpt
– en oversigt over indholdet.post_status
– den aktuelle poststatus. WordPress bruger 8 standardstatusser:"Publicer", "Future", "Kladde", "Afventer", "Privat", "Papirkurv", "Auto-Kladde" og "Arv".comment_status
– slår kommentarer til og fra på et enkelt indlæg eller på en hel side. Der er to mulige værdier:"åben" og "lukket".ping_status
– identificerer, om et indlæg tillader pingbacks og trackbacks. Ligesomcomment_status
, kan den kun indeholde værdierne "åben" og "lukket".post_password
– adgangskoden, der bruges til at se indlægget (valgfrit).post_name
– den menneskelæselige url til enpost_title
.to_ping
– en liste over URL'er, WordPress skal sende pingbacks til, afgrænset af "\n".pinged
– en liste over URL'er, WordPress har sendt pingbacks til, afgrænset af "\n".post_modified
– den seneste dato og det seneste tidspunkt, hvor et indlæg blev ændret.post_modified_gmt
– GMT/UTC-datoen forpost_modified
.post_content_filtered
– bruges af plugins til at cache dyre postindholdstransformationer.post_parent
– henviser til det overordnede indlæg.guid
– Global Unique Identifier for en stilling; dens permanente URL.menu_order
– bruges til indholdsbestilling.post_type
– typen af registrering. Det kan indeholde værdierne "post", "side", "vedhæftet fil" eller brugerdefinerede brugerdefinerede typer.post_mime_type
– typen af uploadede filer, der kun er defineret for indlæg medpost_type = attachment
. Det kan indeholde værdier som "image", "application/pdf" og "application/msword".comment_count
– indlæggets antal kommentarer, pingbacks og trackbacks.
Her er et øjebliksbillede af wp_posts
tabel efter jeg tilføjede siden "Om Nikola Tesla":
Når vi tager et kig på wp_posts
tabel, kan vi se et par versioner af vores side. Posten med ID = 1
har post_status = publish
, hvilket betyder, at indlægget er synligt for alle. comment_status = closed
og ping_status = closed
angiver, at kommentarer og ping er deaktiveret for dette indlæg.
Alle yderligere oplysninger om indlæg og sider opbevares i wp_postmeta
tabel:
Kolonnerne i denne tabel er som følger:
meta_id
– tabellens primære nøgle.post_id
– en henvisning tilwp_posts
tabel.meta_key
– en beskrivelse af enmeta_value
attribut.meta_value
– den faktisk lagrede værdi.
wp_postmeta
tabel er hvor alle oplysninger, der ikke kan gemmes i wp_posts
bordet er gemt. Den er gemt som nøgleværdi-par, en teknik, der ofte kaldes entity-attribute-value (EAV). Tabellen kan bruges af plugins til brugerdefinerede behov.
WordPress-taksonomier
Taxonomi er et fancy ord, der dybest set refererer til at gruppere ting sammen. WordPress har et par indbyggede taksonomier til gruppering af indlæg. For eksempel kategorier og tags er indbyggede WordPress-taksonomier. Du kan også tilføje dine egne brugerdefinerede taksonomier til WordPress.
Taksonomierne og deres termer opbevares i tabeller kaldet wp_terms
, wp_term_taxonomy
, og wp_term_relationships
.
wp_terms
tabel gemmer en liste over termer, der bruges til at klassificere objekter på dit WordPress-websted:
Denne tabel indeholder alle tag- og kategorinavne samt termer fra vores tilpassede taksonomier. Attributterne er som følger:
term_id
– tabellens primære nøgle.name
– navnet på udtrykket.slug
– URL'en tilname
.term_group
– bruges til at gruppere termer sammen.
Her er indholdet af vores eksempelwebsteds wp_terms
tabel:
Begreberne tildeles taksonomier ved hjælp af wp_term_taxonomy
tabel:
Attributterne i tabellen er:
term_taxonomy_id
– tabellens primære nøgle.term_id
– henvisningen tilwp_terms
tabel.taxonomy
– taksonominavnet.description
– en beskrivelse af et udtryk i den pågældende taksonomi.parent
– en reference til det overordnede udtryk iwp_terms
tabel.count
– antallet af objekter iwp_posts
tabel, der bruger dette udtryk i denne taksonomi.
wp_term_taxonomy
tabel gør det muligt for os at genbruge det samme udtryk på tværs af forskellige taksonomier. Bemærk, at posten var term_id = 1
har taxonomy = category
, mens de andre poster har taxonomy = post_tag
.
At relatere objekter gemt i wp_posts
og wp_term_taxonomy
tabeller, bruger WordPress wp_term_relationships
tabel:
Bemærk, at dette er den eneste tabel i modellen, der har en nøgle sammensat af mere end én attribut.
wp_term_relationships
tabel har følgende attributter:
object_id
– en henvisning tilwp_posts
tabel.term_taxonomy_id
– en reference tilwp_term_taxonomy
tabel.term_order
– termen rækkefølge for et bestemt objekt.
Vi har seks poster her, der forbinder seks poster fra wp_term_taxonomy
tabel med posten (object_id = 6
).
Kommentarer og WordPress-datamodellering
Det lykkedes os at placere noget indhold på vores WordPress-side. Det er rart, men i de fleste tilfælde vil vi gerne have feedback fra offentligheden. Og det er kommentarfunktionens rolle.
For at se kommentarer til indlæg kan vi blot bruge "Skriv en kommentar" eller klikke på "X Comment" (hvor X står for antallet af kommentarer til indlægget).
Vores første indlæg har allerede en kommentar. Når vi klikker på det, vil vi se, at det er en automatisk kommentar forårsaget af pingback. Vi tilføjer endnu en kommentar til det indlæg:
Vi ser nu to kommentarer til vores indlæg, men hvad ligger bag det hele i databasen?
Du kan gætte ud fra tabelnavnet, at wp_comments
tabel bruges til at gemme kommentarer på vores WordPress-side:
Egenskaberne er for det meste selvforklarende, men vi vil stadig se nærmere på nogle af dem.
comment_post_ID
er en reference til wp_posts
bord; det angiver, hvilket indlæg der har modtaget kommentarer. For den første kommentar kan vi se, at det faktisk var pingback, og at "forfatteren" er et andet indlæg. For den anden kommentar kan vi se, at jeg er forfatteren. Bemærk også comment_agent
indeholder nogle grundlæggende oplysninger om systemet og computeren, der bruges til at skrive en kommentar.
Hovedideen bag alle tre metatabeller i modellen er at gemme data, som vi ikke ønsker at gemme i vores primære tabel. wp_commentmeta
er relateret til wp_comments
tabellen på samme måde som wp_postmeta
tabellen er relateret til wp_posts
tabel.
Se WordPress-brugere
Når vores side er online, kan alle se den. WordPress-brugere er dem, der i henhold til deres tilladelsesstatus kan foretage ændringer på vores side og dets indhold.
Nu kigger vi ind i wp_users
og wp_usermeta
tabeller i MySQL-databasen.
Som forventet er wp_users
tabel vist ovenfor gemmer grundlæggende data for alle brugere, der er registreret på vores WordPress-side. Bemærk, at user_pass
er krypteret, og at NewUser har user_activation_key
attribut udfyldt, mens edrkusic har feltet tomt.
Mens attributter er angivet i wp_users
tabellen er, hvad vi ville forvente på ethvert WordPress-websted, wp_usermeta
tabel bruges til at gemme værdier, der kan være specifikke for et bestemt projekt:
Bemærk f.eks., at posten med umeta_id = 25
indeholder værdien "nogle biografiske oplysninger" , den samme tekst, som vi skrev i dashboardet, mens vi redigerede NewUser. user_id
attribut i denne post har værdi 2 , som svarer til den nye brugers ID i wp_users
bord. Det er klart, at user_id
er en reference til wp_users
tabel.
Links og muligheder i WordPress
Ideen bag wp_links
tabel er at gemme links til andre websteder:
At have links til andre websteder var meget populært i begyndelsen af blogging-æraen; i dag bruges den mindre og mindre. Fra WordPress version 3.5 og frem blev linkadministration endda fjernet fra admin-grænsefladen. Alligevel opbevares denne tabel for at give kompatibilitet med ældre versioner.
wp_options
tabel gemmer data om WordPress-installation, webstedskonfiguration, tema, plugins og widgets:
Det bruges også til at gemme midlertidige cachelagrede data. EAV-logikken er også til stede i denne tabel, som den er i wp_usermeta
, wp_postmeta
og wp_commentmeta
. Attributten option_name
spiller rollen som nøglen, mens attributten option_value
er dens tilsvarende værdi. De to andre attributter i tabellen er den primære nøgleattribut option_id
og autoload
, som kontrollerer, om en indstilling automatisk indlæses fra databasen.
Evaluering af WordPress’ databasemodel
Databasemodellen bag WordPress følger ikke flere gode databasedesignregler og -konventioner. Når vi designer en database til et bestemt formål og kender alle dens ønskede funktionaliteter på forhånd, kan vi følge alle disse regler. Men WordPress skal dække alt, som enhver kunne have i tankerne, så at ofre fremmednøgler og bruge EAV er noget, der skal gøres. Jeg ville navngive ID-attributten det samme på tværs af alle tabellerne og gøre det samme med "fremmednøglerne". For eksempel ville jeg ikke bruge post_author
i wp_posts
tabel, men jeg ville holde mig til users_id
. Bortset fra dette må jeg være enig i, at WordPress-databasen virkelig er en fantastisk model til sit formål.
Hvad synes du? Fortæl os det i kommentarfeltet.