Skip to content

Kaikki WordPressistä, web-kehityksestä — ja paljon muuta

🔒 Kuinka rajoittaa pääsyä WordPressin mukautettuihin sisältötyyppeihin: vaiheittainen opas

🔒 Kuinka rajoittaa pääsyä WordPressin mukautettuihin sisältötyyppeihin: vaiheittainen opas

Kuvittele tämä: julkaisit yritysportaalin WordPressillä, loit räätälöidyn sisältötyypin nimeltä "Laitteet" ja täytit sen sisäisellä dokumentaatiolla. Viikkoa myöhemmin huomaat, että hakukoneet indeksoivat kaikki nämä sivut ja ne näkyvät kenelle tahansa ohikulkijalle. Pääsy pitäisi rajata vain valtuutetuille työntekijöille, mutta teidän portaalissanne se on täysin avoin.

WordPressin sisäänrakennetut työkalut eivät mahdollista tietyn räätälöidyn sisältötyypin valikoivaa rajoittamista rekisteröitymättömiltä käyttäjiltä. Roolit ja käyttöoikeudet ovat olemassa, mutta sidontaa "vieraat eivät näe sisältötyyppiä X" ei ole saatavilla valmiina. Ratkaisu koostuu kolmesta osasta: sisältötyypin rekisteröinnistä, roolien määrityksestä ja lukurajoituslisäosasta. Neljäs (valinnainen) osa on some-kirjautuminen, jotta työntekijöiden ei tarvitse syöttää salasanaa joka kerta.

Lähikuva ruudusta, jossa ohjelmointikoodia, web-kehitys

Alla on vaiheittainen erittely jokaisesta osasta, jossa mainitaan tietyt lisäosat ja asetukset. Kaikki työkalut ovat ilmaisia, saatavilla virallisesta WordPress.org-hakemistosta eivätkä vaadi koodausta, vaikkakin puhdas koodipohjainen lähestymistapa käsitellään lopussa niille, jotka haluavat välttää lisäosat.

💡 Nopea yleiskatsaus:

  • Rekisteröi räätälöity sisältötyyppi Custom Post Type UI:n avulla kirjoittamatta riviäkään koodia
  • Luo räätälöity rooli PublishPress Capabilitiesissa ja määritä se työntekijöille
  • Rajoita sisältötyypin pääsy vierailta WP Access Areas -lisäosalla: valtuuttamattomat kävijät ohjataan kirjautumissivulle
  • Ota valinnaisesti käyttöön some-kirjautuminen Super Socializerin kautta salasanatonta Google-tilikirjautumista varten

Vaihe 1: Räätälöidyn sisältötyypin rekisteröinti

Ensimmäinen ja yksinkertaisin vaihe on itse sisältötyypin luominen. Sinun ei tarvitse koskea functions.php-tiedostoon tätä varten: Custom Post Type UI -lisäosa WordPress.orgissa tarjoaa graafisen käyttöliittymän kaikkien sisältötyyppien ja taksonomioiden rekisteröintiin.

Asennus on vakio: "Lisäosat → Lisää uusi", hae nimellä, aktivoi. Aktivoinnin jälkeen sivupalkkiin ilmestyy uusi valikkokohta: "CPT UI → Lisää/muokkaa sisältötyyppejä". Täytä kentät: polkutunnus (esimerkiksi equipment), monikko- ja yksikkönimet, nimikkeet ja napsauta "Lisää sisältötyyppi".

Custom Post Type UI -liitännäisen käyttöliittymä mukautetun tyypin luomiseen

Lisäosa kutsuu register_post_type()-funktiota oikeilla parametreilla automaattisesti. Manuaalista koodia ei tarvita: saat täysin toimivan sisältötyypin, jossa on editorituki, arkistot ja REST API. Jos myöhemmin tarvitset rekisteröinnin siirtämistä functions.php-tiedostoon, CPT UI näyttää luodun PHP-koodin "Työkalut"-välilehdellä.

Rekisteröinnin aikana kiinnitä huomiota kahteen kriittiseen tietoturvaan liittyvään asetukseen. CPT UI:n "Asetukset"-lohkossa on "Julkisesti kyseltävissä" -lippu, joka määrittää, voidaanko artikkelit avata suorien linkkien kautta. Sen oletusarvo on tosi, ja jopa sen jälkeen, kun lukemista on rajoitettu lisäosan kautta, tämä kannattaa jättää päälle; muuten WordPress palauttaa 404-virheen sen sijaan, että ohjaisi kirjautumissivulle, eivätkä käyttäjät ymmärrä, mitä tapahtui. Toinen parametri, "On arkisto", ottaa käyttöön arkistosivun, joka listaa kaikki sisältötyypin artikkelit. Jos et tarvitse arkistoa, poista se käytöstä, jotta hakukoneet eivät indeksoi palvelusivua, jossa on esikatseluja rajoitetuista dokumenteista.

