Tenk deg dette: du lanserte en bedriftsportal på WordPress, opprettet en egendefinert innholdstype kalt «Utstyr» og fylte den med intern dokumentasjon. En uke senere oppdager du at alle disse sidene indekseres av søkemotorer og er synlige for alle som tilfeldigvis kommer forbi. Tilgangen skal være begrenset til autoriserte ansatte, men din er vidåpen.

WordPress sine innebygde verktøy lar deg ikke selektivt begrense en spesifikk egendefinert innholdstype for uregistrerte brukere. Roller og rettigheter finnes, men bindingen «gjester kan ikke se CPT X» er ikke tilgjengelig ut av boksen. Løsningen består av tre komponenter: CPT-registrering, rollekonfigurasjon og en plugin for leserestriksjon. Den fjerde (valgfrie) komponenten er sosial innlogging, slik at ansatte slipper å taste inn et passord hver gang.

Nedenfor følger en trinnvis gjennomgang av hver komponent med spesifikke plugin-er og innstillinger. Alle verktøy er gratis, tilgjengelige i den offisielle WordPress.org-katalogen og krever ingen koding, selv om en ren kodebasert tilnærming dekkes til slutt for dem som ønsker å unngå plugin-er.

💡 Rask oversikt:

• Registrer en egendefinert innholdstype via Custom Post Type UI uten å skrive en eneste linje kode
• Opprett en egendefinert rolle i PublishPress Capabilities og tildel den til ansatte
• Begrens CPT-tilgang for gjester ved hjelp av WP Access Areas-pluginen: uautoriserte besøkende omdirigeres til innloggingssiden
• Aktiver eventuelt sosial innlogging via Super Socializer for passordfri pålogging med Google-konto

Trinn 1: Registrere en egendefinert innholdstype

Det første og enkleste stadiet er å opprette selve CPT-en. Du trenger ikke røre functions.php for dette: Custom Post Type UI-pluginen på WordPress.org gir et grafisk grensesnitt for å registrere alle innholdstyper og taksonomier.

Installasjonen er standard: «Plugins → Legg til ny», søk etter navn, aktiver. Etter aktivering dukker det opp et nytt menyelement i sidepanelet: «CPT UI → Legg til/Rediger innholdstyper». Fyll ut feltene: slug (for eksempel equipment), flertalls- og entallsnavn, etiketter, og klikk «Legg til innholdstype».

Pluginen kaller register_post_type() med korrekte parametere automatisk. Ingen manuell kode kreves: du får en fullt funksjonell innholdstype med redigeringsstøtte, arkiver og REST API. Hvis du senere trenger å flytte registreringen til functions.php, viser CPT UI den genererte PHP-koden i fanen «Verktøy».

Under registreringen må du være oppmerksom på to kritiske sikkerhets-relaterte alternativer. I CPT UI sin innstillingsblokk finnes flagget «Offentlig søkbar», som avgjør om innlegg kan åpnes via direkte lenker. Det er satt til true som standard, og selv etter at du har begrenset lesing gjennom en plugin, bør du la dette være aktivert; ellers vil WordPress returnere en 404 i stedet for å omdirigere til innloggingssiden, og brukerne vil ikke forstå hva som skjedde. Den andre parameteren, «Har arkiv», aktiverer en arkivside som viser alle CPT-innlegg. Hvis du ikke trenger et arkiv, deaktiver det slik at søkemotorer ikke indekserer en serviceside med forhåndsvisninger av begrensede dokumenter.

Trinn 2: Opprette en egendefinert rolle

Å bare begrense CPT-tilgang for gjester er ikke nok: du trenger en rolle som skal ha tilgang. Som standard tilbyr WordPress et fast sett: Administrator, Redaktør, Forfatter, Bidragsyter, Abonnent. Vi oppretter en ny rolle ved hjelp av PublishPress Capabilities-utvidelsen (tidligere kalt Capability Manager Enhanced, samme slug, samme funksjonalitet, bare omprofilert).

Etter aktivering går du til «Capabilities → Roles». På høyre side av skjermen finner du blokken «Create New Role»:

Skriv inn et navn (for eksempel «Equipment Reader»), velg en basisrolle å klone fra (Abonnent er best, med minimale rettigheter), og klikk «Create». Den nye rollen eksisterer nå, og du kan fylle den med kapabiliteter. For å lese en CPT er standardkombinasjonen read + read_equipment (kapabiliteten registrert av CPT UI) tilstrekkelig.

