Miksi WordPress 7.1 muuttaa ACF-lohkojen sisällönsyöttöä?

Sisällönsyöttäjä avaa sivun muokkausnäkymän uusimman WordPress-päivityksen jälkeen. Lohkon kentät eivät ole enää siellä, missä ne olivat aiemmin. Sivusto itse toimii normaalisti. Kyse ei ole viasta vaan arkkitehtuurimuutoksesta, jota WordPress on valmistellut vuodesta 2021.

Kirjoittaja: Jukka Isokoski

9.9.2026

Uutiset

WordPressin uusin versiopäivitys 7.1 näyttää sisältöeditorin sisältöalueen aina iframe-kehyksessä. Muutos vaikuttaa sivustoihin, joilla on käytössä ACF-laajennuksen (Advanced Custom Fields) avulla toteutettuja lohkoja. Lohkojen kentät eivät enää avaudu editorin sisältöalueelle, vaan ne siirtyvät sivupalkkiin tai erilliseen muokkausikkunaan.

Julkinen sivusto ei muutu. ACF-lohkot ovat dynaamisia lohkoja, joiden sisältö tuotetaan palvelimella joka sivulatauksella. Lohkojen kenttäarvot säilyvät sisällössä sellaisenaan. Muutos ei edellytä sisällön uudelleentallennusta eikä tietokantamuutoksia. Kaikki vaikutukset kohdistuvat sisällönsyöttäjän muokkausnäkymään.

Teemme WordPress-päivityksen ylläpitoasiakkaillemme hallitusti. Testaamme ACF-lohkojen toiminnan ennen päivitystä ja teemme tarvittavat muutokset ensin. Näin sisällönsyöttö toimii heti päivityksen jälkeen.

Mutta miksi tämä muutos on ylipäänsä tarpeellinen? Tähän vastaaminen edellyttää pientä katsausta menneeseen.

WordPressin pitkä siirtymä iframe-malliin

Kun lohkoeditori julkaistiin vuonna 2018, editorin muokkausalue oli teknisesti osa WordPressin hallintasivua. Sama dokumentti sisälsi siis hallintanäkymän valikot ja muokattavan sisällön. Tästä seurasi ongelmia kahteen suuntaan. Hallintanäkymän tyylit vuotivat sisältöön, ja teeman tyylit vuotivat hallintanäkymään.

Seuraus näkyi sisällönsyöttäjälle. Muokkausnäkymä ei aina vastannut valmista sivua. Esimerkiksi näkymän leveyteen sidotut CSS-tyylit eivät toimineet, koska arvona toimi hallintanäkymän, ei sisältöalueen leveys.

Iframe ratkaisee tämän ongelman. Sisältöalue saa oman dokumentin, jossa vaikuttavat vain teeman ja lohkojen omat tyylit. Tämä on edellytys sille, että lohkoeditori voi toimia WYSIWYG-periaatteen mukaisesti: sisällönsyöttäjä näkee sisällön samanlaisena kuin sivuston käyttäjä. Samalla ratkaisu vapauttaa myös hallintanäkymän tyylien kehittämisen, koska muutokset eivät enää vuoda lohkoihin.

Siirtymä on ollut pitkä. Se alkoi vuonna 2021. Ensin iframeen vietiin sivupohja-editori ja sen jälkeen sivusto-editori. Vuonna 2023 lohkot saivat uuden versionumeron (v3), jolla kehittäjä ilmoittaa lohkon toimivan iframen sisällä. Editori vaihtoi kuitenkin iframe-malliin vain silloin, kun sivuston kaikki lohkot tukivat tätä versiota eikä sivustolla ollut vanhoja metabox-kenttiä. Pakottaminen uuteen malliin peruttiin kahdesti yhteensopivuusongelmien vuoksi. Keväällä 2026 julkaistu WordPress 7.0 käänsi oletuksen. Ehtoa ei enää arvioitu koko sivuston lohkovalikoiman perusteella, vaan yksittäisen sivun sisällön perusteella. Iframe oli siis päällä, ellei kyseisellä sivulla ollut vanhemman version lohkoja. Versio 7.1 poistaa tämän tarkistuksen kokonaan ja iframe on aina päällä.

Miksi muutos osuu juuri ACF-lohkoihin?

ACF julkaistiin vuonna 2011. Sen alkuperäinen tehtävä oli monipuolistaa WordPressin metakenttien hallintaa. WordPressin Core tarjosi vain yksinkertaisen ja hieman kömpelön mallin metakenttien hallintaan. ACF tarjosi rinnalle kenttätyypit, jotka vastasivat erilaisia käyttötarpeita. Kuvat, listat, linkit, tekstieditorikentät ja sisältöjen väliset suhteet saivat kukin oman kenttätyyppinsä.

Moni kenttätyyppi rakentui ulkopuolisten jQuery-kirjastojen varaan. Se oli aikakauden tapa toteuttaa interaktiivisia käyttöliittymiä hallintanäkymässä. Nykyisin verkon käyttöliittymien toteutuksessa yleinen React-kirjasto julkaistiin vasta kaksi vuotta myöhemmin, ja WordPressin oma lohkoeditori oli vielä kauempana tulevaisuudessa.