Vaihe 2: Räätälöidyn roolin luominen

Pelkkä CPT:n käytön rajoittaminen vierailta ei riitä: tarvitset roolin, jolla on käyttöoikeus. WordPress tarjoaa oletuksena kiinteän joukon: Ylläpitäjä, Editori, Kirjoittaja, Avustaja, Tilaaja. Luomme uuden roolin PublishPress Capabilities -lisäosalla (aiemmin nimeltään Capability Manager Enhanced, sama slug, sama toiminnallisuus, vain brändätty uudelleen).

Roolien hallintasivu PublishPress Capabilities -liitännäisessä

Aktivoinnin jälkeen siirry kohtaan "Capabilities → Roles". Näytön oikeasta reunasta löydät "Create New Role" -lohkon:

Lomake uuden mukautetun roolin luomiseksi PublishPress Capabilitiesissa

Anna nimi (esimerkiksi "Equipment Reader"), valitse pohjarooli, josta kloonataan (Tilaaja on paras, siinä on minimaaliset oikeudet), ja klikkaa "Create". Uusi rooli on nyt olemassa, ja voit täyttää sen käyttöoikeuksilla. CPT:n lukemiseen riittää vakioyhdistelmä read + read_equipment (CPT UI:n rekisteröimä käyttöoikeus).

Määritä luotu rooli työntekijöille, jotka tarvitsevat pääsyn rajattuun sisältöön. Tämän jälkeen voit poistaa lisäosan käytöstä: roolit ja käyttöoikeudet säilyvät WordPressin tietokannassa eivätkä ole riippuvaisia PublishPress Capabilitiesin aktiivisuudesta.

Roolien käyttöoikeuksien määrityspaneeli PublishPress Capabilitiesissa

Vaihe 3: CPT:n lukuoikeuden rajoittaminen

Tämä on avainvaihe. WP Access Areas -lisäosalla voit määritellä tarkasti, kuka voi lukea, muokata ja kommentoida kunkin tyypin julkaisuja, aina yksittäisiin sivuihin asti. Sillä on vaatimattomat 400 aktiivista asennusta eikä se ole saanut suuria päivityksiä vähään aikaan, mutta tehtävään "CPT:n rajoittaminen vierailta" se toimii ennustettavasti ja ilman ristiriitoja.

WP Access Areas -liitännäisen sivu WordPressin hakemistossa

Asennuksen jälkeen siirry kohtaan "Settings → Access Areas". "Default Behaviour" -osiossa valitse:

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

Tämä asetus ohjaa valtuuttamattomat käyttäjät osoitteeseen wp-login.php, kun he yrittävät avata minkä tahansa suojatun CPT-sivun.

WP Access Areas -liitännäisen pääkäyttäytymisasetukset

Seuraavaksi näet taulukon kaikista rekisteröidyistä julkaisutyypeistä. Valitse CPT:si kohdalla "Reading"-sarakkeen pudotusvalikosta "Logged in Users". Siinä kaikki: tästä eteenpäin jokainen vieras, joka seuraa suoraa linkkiä CPT-sivulle, ohjataan kirjautumislomakkeelle.

Tärkeä huomio: taulukon kautta tehdyt asetukset koskevat vain uusia julkaisuja. Jo luoduille sivuille sinun on asetettava käyttöoikeudet manuaalisesti editorin sivupalkista, jossa näkyy "Access Areas" -lohko. Määrityksen jälkeen muista tarkistaa tulos selaimesi incognito-tilassa: suoran linkin avaamisen suojatulle CPT-sivulle pitäisi näyttää sinulle wp-login.php, ei sisältöä.

Lukuoikeusasetusten lohko WordPressin artikkelieditorissa

Vaihtoehtoja WP Access Areasille, jos tarvitset aktiivisemmin ylläpidettyä ratkaisua: PublishPress Permissions (ilmainen versio kattaa CPT:t ja roolit) tai ContentGate (kevyt lisäosa, jonka säännöt perustuvat kirjautumistilaan ja rooleihin).

Vaihe 4: somekirjautuminen (valinnainen)

Käyttäjätunnuksen ja salasanan jatkuva syöttäminen yritysportaalissa aiheuttaa turhaa kitkaa. Looginen ratkaisu: yhden klikkauksen kirjautuminen Google-tilin kautta. Super Socializer -lisäosa hoitaa tämän tehtävän, ja sillä on yli 20 000 aktiivista asennusta sekä tuki Googlelle, Facebookille, X:lle (Twitter) ja tusinalle muita palveluntarjoajia.

