Förorena inte WordPress-alternativtabellen

Jag är ett fan av korta utgivningscykler. Beroende på projekt kommer cykelns längd att variera, men för många av de typer av projekt som jag arbetar med, siktar jag på att ha två veckors releasecykler.

Vidare finns det tillfällen då jag arbetar med ett projekt för någon där miljövariabler är nödvändiga så att koden vet om den körs i utveckling, iscensättning eller produktion.

Och detta kan uppnås på olika sätt beroende på projektets behov. Ibland kommer en konfigurationsfil att fungera, ibland kan frågesträngsvariabler fungera, och andra gånger tycker jag att det är rimligt att lagra en inställning i databasen.

Men när det gäller WordPress tror jag att vi genvägar bättre designbeslut och slänger information i databasen, närmare bestämt alternativtabellen, när alternativ kan vara bättre lämpade.

WordPress-alternativtabellen

Jag vill vara tydlig: Jag tycker inte att alternativtabellen ska fungera som en dumpningsplats för inställningar när du inte har någon annanstans att lägga information. Och det är kärnan i hela det här inlägget.

Istället kan du använda:

• en konfigurationsfil,
• sessionsdata (när det är lämpligt),
• en anpassad databastabell,
• eller något annat.

Så varför ser vi detta hända så ofta? Det är inte så att det inte finns tillfällen då det är vettigt att använda det. Jag tror bara att vi missbrukar det. Men det finns skäl varför.

WordPress Codex definierar alternativ så här:

Alternativ är bitar av data som WordPress använder för att lagra olika preferenser och konfigurationsinställningar.

Med en definition som denna är det lätt att se varför så många kommer att använda den som en plats för att förvara allt som inte får plats någon annanstans.

Istället tycker jag att det är viktigt att ställa frågan:

För vilken typ av lagring är [dessa data] mest relevant?

Det vill säga, om det är relaterat till inlägg varför inte lagra det i postmetatabellen? Samma för termmetadata eller kommentarer eller något annat.

Poängen är denna:

Hitta den mest logiska platsen för att lagra data och placera den där.

Med andra ord, släng inte data i WordPress-alternativtabellen eftersom den inte passar någon annanstans. Det förorenar det. Hitta istället – eller skapa – den mest logiska platsen för den. Det är förmodligen bevis på en kodlukt och skulle vara en bra anledning att omvärdera arkitekturen för din kod och hur informationen representeras.

Men hur kan detta se ut? Det vill säga, hur skulle vi ta en given kodbit och ändra hur den representeras i databasen.

Tyvärr är det svårt att ge en preskriptiv lösning på denna fråga när det finns så många varianter av implementeringen av ett problem. Så kanske en enkel riktlinje är på sin plats:

Om data är relaterade till de redan existerande datatyperna (eller tabellerna), använd dem sedan; I annat fall kan du överväga en konfigurationsfil eller anpassad databastabell som mappas till ditt arbete.

Jag är säker på att det finns andra vägledande faktorer, men det här är ett bättre ställe att börja än att bara förorena WordPress-alternativtabellen.