Det finns en sak jag aldrig vill behöva förklara för en plugin-leverantör.
Det är vem av mina medlemmar som har tillgång till vad, varför de registrerade sig den vägen de gjorde, och varför systemet skickade fel välkomstmail till fel person. Det är inte ett tekniskt problem i sig. Det är ett designproblem – en konsekvens av att lägga för många ansvar i för många verktyg som inte är byggda för att prata med varandra.
Det var det jag försökte undvika när jag byggde medlemskapssystemet bakom Din Plattform.
Den här artikeln är en genomgång av hur det faktiskt ser ut. Inte en produktrecension av Restrict Content Pro, och inte ett argument för att du borde använda exakt samma stack. Det är dokumentationen av ett konkret beslut – vad jag valde, varför, och vad som gick snett längs vägen.
Varför Restrict Content Pro
Det finns inget brist på verktyg för att bygga medlemskaps-sajter. MemberPress, Paid Memberships Pro, Wishlist Member – listan är lång. Jag har testat eller utvärderat de flesta.
Anledningen till att jag landade i Restrict Content Pro handlar egentligen om tre saker, och de hänger ihop.
Den första är ägarskap. RCP är ett plugin som installeras direkt i WordPress och lagrar all data i din egen databas. Det finns ingen extern tjänst som håller i dina membres, dina transaktioner eller din åtkomstkontroll. Det spelar roll inte bara för integritet utan för kontroll – om jag vill migrera, exportera eller bygga om, är allt redan mitt.
Den andra är enkelhet. RCP gör en sak och gör den bra: det kontrollerar vem som har tillgång till vad, baserat på deras medlemskapsnivå. Det är inte ett sidbyggarverktyg, inte ett CRM, inte ett e-postsystem. Det försöker inte vara allt på en gång. Den typen av avgränsning är faktiskt en funktion.
Den tredje är att det är WP-native. Tillgångskontroll på inlägg och sidor sker via en metabox i WordPress-editorn. Nivåer och grupper hanteras i adminpanelen. Det finns inga externa dashboarder att logga in på, inga parallella system att hålla i synk. Allt lever i WordPress och följer WordPress-logiken.
Det är inte det mest avancerade alternativet på marknaden. Men det är det rätta för det jag bygger.
Hur nivåerna är konfigurerade
Din Plattform har tre nivåer: Gratis, Insiders och Premium.
Gratis är ingen medlemskapsnivå i RCP:s mening. Det är vad alla ser innan de registrerat sig – det publika lagret av sajten. Artiklar, startsida, vad som visas utan inloggning. RCP behöver inte göra något för att den nivån ska fungera.
Insiders är den fria medlemskapsnivån. Den kräver registrering men ingen betalning. En Insiders-medlem får tillgång till ett urval av innehåll som inte är publikt – längre format, mer genomarbetade resurser, saker som kräver lite mer engagemang att ta del av. I RCP sätts det upp som en nivå med priset noll kronor och ingen löptid, vilket i praktiken innebär att den inte förfaller automatiskt.
Premium är den betalda nivån. Månadsabonnemang. Tillgång till allt Premium-märkt innehåll på sajten, inklusive den här artikeln. I RCP konfigureras nivån med ett månadspris, en löptid på 30 dagar, och automatisk förnyelse. Betalning hanteras separat – jag återkommer till det.
Det finns också en fjärde sak som tekniskt sett inte är en nivå, men som fungerar som ett lager ovanpå de andra: grupper. RCP har stöd för att tilldela en användare en specifik grupp utöver deras medlemskapsnivå. Det använder jag inte fullt ut ännu, men det är inbyggt infrastruktur för framtida segmentering – till exempel om jag vill ge beta-testare eller partnerläsare tillgång till specifikt innehåll utan att skapa en helt ny betald nivå.
Hur innehållsskyddet fungerar
Det är här de konkreta besluten bor.
Varje inlägg och sida i WordPress har en RCP-metabox i editorn. Där kan jag välja vilka medlemskapsnivåer som har tillgång, och vad som ska hända om en icke-behörig besökare försöker se innehållet. Standardalternativet är en redirect till registreringssidan. Men jag använder hellre en annan approach: partiell synlighet.
Det innebär att ett Premium-inlägg är sökbart och synligt i listar och sökresultat, men att innehållet under en viss punkt – antingen en manuell ”läs vidare”-markör eller ett automatiskt klipp – ersätts av en prompt som förklarar vad nivån ger tillgång till och hur man uppgraderar. Av två skäl: det är bättre för SEO (sökmotorer ser ett fullständigt inlägg, inte en tom sida), och det är en bättre upplevelse för läsaren (de vet vad de missar, inte bara att de saknar behörighet).
Skyddet på sidnivå fungerar annorlunda. Sidor som är Insiders-specifika – till exempel en resurssida eller ett arkiv – är helt stängda för oinloggade besökare. Där vill jag inte att en sökmotorlänk ska landa i en redirect-loop, så de sidorna är heller inte indexerade.
Det som tog tid att räkna ut var skillnaden mellan inlägg och sidor i det här sammanhanget. I WordPress är de tekniskt sett olika post-typer med olika standardbeteenden. RCP hanterar dem på samma sätt, men det kräver att du är medveten om när du skapar något som en sida versus ett inlägg – det påverkar hur skyddet tillämpas och hur innehållet beter sig i navigationen.
Registreringsflödet
Det är den del som tog flest iterationer att få rätt.
Teorin är enkel: en person hittar Din Plattform, väljer en nivå, registrerar sig, och hamnar i rätt bucket. I praktiken finns det två vägar in, och de behöver ge samma resultat.
Den primära vägen är via RCP:s egna registreringsformulär. Det är ett standardformulär som du kan styla med CSS och placera på valfri sida. Användaren väljer sin nivå, fyller i namn och e-post, betalar om det är en betald nivå, och skapar ett WordPress-konto. RCP tar hand om hela den flödet.
Den sekundära vägen är via Fluent Forms. Det finns situationer – lead magnets, minikursen, externa kampanjer – där jag vill fånga en person i ett separat formulär innan de aktivt väljer en medlemskapsnivå. Fluent Forms hanterar det formuläret, FluentCRM tar emot kontakten och lägger till en tagg, och sedan – via en webhook eller en automatiseringsregel – skapas antingen ett WordPress-konto direkt, eller så skickas ett mail med en länk till RCP:s registreringssida med nivån förvald.
Det är den integrationen som tog tid. Inte för att det är tekniskt svårt, utan för att varje länk i kedjan behöver testas med verkliga adresser och verkliga inloggningar. Det räcker inte att flödet ser logiskt ut i ett diagram – det måste faktiskt fungera för en person som precis hittat sajten och klickar på en knapp.
Vad som inte fungerade från början
Tre saker.
Den första var e-postsekvenserna. RCP skickar ett välkomstmail när en person registrerar sig. FluentCRM skickar ett välkomstmail när en ny kontakt skapas. I det tidiga testet innebar det att en ny Insiders-medlem fick två välkomstmail – ett från varje system – med delvis överlappande men inte identisk information. Lösningen var att stänga av RCP:s välkomstmail helt och låta FluentCRM äga hela e-postkommunikationen. Det kräver att RCP-taggningen verkligen synkar mot FluentCRM konsekvent, men när det fungerar är det rätt approach. Ett system äger kommunikationen.
Den andra var nivå-synkroniseringen. Om en Premium-medlem avbryter sitt abonnemang – antingen aktivt eller för att betalningen misslyckas – ska deras tillgång ändras till Insiders (eller tas bort helt). RCP hanterar detta automatiskt via sina egna regler, men FluentCRM-taggen uppdaterades inte automatiskt i samma stund. Det innebar att taggen i CRM:et kunde säga ”Premium” medan RCP-nivån redan var nedgraderad. Det löste sig via en webhook som triggar en FluentCRM-automation vid varje nivåändring i RCP. Nu är de i synk.
Den tredje var den partiella synligheten. Det finns ett par tredjepartstillägg till RCP som hanterar ”läs vidare”-funktionen, och de beter sig olika beroende på vilket tema och vilken block-editor-setup man kör. Jag fick testa mig fram till en lösning som fungerar med Blocksy och block-editorn utan att skapa konstiga artefakter i inläggsstrukturen. Det är löst nu, men det var inte trivialt.
Vad det innebär i praktiken
Systemet fungerar. Det är inte perfekt, men det är stabilt och begripligt.
Det jag värdesätter mest är att det finns en tydlig källa till sanning för varje central fråga: vem som är medlem (RCP), vad de kommunicerat med mig (FluentCRM), och vad de har rätt att se (RCP, per inlägg och sida). De systemen pratar med varandra, men de konkurrerar inte.
Det är vad ägarskap faktiskt innebär i praktiken – inte bara att du äger datan, utan att du förstår var datan finns och varför.
