Föreställ dig det här: du lanserade en företagsportal på WordPress, skapade en anpassad innehållstyp kallad "Utrustning" och fyllde den med intern dokumentation. En vecka senare upptäcker du att alla dessa sidor indexeras av sökmotorer och är synliga för vem som helst som råkar passera. Åtkomsten borde vara begränsad till behöriga medarbetare, men din är vidöppen.

WordPress inbyggda verktyg låter dig inte selektivt begränsa en specifik anpassad innehållstyp från oregistrerade användare. Roller och behörigheter finns, men kopplingen "gäster kan inte se CPT X" finns inte tillgänglig ur lådan. Lösningen består av tre komponenter: CPT-registrering, rollkonfiguration och ett tillägg för läsrestriktioner. Den fjärde (valfria) komponenten är social inloggning så att medarbetarna slipper ange ett lösenord varje gång.

Här följer en steg-för-steg-genomgång av varje komponent med specifika tillägg och inställningar. Alla verktyg är gratis, finns i den officiella WordPress.org-katalogen och kräver ingen kodning, även om en ren kodbaserad metod tas upp i slutet för den som vill undvika tillägg.

💡 Snabb översikt:

• Registrera en anpassad innehållstyp via Custom Post Type UI utan att skriva en enda rad kod
• Skapa en anpassad roll i PublishPress Capabilities och tilldela den till medarbetarna
• Begränsa CPT-åtkomst för gäster med tillägget WP Access Areas: obehöriga besökare omdirigeras till inloggningssidan
• Aktivera eventuellt social inloggning via Super Socializer för lösenordsfri inloggning med Google-konto

Steg 1: Registrera en anpassad innehållstyp

Det första och enklaste steget är att skapa själva CPT:n. Du behöver inte röra functions.php för detta: tillägget Custom Post Type UI på WordPress.org erbjuder ett grafiskt gränssnitt för att registrera alla innehållstyper och taxonomier.

Installationen är standard: "Tillägg → Lägg till nytt", sök efter namnet, aktivera. Efter aktivering dyker ett nytt menyalternativ upp i sidofältet: "CPT UI → Add/Edit Post Types." Fyll i fälten: slug (till exempel equipment), namn i plural och singular, etiketter och klicka på "Add Post Type."

Tillägget anropar register_post_type() med korrekta parametrar automatiskt. Ingen manuell kod behövs: du får en fullt fungerande innehållstyp med redigerarstöd, arkiv och REST API. Om du senare behöver flytta registreringen till functions.php visar CPT UI den genererade PHP-koden under fliken "Tools."

Var under registreringen uppmärksam på två kritiska säkerhetsrelaterade alternativ. I CPT UI:s inställningsblock "Settings" finns en flagga "Publicly Queryable" som avgör om inlägg kan öppnas via direktlänkar. Den är förvald till true, och även efter att du har begränsat läsningen via ett tillägg bör du lämna den aktiverad; annars returnerar WordPress en 404 istället för att omdirigera till inloggningssidan, och användarna förstår inte vad som hände. Den andra parametern, "Has Archive," aktiverar en arkivsida som listar alla CPT-inlägg. Om du inte behöver ett arkiv, inaktivera det så att sökmotorer inte indexerar en servicesida med förhandsvisningar av begränsade dokument.

Steg 2: Skapa en anpassad roll

Att bara begränsa CPT-åtkomst för gäster räcker inte: du behöver en roll som ska ha åtkomst. WordPress har som standard en fast uppsättning: Administratör, Redaktör, Författare, Medarbetare, Prenumerant. Vi skapar en ny roll med hjälp av plugin-programmet PublishPress Capabilities (hette tidigare Capability Manager Enhanced, samma slug, samma funktionalitet, bara omprofilierat).

Efter aktivering går du till "Capabilities → Roles". På höger sida av skärmen hittar du blocket "Create New Role":

Ange ett namn (till exempel "Equipment Reader"), välj en basroll att klona från (Prenumerant är bäst, med minimala rättigheter) och klicka på "Create". Den nya rollen finns nu och du kan fylla den med behörigheter. För att läsa en CPT räcker standardkombinationen read + read_equipment (den behörighet som registrerats av CPT UI).

Tilldela den skapade rollen till medarbetare som behöver åtkomst till det begränsade innehållet. Därefter kan du avaktivera plugin-programmet: roller och behörigheter ligger kvar i WordPress-databasen och är inte beroende av att PublishPress Capabilities är aktivt.

Steg 3: Begränsa läsåtkomst till CPT

