Varför användardata i WordPress kan vara en mardröm

Varje webbplats vi skapar har sina egna utmaningar. Men de verktyg vi använder kan hjälpa oss att hantera dem direkt.

WordPress och dess oändliga plugin-ekosystem har hjälpt webbdesigners att bemästra även de tuffaste kundkraven. Nästan allt vi behöver är bara klicka och gå. Och om det inte finns kan vi bygga det själva.

Men för varje lösning vi tar finns det en potentiell konsekvens. En som bara växer när vi gräver lite djupare i användarspecifik data. Först då inser vi röran under det vackra skalet.

En enkel start

I standardinstallationen av WordPress är användardatan (åtminstone den typ du vill exportera) faktiskt ganska ren och snygg. Data lagras i databastabellen wp_usermeta. Inuti hittar du grunder som användarnamn, tillsammans med deras roller/funktioner och kontopreferenser.

Kombinera detta med vad som finns i tabellen wp_users (användarnamn, e-postadress, lösenord) så kan du få mycket användbar information för varje användare på din webbplats. Dessutom kan du enkelt importera en CSV-lista med nya användare om det behövs.

Naturligtvis stannar de flesta webbplatser inte vid en standardinställning. Istället lägger vi vanligtvis till valfritt antal plugins så att användarna kan göra mer med vår sida.

Vi vill att de ska göra saker som att ha profilinformation, spåra beställningar och tillhöra specifika grupper. Dessutom används funktioner som forum, supportportaler och lärhanteringssystem i stor utsträckning idag.

Och det är bara att skrapa på ytan. Det finns mycket mer som kan läggas till på en typisk WordPress-webbplats. Det är bra, tills du måste försöka diskutera data.

Data, data, överallt

Problemet i fråga är inte WordPress självts fel. I många fall är det där en viss bit data lagras för plugin-utvecklare. Det kan göra att användardata du vill samla in lagras överallt. Detta är djurens natur.

Låt oss använda en ny webbplats som jag arbetade på som exempel. Den använder ett medlemskapsplugin, som gör att vem som helst kan gå med i kundens organisation.

Information som samlas in

När de registrerar sig ber vi om mer än bara standard WordPress-användarmetadata. Nya medlemmar krävs information som:

• Leveransadress;
• Telefonnummer;
• Dina preferenser för hur de tar emot nyhetsbrev (e-post eller post);

Data genereras

Utöver den information vi ber användarna att tillhandahålla, finns det mycket data som genereras av medlemskapsplugin, inklusive:

• Medlemskapsstatus (aktiv eller inaktiv);
• Medlemsnivå;
• Medlemskapets utgångsdatum;

Inget på toppen om inställningarna. Det skiljer sig förmodligen inte mycket från tiotusentals andra sajter som driver samma medlemspool.

Även om webbplatsen inte är alltför komplicerad, betyder det inte att dina användardata är lätta att hitta. Låt oss se hur en enkel uppgift kan bli en tidskrävande utmaning.

Utmaning

Kunden har ett väldigt grundläggande behov. De vill exportera från alla aktiva medlemmar som vill ha en utskrift av organisationens nyhetsbrev skickat till dem. Baserat på vad vi har tar detta bara några minuter att improvisera. Det är så långt.

Det här är mycket svårare än jag föreställt mig. Den data vi behöver finns redan i databasen. Men att försöka bygga om det visade sig vara en nästan episk uppgift för någon som inte är en databasfrågeguide.

Men det är därför vi har plugins, eller hur? Och det finns massor av olika alternativ, både gratis och premium. Men, oavsett vad jag försökte, kunde jag inte få exakt vad exporten krävde. Här är varför:

• de personuppgifter som vi ber medlemmar att lämna Vi är lätta nog att få. Det finns i tabellen wp_usermeta, som användare vanligtvis exporterar plugins till. Därför är det ganska enkelt att skapa en lista över användare som vill att en kopia av nyhetsbrevet ska skrivas ut.
• de andra medlemsrelaterade uppgifterDen lagras dock i en annan tabell som är unik för medlemskapsplugin. Inte ens ett ganska kraftfullt handelsplugin som jag har använt kan hjälpa mig här.

Som ett resultat kunde jag ta reda på vem som begärde postversionen av nyhetsbrevet, men jag kunde inte ta reda på om deras medlemskap var aktivt, vilket inte är särskilt användbart.

Visst, den informationen lagrades i en sammanhängande tabell i samma databas, men den kan också vara på Jupiter för mina ändamål. Det känns som att leta efter nycklar i huset, bara för att få reda på att din granne har dem på jakt efter räddning.

Slutligen hittade jag ett exportplugin, ett som innehåller ett plugin för medlemskapsplugin, som kan hjälpa mig att samla in den data jag behövde. Om det inte finns, kommer du fortfarande att sitta fast med bara halva lösningen.

Kan upplevelsen förbättras?

Allt detta får mig att undra hur dessa situationer skulle kunna förbättras eller undvikas i första hand. Det var ett svårt beslut.

För det första erkänner jag att den här typen av utmaningar inte är min starka sida. Någon med mycket PHP- och MySQL-erfarenhet kan hitta en anpassad lösning. jag? Jag får testa plugins och gnälla när de inte fungerar som förväntat.

Men en fråga värd att ställa är: Där sådan erfarenhet krävs för att exportera en komplett uppsättning användardata? Det verkar som att det borde finnas ett enklare sätt att få detta att fungera.

Det faktum att WordPress tillåter plugins att skapa sina egna databastabeller är förståeligt och till och med fördelaktigt. Det säkerställer att vi kan installera och avinstallera plugins utan rädsla för att förstöra något.

Men även om allt detta fungerar med blotta ögat, är det allt annat än de av oss som försöker komma åt grundläggande data.

Kanske borde det finnas ett API som gör att vi kan få allt relaterat till en viss användare, oavsett var det lagras i databasen. Men jag lämnar den diskussionen för dem som känner till fördelarna och nackdelarna med en sådan funktion.

Tills dess kommer jag att fortsätta sätta ihop saker eftersom kunden behöver dem, förhoppningsvis en renare process i framtiden.