Myöhemmin ACF laajeni sisältöeditorin ulkopuolelle. Samat kenttäryhmät alkoivat palvella taksonomiatermien muokkausnäkymiä, käyttäjäprofiilen hallintaa, valikkojen muokkausta ja sivuston asetussivuja.

Kun Gutenberg julkaistiin vuonna 2019, Reactin valinta tekniseksi ratkaisuksi herätti keskustelua kehittäjien parissa. Monen mielestä uusi javascript-kirjasto nosti lohkojen kehittämisen kompleksisuutta. ACF vastasi tähän tarjoamalla tavan tehdä lohkoja ilman Reactia. ACF hoiti editorin käyttöliittymän omilla kenttävalitsimillaan, ja lohkon tulostus voitiin kirjoittaa PHP:lla.

Ratkaisu oli kustannustehokas. Editorin käyttöliittymää ei tarvinnut suunnitella eikä toteuttaa erikseen, koska valmis kenttälomake kelpasi sellaisenaan. Coren oma dokumentaatio lohkojen kehittämiseen oli tuolloin nykyistä ohuempi. Tästä syystä moni digitoimisto Suomessa, myös redandblue, valitsi ACF:n räätälöityjen lohkojen toteutustavaksi.

ACF:n toteutustapa sisältää riippuvuuden, joka on ristiriidassa uuden iframe-kehyksen kanssa. ACF lataa resursseja hallintanäkymän kautta, esimerkiksi jQuery-kirjastot ja tekstieditorin. Iframen sisällä nämä eivät ole saatavilla.

ACF ei voinut käytännössä ratkaista tätä ongelmaa uudelleenkirjoittamalla kenttäkäyttöliittymää Reactilla. ACF oli muodostanut rajapinnan, jolla kehittäjät voivat luoda omia kenttätyyppejään. Keskitetty muutos olisi rikkonut kenttien ekosysteemin. Lisäksi sama ACF:n kenttälomake palvelee edelleen niitä näkymiä, joissa Reactia ei ole lainkaan käytössä.

ACF:n ratkaisu on siirtää kenttien muokkaus iframen ulkopuolelle. Kenttäkäyttöliittymää ei kirjoitettu uudelleen, vaan sen sijainti vaihdettiin. Se on ACF:n tapa saavuttaa yhteensopivuus iframe-mallin kanssa.

Mitä tapahtuu, jos muutoksia ei tehdä?

Jos ACF-lohkoja sisältävä sivusto päivitetään WordPress versioon 7.1. ilman, että tehdään mitään muita päivityksiä, sivuston julkinen puoli toimii kuten ennenkin. Muutokset koskevat vain muokkausnäkymää.

Mikäli ACF-lohkot on toteutettu vanhemmalla lohkoversiolla, niiden kentät avautuvat päivityksen jälkeen editorin sivupalkkiin. Sivupalkki on kapea, leveydeltään noin 280 pikseliä. Yksinkertaisen lohkon muokkaaminen tässä näkymässä onnistuu, mutta monikenttäisen lohkon kanssa työskentely on hankalaa.

Jos lohkojen muokkausnäkymään on tehty räätälöityjä tyylejä, ne eivät todennäköisesti näy oikein.

Lohkon esikatselu ei myöskään välttämättä näy oikein sisältöalueella. ACF-lohkoilla oli aiemmin kaksi tilaa, muokkaus ja esikatselu. Aiemmin muokkaustila oli oletuksena päällä. Siksi kaikkien tuon aikakauden lohkojen kohdalla ei ole mietitty, miltä lohkon pitäisi esikatselussa näyttää. Näiden lohkojen osalta editoriin voi ilmestyä teksti ”Lohko palautui tyhjänä”.

ACF-lohkot saadaan käyttökuntoon pienillä muutoksilla

Työ on rajattu ja se voidaan tehdä kertaluonteisesti.

Päivitämme ACF:n uusimpaan versioon ja muutamme lohkot versioon 3. Tämän jälkeen lohkon kentät avautuvat erilliseen muokkausikkunaan. Kentillä on siinä riittävästi tilaa, ja niiden täyttäminen tapahtuu samalla tavalla kuin ennen. Ero on kenttien sijainnissa.

Räätälöidyt editorin tyylit korjataan toimimaan uudessa muokkausikkunassa.

Lohkon tulostuslogiikkaa muokataan niin, että lohko näyttää editorissa järkevältä. Tämä tehdään lohkokohtaisesti ja vain niille lohkoille, joiden esikatselussa on puutteita.

Kannattaa kuitenkin huomata, että kenttien muokkaaminen suoraan ACF-lohkon sisällä ei enää palaa. Muutos tämän osalta on pysyvä, niin kauan kun sivustolla on käytössä ACF-lohkoja. Tämä on hyvä käydä läpi sisällönsyöttäjien kanssa.

Kannattaako jatkossa siirtyä natiivilohkoihin?