Det här är det avgörande steget. Plugin-programmet WP Access Areas låter dig exakt definiera vem som kan läsa, redigera och kommentera inlägg av varje typ, ända ner till enskilda sidor. Det har blygsamma 400 aktiva installationer och har inte fått några större uppdateringar på ett tag, men för uppgiften "begränsa CPT från gäster" fungerar det förutsägbart och utan konflikter.

Efter installation går du till "Settings → Access Areas". I sektionen "Default Behaviour" väljer du:

"If not logged in, redirect to login. Otherwise redirect to the fallback page."

Den här inställningen skickar obehöriga användare till wp-login.php när de försöker öppna en skyddad CPT-sida.

Därefter finns en tabell över alla registrerade inläggstyper. För din CPT väljer du "Logged in Users" i rullgardinsmenyn under kolumnen "Reading". Det är allt: från och med nu omdirigeras varje gäst som följer en direktlänk till en CPT-sida till inloggningsformuläret.

Viktigt att notera: inställningar som görs via tabellen gäller bara nya inlägg. För redan skapade sidor måste du manuellt ange behörigheter i redigerarens sidopanel, där ett "Access Areas"-block visas. Efter konfigurationen, se till att kontrollera resultatet i webbläsarens inkognitoläge: att öppna en direktlänk till en skyddad CPT-sida ska visa wp-login.php, inte innehållet.

Alternativ till WP Access Areas om du behöver en mer aktivt underhållen lösning: PublishPress Permissions (gratisversionen täcker CPT och roller) eller ContentGate (ett lättviktsplugin med regler baserade på inloggningsstatus och roller).

Steg 4: Social inloggning (valfritt)

Att ständigt ange användarnamn och lösenord på en företagsportal skapar onödig friktion. Den logiska lösningen: inloggning med ett klick via Google-konto. Pluginet Super Socializer hanterar detta med över 20 000 aktiva installationer och stöd för Google, Facebook, X (Twitter) och ett dussin andra leverantörer.

Efter aktivering, gå till "Super Socializer → Social Login":

Grundinställningar: aktivera kryssrutan "Disable user registration via social networks". Detta är viktigt så att endast befintliga konton kan logga in via sociala nätverk, istället för att skapa nya. Välj sedan leverantör (Google) och ange Client ID och Client Secret. Var du får tag på dem:

• Öppna Google Cloud Console, skapa ett projekt (eller välj ett befintligt)
• I avsnittet "APIs & Services → Credentials", klicka på "Create Credentials → OAuth client ID"
• Applikationstyp är Webbapplikation; under Authorized redirect URIs, klistra in callback-URL:en från Super Socializers inställningar
• Spara för att få ditt Client ID och Client Secret

Kopiera nycklarna till pluginets fält:

Kritisk punkt: fältet Authorized redirect URIs får inte ha ett avslutande snedstreck, annars får du felet redirect_uri_mismatch. Efter att du sparat visas en "Sign in with Google"-knapp på inloggningssidan.

Viktigt: den ursprungliga versionen av detta inlägg (2020) beskrev integration med Google+, som lades ner i april 2019. Moderna Super Socializer använder standardprotokollet Google OAuth 2.0 via Google Identity Services. Google Cloud Consoles gränssnitt har uppdaterats sedan dess, men logiken i stegen (projekt → Credentials → OAuth client ID → redirect URI) är densamma.

Alternativ metod: allt i kod

Om ytterligare tillägg är oönskade kan uppgiften lösas i temats functions.php eller ett barntema. Koden registrerar CPT:n, skapar en roll och kopplar en behörighetskontroll till mallen:

1
// Registering a custom post type
2
function register_equipment_cpt() {
3
    register_post_type('equipment', [
4
        'labels'      => ['name' => 'Equipment', 'singular_name' => 'Equipment'],
5
        'public'      => true,
6
        'has_archive' => true,
7
        'supports'    => ['title', 'editor', 'thumbnail'],
8
        'capability_type' => 'equipment',
9
        'map_meta_cap' => true,
10
    ]);
11
}
12
add_action('init', 'register_equipment_cpt');
13
 
14
// Creating a role on theme activation
15
function add_equipment_reader_role() {
16
    add_role('equipment_reader', 'Equipment Reader', ['read' => true, 'read_equipment' => true]);
17
}
18
add_action('after_switch_theme', 'add_equipment_reader_role');
19
 
20
// Redirecting guests from CPT to login page
21
function restrict_equipment_to_logged_in() {
22
    if (is_singular('equipment') && !is_user_logged_in()) {
23
        wp_redirect(wp_login_url(get_permalink()));
24
        exit;
25
    }
26
}
27
add_action('template_redirect', 'restrict_equipment_to_logged_in');