Yleiskatsaus Super Socializer -liitännäisen sosiaalisen kirjautumisen ominaisuuksiin

Aktivoinnin jälkeen siirry kohtaan "Super Socializer → Social Login":

Sosiaalisen kirjautumisen asetukset-välilehti Super Socializer -liitännäisessä

Perusasetukset: ota käyttöön "Disable user registration via social networks" -valintaruutu. Tämä on tärkeää, jotta vain olemassa olevat tilit voivat kirjautua someverkkojen kautta sen sijaan, että syntyisi uusia tilejä. Valitse sitten palveluntarjoaja (Google) ja syötä Client ID ja Client Secret. Mistä ne saa:

  • Avaa Google Cloud Console, luo projekti (tai valitse olemassa oleva)
  • Kohdassa "APIs & Services → Credentials" klikkaa "Create Credentials → OAuth client ID"
  • Sovellustyyppi on Web application; Authorized redirect URIs -kenttään liitä callback-URL Super Socializerin asetuksista
  • Tallenna, niin saat Client ID:n ja Client Secretin
OAuth-asiakkaan luominen Google Cloud -konsolissa sosiaalista valtuutusta varten

Kopioi avaimet lisäosan kenttiin:

Client ID- ja Client Secret -kenttien täyttäminen Googlen valtuutusta varten Super Socializerissa

Kriittinen kohta: Authorized redirect URIs -kentän lopussa ei saa olla kauttaviivaa, tai saat redirect_uri_mismatch-virheen. Tallennuksen jälkeen kirjautumissivulle ilmestyy "Sign in with Google" -painike.

Tärkeää: tämän kirjoituksen alkuperäinen versio (2020) kuvasi integraation Google+:n kanssa, joka suljettiin huhtikuussa 2019. Nykyaikainen Super Socializer käyttää tavallista Google OAuth 2.0 -protokollaa Google Identity Servicesin kautta. Google Cloud Consolen käyttöliittymä on päivittynyt sen jälkeen, mutta vaiheiden logiikka (projekti → Credentials → OAuth client ID → redirect URI) on pysynyt samana.

Vaihtoehtoinen lähestymistapa: kaikki koodissa

Jos lisäosat eivät ole toivottavia, tehtävän voi ratkaista teeman functions.php-tiedostossa tai lapsiteemassa. Koodi rekisteröi CPT:n, luo roolin ja kytkee valtuutustarkistuksen sivupohjaan:

1// Registering a custom post type
2function 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}
12add_action('init', 'register_equipment_cpt');
13
14// Creating a role on theme activation
15function add_equipment_reader_role() {
16 add_role('equipment_reader', 'Equipment Reader', ['read' => true, 'read_equipment' => true]);
17}
18add_action('after_switch_theme', 'add_equipment_reader_role');
19
20// Redirecting guests from CPT to login page
21function 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}
27add_action('template_redirect', 'restrict_equipment_to_logged_in');

Mitä tämä koodi tekee: ensimmäinen lohko rekisteröi CPT:n equipment omalla kyvykkyystyypillään (capability_type). Toinen lohko luo Equipment Reader -roolin, jolla on oikeudet lukea tätä CPT:tä, kun teema aktivoidaan. Kolmas lohko tarkistaa valtuutuksen template_redirect-koukussa ja ohjaa vierailijat wp-login.php-sivulle.

Koodilähestymistavan etu: ei ylimääräisiä lisäosia, täysi hallinta. Haitta: somekirjautuminen vaatii silti lisäosan (OAuth-integraation kirjoittaminen käsin on aikaavievää ja tietoturvariski), ja jokainen roolimuutos tarkoittaa koodin muokkaamista.

⁉️🤔 Usein kysytyt kysymykset

Voinko rajoittaa CPT:tä ilman lisäosia, pelkillä funktioilla.php?

Kyllä. Yhdistelmä register_post_type() + add_role() + template_redirect-koukku ja is_user_logged_in()-tarkistus on täysin toimiva ratkaisu. Koodi on edellisessä osiossa. Somekirjautuminen ilman lisäosaa on huomattavasti vaikeampaa toteuttaa: manuaalinen OAuth-integraatio vaatii tokenien, tilan ja tietoturvan käsittelyä.

Miksi WP Access Areas eikä uudempi lisäosa kuten ContentGate?