Lähtötilanne on toinen kuin vuonna 2019. WordPressiin on sen jälkeen lisätty ominaisuuksia, jotka helpottavat natiivilohkojen kehittämistä. Lohkojen rekisteröinti block.json-tiedostolla on yhtä suoraviivaista kuin ACF:n vastaava malli. Block Bindings API mahdollistaa coren lohkojen sisällön sitomisen omiin kenttiin. Dynaamiset lohkot voidaan tulostaa PHP-tiedostolla. Natiivilohkojen tekeminen on siis helpompaa ja kustannustehokkaampaa kuin aiemmin.

Jatkossakin WordPressin Core kehittyy natiivilohkojen ehdoilla. Tässä artikkelissa käsitellään iframe-muutosta, mutta se ei ole ainoa asia joka tuo muutoksia editoriin. Tulevat versiot voivat tuoda ominaisuuksia, jotka eivät toimi täysimittaisesti coren logiikasta poikkeavilla lohkoilla.

Yhteismuokkaus (real-time collaboration) on konkreettinen esimerkki tästä. Ominaisuus on ollut WordPressin kehityssuunnitelmassa pitkään. Siinä useampi sisällönsyöttäjä voi muokata sisältöä samanaikaisesti. Nykyisessä WordPressissä vain yksi käyttäjä voi ottaa sisällön hallintaansa kerrallaan. Yhteismuokkaus oltiin jo sisällyttämässä version 7.0 julkaisuun, mutta vedettiin pois viime hetkellä yhteensopivuusongelmien vuoksi. Tämä ominaisuus kuitenkin palaa hyvin todennäköisesti jossakin tulevassa WP versiossa. Testauksen yhteydessä on raportoitu, että yhteismuokkaus toimii parhaiten natiivilohkojen kanssa. ACF:n valitsema malli, jossa kenttiä muokataan erillisessä ikkunassa iframen ulkopuolella, on todennäköisesti vaikea sovittaa yhteismuokkauksen työnkulkuun.

Natiivilohkot tarjoavat yleisesti ottaen paremman sisällönsyöttökokemuksen. Otsikkoa muokataan klikkaamalla otsikkoa. Kuva vaihdetaan klikkaamalla kuvaa.

Suunnitelmallisesti kohti natiivilohkoja

ACF-lohkoja sisältävällä sivustolla siirtymä natiivilohkoihin voidaan tehdä hallitusti ja olemassa olevan sisällön ehdoilla. Lohkon tulostus eli se, mitä sivustolla näkyy, voidaan pitää ennallaan. Muutettava asia olemassa olevien lohkojen osalta on editorin käyttöliittymä.

Työtä helpottaa se, että olemme kehittäneet natiivilohkoja pitkään. Redandbluella on valmis lohkokirjasto ja sen käytössä kokoelma yleiskäyttöisiä editorin käyttöliittymäkomponentteja. Esimerkiksi artikkelin tai luokittelutiedon valitsin on valmiina natiivilohkojen kanssa käytettäväksi. Kaikkea ei siis tarvitse tehdä alusta asti räätälöitynä työnä.

Siirtymään liittyy myös haasteita. Tietyt ACF:n rakenteet, kuten toistuvat kenttärivit (repeater) ja vaihtoehtoiset sisältölohkot (flexible content), pitää sovittaa natiivilohkojen arkkitehtuuriin. Tyypillisesti toistuvista riveistä tulee lapsilohkoja, joita lisätään päälohkon sisältöalueelle. Kyse ei ole suorasta käännöksestä vaan rakenteen uudelleensuunnittelusta. Lohkotyypin vaihtaminen olemassa olevassa sisällössä tarkoittaa myös sisällön muuntamista, joten se on eri kokoluokan työ kuin ACF-lohkojen versiopäivitys. Teknisen työn lisäksi sisällönsyöttäjät voivat tarvita uutta ohjeistusta. Nämä asiat otetaan huomioon tiekartassa.

Siirtymää varten kannattaa laatia tiekartta: miten muutokset vaiheistetaan ja missä järjestyksessä. Ensimmäisenä kannattaa muuttaa yksinkertaiset lohkot, joiden osalta työ voi olla hyvinkin pieni. Toiseksi, kaikki uusi kehitys kannattaa ohjata natiivilohkoihin. Tämä ei kasvata toteutuksen työmääriä, mutta uusiin ominaisuuksiin tehty investointi on pitkäikäisempi. Kolmanneksi muutetaan yleisimmin käytetyt lohkot. Vasta viimeisenä muutetaan ACF-lohkot, joilla on tuotettu staattista tai harvoin päivitettävää sisältöä.

ACF ei poistu kokonaan

ACF on edelleen käyttökelpoinen työkalu ja sitä kehitetään aktiivisesti. Sen tuoma lisäarvo lohkojen rekisteröinnissä on vähentynyt, mutta kenttäryhmien hallinnassa se on edelleen vahva. Sivuston asetusten, taksonomiatermien lisätietojen ja käyttäjäkohtaisten kenttien määrittely onnistuu ACF:llä nopeasti.

ACF voi hyvin käyttää jatkossakin monipuolisten kenttien hallinnan työkaluna. Lohkojen kehityksessä kannattaa kuitenkin satsata natiivilohkoihin.