Tildel den opprettede rollen til ansatte som trenger tilgang til det begrensede innholdet. Etter dette kan du deaktivere utvidelsen: roller og kapabiliteter forblir i WordPress-databasen og er ikke avhengige av at PublishPress Capabilities er aktiv.

Trinn 3: Begrense lesetilgang til CPT

Dette er det viktigste trinnet. Utvidelsen WP Access Areas lar deg presist definere hvem som kan lese, redigere og kommentere innlegg av hver type, helt ned til enkeltsider. Den har beskjedne 400 aktive installasjoner og har ikke hatt større oppdateringer på en stund, men for oppgaven «begrense CPT for gjester» fungerer den forutsigbart og uten konflikter.

Etter installasjon går du til «Settings → Access Areas». I seksjonen «Default Behaviour» velger du:

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

Denne innstillingen sender uautoriserte brukere til wp-login.php når de prøver å åpne en beskyttet CPT-side.

Deretter finner du en tabell over alle registrerte innholdstyper. For din CPT velger du «Logged in Users» fra nedtrekksmenyen i «Reading»-kolonnen. Det er alt: fra dette tidspunktet blir enhver gjest som følger en direkte lenke til en CPT-side omdirigert til autorisasjonsskjemaet.

Viktig merknad: innstillinger gjort via tabellen gjelder bare for nye innlegg. For allerede opprettede sider må du manuelt angi tillatelser i redigeringssidepanelet, der en «Access Areas»-blokk vises. Etter konfigurasjon må du huske å verifisere resultatet i nettleserens inkognitomodus: å åpne en direkte lenke til en beskyttet CPT-side skal vise deg wp-login.php, ikke innholdet.

Alternativer til WP Access Areas hvis du trenger en mer aktivt vedlikeholdt løsning: PublishPress Permissions (gratisversjonen dekker CPT og roller) eller ContentGate (et lettvektsprogramtillegg med regler basert på innloggingsstatus og roller).

Trinn 4: Sosial innlogging (valgfritt)

Å stadig taste inn brukernavn og passord på en bedriftsportal skaper unødvendig friksjon. Den logiske løsningen: ett-klikks innlogging via Google-konto. Programtillegget Super Socializer håndterer denne oppgaven med over 20 000 aktive installasjoner og støtte for Google, Facebook, X (Twitter) og et dusin andre tilbydere.

Etter aktivering går du til «Super Socializer → Social Login»:

Grunninnstillinger: aktiver avkrysningsboksen «Disable user registration via social networks». Dette er viktig for at bare eksisterende kontoer kan logge inn via sosiale nettverk, i stedet for å opprette nye. Velg deretter tilbyderen (Google) og skriv inn Client ID og Client Secret. Slik får du tak i dem:

• Åpne Google Cloud Console, opprett et prosjekt (eller velg et eksisterende)
• I seksjonen «APIs & Services → Credentials» klikker du på «Create Credentials → OAuth client ID»
• Applikasjonstype er Web application; under Authorized redirect URIs limer du inn tilbakeringings-URL-en fra Super Socializer-innstillingene
• Lagre for å få din Client ID og Client Secret

Kopier nøklene inn i programtilleggets felter:

Kritisk punkt: feltet Authorized redirect URIs må ikke ha en etterfølgende skråstrek, ellers får du en redirect_uri_mismatch-feil. Etter lagring vises en «Sign in with Google»-knapp på innloggingssiden.

Viktig: den opprinnelige versjonen av dette innlegget (2020) beskrev integrasjon med Google+, som ble lagt ned i april 2019. Moderne Super Socializer bruker standard Google OAuth 2.0-protokoll gjennom Google Identity Services. Google Cloud Console-grensesnittet har blitt oppdatert siden den gang, men logikken i trinnene (prosjekt → Credentials → OAuth client ID → redirect URI) er den samme.

Alternativ tilnærming: alt i kode

Hvis ekstra utvidelser er uønsket, kan oppgaven løses i temaets functions.php eller et child theme. Koden registrerer CPT-en, oppretter en rolle og kobler en autorisasjonssjekk til malen:

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');

Hva denne koden gjør: den første blokken registrerer CPT-en equipment med sin egen kapabilitetstype (capability_type). Den andre blokken oppretter rollen Equipment Reader med tillatelser til å lese denne CPT-en når temaet aktiveres. Den tredje blokken sjekker autorisasjon på template_redirect-hooken og sender gjester til wp-login.php.

Fordelen med kodetilnærmingen: null ekstra utvidelser, full kontroll. Ulempen: sosial innlogging vil fortsatt kreve en utvidelse (å skrive OAuth-integrasjon manuelt er tidkrevende og usikkert), og hver endring av roller betyr redigering av kode.