Vad den här koden gör: det första blocket registrerar CPT:n equipment med en egen behörighetstyp (capability_type). Det andra blocket skapar rollen Equipment Reader med rättigheter att läsa denna CPT när temat aktiveras. Det tredje blocket kontrollerar behörighet på hooken template_redirect och skickar gäster till wp-login.php.

Fördelen med kodmetoden: noll extra tillägg, full kontroll. Nackdelen: social inloggning kräver fortfarande ett tillägg (att skriva OAuth-integration manuellt är tidskrävande och osäkert), och varje ändring av roller innebär att man redigerar kod.

⁉️🤔 Vanliga frågor

Kan jag begränsa en CPT utan tillägg, bara genom functions.php?

Ja. Kombinationen av register_post_type() + add_role() + hooken template_redirect med en is_user_logged_in()-kontroll är en fullt fungerande lösning. Koden finns i avsnittet ovan. Social inloggning utan tillägg är betydligt svårare att implementera: manuell OAuth-integration kräver hantering av tokens, state och säkerhet.

Varför WP Access Areas istället för ett nyare tillägg som ContentGate?

WP Access Areas är ett minimalistiskt verktyg för en specifik uppgift: "begränsa en posttyp från gäster". Det drar inte med sig en regelbyggare, visuella redigerare eller prenumerationer. Om du behöver mer komplex logik (till exempel olika åtkomstnivåer för olika roller på samma CPT), använd ContentGate eller PublishPress Permissions, som uppdateras aktivt. För grundscenariot i den här guiden räcker WP Access Areas.

Vad ska jag göra om gäster fortfarande kan se CPT-sidor efter konfigurationen?

Tre typiska orsaker. För det första: inställningen "Logged in Users" i WP Access Areas-tabellen gäller bara nya inlägg; för befintliga sidor måste du ställa in behörigheter manuellt via redigeringssidopanelen. För det andra: ett cachingtillägg serverar en cachad version av sidan till gäster; rensa cachen och konfigurera undantag för den skyddade CPT:n. För det tredje: CPT:n är registrerad med 'publicly_queryable' => true och sluggen krockar med en publik sida; kontrollera efter kollisioner.

Kan jag använda Super Socializer endast för inloggning, utan delning och kommentarer?

Ja, tilläggets moduler är oberoende. På fliken "Social Sharing", avmarkera alla rutor så försvinner "Dela"-knapparna. På fliken "Social Commenting", inaktivera integrationen. Lämna bara "Social Login" med de leverantörer du behöver. Tillägget är lättviktigt, och att inaktivera onödiga moduler påverkar inte prestandan.

Är det säkert att avaktivera PublishPress Capabilities efter att ha skapat en roll?

Ja. WordPress roller och behörigheter lagras i tabellen wp_options (alternativet wp_user_roles) och är inte beroende av tillägget som skapade dem. Efter avaktivering av PublishPress Capabilities bevaras alla skapade roller och tilldelade behörigheter. Du kan återaktivera tillägget om du behöver ändra behörigheter senare.

Ska du skriva kod eller hålla dig till tillägg

Valet mellan tillägg och functions.php handlar om två faktorer: antalet CPT:er som skyddas och hur ofta behörigheter ändras.

Om du bara har en CPT (som utrustningsexemplet), rollerna är stabila och du är villig att skriva 30 rader kod en gång, är functions.php-metoden renare: den skapar inga tillägg, är inte beroende av tredjepartsuppdateringar och är helt transparent. Du kan behålla Super Socializer för social inloggning, eftersom det löser en smal uppgift och inte krockar med egen kod.

Om du har flera CPT:er, behörigheter revideras ofta eller webbplatsen hanteras av en icke-utvecklare, välj tilläggskombinationen. CPT UI + PublishPress Capabilities + WP Access Areas (eller ContentGate) kan konfigureras från adminpanelen på 15 minuter utan att röra kod. Dessutom säkerhetskopierar PublishPress Capabilities automatiskt roller vid varje ändring, vilket möjliggör återställning med två klick.

Oavsett scenario, följ principen: ett verktyg för en uppgift. Installera inte en kraftfull allt-i-ett-lösning för en enda kryssruta, och uppfinn inte hjulet på nytt om ett befintligt tillägg gör exakt samma sak snabbare och säkrare.

Versionshantering förtjänar separat övervägande. Kod från functions.php lever i temats repository, ändringar spåras via Git, och vid migrering av webbplatsen återskapas roller automatiskt på hooken after_switch_theme. Tilläggsmetoden erbjuder inte denna transparens: roller lagras i databasen, och vid driftsättning av en staging-kopia eller överföring till en ny domän måste de återskapas manuellt eller via ett migreringsskript. Denna faktor blir ofta avgörande till förmån för kod för team som praktiserar CI/CD och Git-baserad driftsättning.