WP Access Areas on minimalistinen työkalu tiettyyn tehtävään: "rajoita sisältötyyppi vierailijoilta." Se ei tuo mukanaan sääntörakentajaa, visuaalisia editoreja eikä tilauksia. Jos tarvitset monimutkaisempaa logiikkaa (esimerkiksi eri käyttöoikeustasoja eri rooleille samassa CPT:ssä), käytä ContentGatea tai PublishPress Permissionsia, joita päivitetään aktiivisesti. Tämän oppaan perusskenaarioon WP Access Areas riittää.

Mitä teen, jos vierailijat näkevät yhä CPT-sivuja määritysten jälkeen?

Kolme tyypillistä syytä. Ensimmäinen: WP Access Areas -taulukon "Logged in Users" -asetus koskee vain uusia julkaisuja; olemassa oleville sivuille käyttöoikeudet on asetettava manuaalisesti editorin sivupalkista. Toinen: välimuistilisäosa tarjoilee vierailijoille välimuistissa olevan version sivusta; tyhjennä välimuisti ja määritä poikkeukset suojatulle CPT:lle. Kolmas: CPT on rekisteröity asetuksella 'publicly_queryable' => true ja polkutunnus on ristiriidassa julkisen sivun kanssa; tarkista päällekkäisyydet.

Voinko käyttää Super Socializeria vain kirjautumiseen, ilman jakamista ja kommentointia?

Kyllä, lisäosan moduulit ovat itsenäisiä. "Social Sharing" -välilehdellä poista valinnat kaikista ruuduista, jolloin "Share"-painikkeet katoavat. "Social Commenting" -välilehdellä poista integraatio käytöstä. Jätä vain "Social Login" ja tarvitsemasi palveluntarjoajat. Lisäosa on kevyt, eikä tarpeettomien moduulien poistaminen käytöstä vaikuta suorituskykyyn.

Onko turvallista poistaa PublishPress Capabilities käytöstä roolin luomisen jälkeen?

Kyllä. WordPressin roolit ja kyvykkyydet tallennetaan wp_options-tauluun (wp_user_roles-optio), eivätkä ne riipu ne luoneesta lisäosasta. PublishPress Capabilitiesin käytöstä poistamisen jälkeen kaikki luodut roolit ja myönnetyt oikeudet säilyvät. Voit aktivoida lisäosan uudelleen, jos haluat muokata oikeuksia myöhemmin.

Kannattaako kirjoittaa koodia vai pysyä lisäosissa

Valinta lisäosien ja functions.php-tiedoston välillä riippuu kahdesta tekijästä: suojattavien CPT:iden määrästä ja siitä, kuinka usein käyttöoikeudet muuttuvat.

Jos sinulla on vain yksi CPT (kuten kalustoesimerkissä), roolit ovat vakaat ja olet valmis kirjoittamaan 30 riviä koodia kerran, functions.php-lähestymistapa on siistimpi: se ei tuota lisäosia, ei ole riippuvainen kolmannen osapuolen päivityksistä ja on täysin läpinäkyvä. Voit pitää Super Socializerin somekirjautumista varten, koska se ratkaisee kapean tehtävän eikä ole ristiriidassa oman koodin kanssa.

Jos sinulla on useita CPT:itä, käyttöoikeuksia tarkistetaan usein tai sivustoa hallinnoi ei-kehittäjä, valitse lisäosayhdistelmä. CPT UI + PublishPress Capabilities + WP Access Areas (tai ContentGate) voidaan määrittää hallintapaneelista 15 minuutissa koskematta koodiin. Lisäksi PublishPress Capabilities varmuuskopioi roolit automaattisesti jokaisen muutoksen yhteydessä, mikä mahdollistaa palautuksen kahdella napsautuksella.

Noudata joka tapauksessa periaatetta: yksi työkalu yhteen tehtävään. Älä asenna raskasta kaikki yhdessä -ratkaisua yhden valintaruudun takia, äläkä keksi pyörää uudelleen, jos olemassa oleva lisäosa tekee täsmälleen saman asian nopeammin ja turvallisemmin.

Versionhallinta ansaitsee erillisen huomion. functions.php-tiedoston koodi elää teeman repositoriossa, muutoksia seurataan Gitin kautta, ja sivustoa siirrettäessä roolit luodaan automaattisesti uudelleen after_switch_theme-koukussa. Lisäosalähestymistapa ei tarjoa tätä läpinäkyvyyttä: roolit on tallennettu tietokantaan, ja staging-kopiota julkaistaessa tai uudelle domainille siirryttäessä ne on luotava uudelleen manuaalisesti tai migraatioskriptin avulla. Tämä tekijä kallistaa usein vaa'an koodin puoleen tiimeissä, jotka käyttävät CI/CD:tä ja Git-pohjaista julkaisuprosessia.