⁉️🤔 Ofte stilte spørsmål

Kan jeg begrense en CPT uten utvidelser, kun gjennom functions.php?

Ja. Kombinasjonen av register_post_type() + add_role() + template_redirect-hooken med en is_user_logged_in()-sjekk er en fullt fungerende løsning. Koden er gitt i avsnittet over. Sosial innlogging uten en utvidelse er betydelig vanskeligere å implementere: manuell OAuth-integrasjon krever håndtering av tokens, state og sikkerhet.

Hvorfor WP Access Areas i stedet for en nyere utvidelse som ContentGate?

WP Access Areas er et minimalistisk verktøy for en spesifikk oppgave: «begrens en posttype for gjester». Det drar ikke med seg en regelbygger, visuelle editorer eller abonnementer. Hvis du trenger mer kompleks logikk (for eksempel ulike tilgangsnivåer for ulike roller på samme CPT), bruk ContentGate eller PublishPress Permissions, som oppdateres aktivt. For det grunnleggende scenarioet i denne guiden er WP Access Areas tilstrekkelig.

Hva bør jeg gjøre hvis gjester fortsatt kan se CPT-sider etter konfigurasjon?

Tre typiske årsaker. For det første: innstillingen «Logged in Users» i WP Access Areas-tabellen gjelder bare for nye innlegg; for eksisterende sider må du angi tillatelser manuelt via editor-sidepanelet. For det andre: en caching-utvidelse serverer en bufret versjon av siden til gjester; tøm cachen og konfigurer unntak for den beskyttede CPT-en. For det tredje: CPT-en er registrert med 'publicly_queryable' => true og slug-en kolliderer med en offentlig side; sjekk for kollisjoner.

Kan jeg bruke Super Socializer bare for innlogging, uten deling og kommentarer?

Ja, utvidelsens moduler er uavhengige. På fanen «Social Sharing» fjerner du avhakingen for alle bokser, så forsvinner «Share»-knappene. På fanen «Social Commenting» deaktiverer du integrasjonen. La bare «Social Login» stå igjen med leverandørene du trenger. Utvidelsen er lett, og deaktivering av unødvendige moduler påvirker ikke ytelsen.

Er det trygt å deaktivere PublishPress Capabilities etter å ha opprettet en rolle?

Ja. WordPress-roller og -kapabiliteter lagres i wp_options-tabellen (feltet wp_user_roles) og avhenger ikke av utvidelsen som opprettet dem. Etter deaktivering av PublishPress Capabilities bevares alle opprettede roller og tildelte tillatelser. Du kan reaktivere utvidelsen hvis du trenger å endre tillatelser senere.

Bør du skrive kode eller holde deg til utvidelser

Valget mellom utvidelser og functions.php koker ned til to faktorer: antall CPT-er som beskyttes og hvor ofte tillatelser endres.

Hvis du bare har én CPT (som utstyrseksempelet), rollene er stabile og du er villig til å skrive 30 linjer kode én gang, er functions.php-tilnærmingen renere: den skaper ikke utvidelser, avhenger ikke av tredjepartsoppdateringer og er fullstendig transparent. Du kan beholde Super Socializer for sosial innlogging, siden den løser en smal oppgave og ikke kommer i konflikt med egendefinert kode.

Hvis du har flere CPT-er, tillatelser revideres ofte eller nettstedet administreres av en ikke-utvikler, gå for utvidelseskombinasjonen. CPT UI + PublishPress Capabilities + WP Access Areas (eller ContentGate) kan konfigureres fra admin-panelet på 15 minutter uten å røre kode. I tillegg tar PublishPress Capabilities automatisk sikkerhetskopi av roller ved hver endring, noe som muliggjør tilbakerulling med to klikk.

I ethvert scenario, følg prinsippet: ett verktøy for én oppgave. Ikke installer en kraftfull alt-i-ett-løsning for én enkelt avhukingsboks, og ikke finn opp hjulet på nytt hvis en eksisterende utvidelse gjør nøyaktig det samme raskere og sikrere.

Versjonskontroll fortjener separat vurdering. Kode fra functions.php lever i temalageret, endringer spores gjennom Git, og ved migrering av nettstedet gjenskapes roller automatisk på after_switch_theme-hooken. Utvidelsestilnærmingen tilbyr ikke denne transparensen: roller lagres i databasen, og ved deployering av en staging-kopi eller overføring til et nytt domene må de gjenskapes manuelt eller via et migreringsskript. Denne faktoren blir ofte avgjørende til fordel for kode for team som praktiserer CI/CD og Git-basert deployering.