Mikä vanhassa versiossa oli vikana?

Minulla oli vanhalla sivustolla PHP-skripti, joka haki samat listat. Se latasi jokaisen ravintolan sivun, poimi XPath-valitsimella lounasosion HTML:n ja liimasi sen sellaisenaan omalle sivulleni. Välimuistina oli tekstitiedosto, joka vanheni tunnissa. Tämän päivän nimi korostettiin JavaScriptillä säännöllisellä lausekkeella.

Se toimi, mutta siivouskoodin tekeminen oli iso työ. Sivulle tuli viiden eri sivuston HTML, josta piti karsia kaikki ylimääräinen, jotta listat näyttivät samalta. Siivoussääntöjä kertyi: tämä otsikko pois, tuo lomake pois, hinta pois yhdeltä ravintolalta. Turhat sanat ja sitovat välilyönnit poistettiin säännöllisillä lausekkeilla. Kun ravintola vaihtoi sivustonsa teemaa, valitsin lakkasi löytämästä mitään. Sivulla luki silloin vain "No menu found".

Miten uusi botti toimii?

Uusi versio on kaksi Firebasen Cloud Functionia samassa projektissa kuin tämä sivusto.

1. Ajastettu haku käynnistyy maanantaista lauantaihin neljä kertaa päivässä. Se hakee ravintoloiden sivut ja poimii lounasosion tekstinä Cheeriolla. Rivinvaihdot säilyvät, jotta listan rakenne näkyy.
2. Gemini jäsentää tekstin. Teksti lähtee Vertex AI:n kautta Gemini 3.5 Flash-Lite -mallille yhdessä JSON-skeeman kanssa. Skeema määrää, mitä vastauksessa on: viikkonumero, päivät, ruoat, ruokavaliomerkinnät, hinnat ja lisukkeet. Vertex AI:n rakenteinen tuloste pakottaa vastauksen skeeman muotoon, joten koodin ei tarvitse arvailla, mitä mallilta tulee.

Samasta listasta Gemini palauttaa tällaisen JSONin (ote maanantailta):

{
  "viikko": 43,
  "paivat": [
    {
      "paiva": "maanantai",
      "pvm": "2026-10-19",
      "ruoat": [
        { "nimi": "Aseman kebab ja tsatsiki",
          "ruokavaliot": ["L", "G"], "hinta": "" },
        { "nimi": "Kasvisriisiä",
          "ruokavaliot": ["M", "G"], "hinta": "" },
        { "nimi": "Broilerikiusausta",
          "ruokavaliot": ["L", "G"], "hinta": "" }
      ],
      "lisat": ""
    }
  ]
}

Päivämäärä on päätelty otsikon viikosta. Sulkeissa olevat pienet kirjaimet ovat muuttuneet yhtenäisiksi ruokavaliomerkinnöiksi.

3. Tulos tallennetaan JSON-tiedostona Cloud Storageen.
4. Sivu piirretään palvelimella siitä JSONista. Firebasen CDN pitää valmiin sivun välimuistissa kymmenen minuuttia, joten sivu aukeaa heti eikä kävijä koskaan odota kielimallia.

Gemini kutsutaan vain, kun ravintolan teksti on muuttunut edellisestä hausta. Botti laskee tekstistä tiivisteen ja vertaa sitä edelliseen. Käytännössä malli ajetaan kerran viikossa ravintolaa kohden sekä silloin, kun ravintola korjaa listaansa kesken viikon.

Miksi kielimalli eikä pelkät valitsimet?

Viidellä ravintolalla on viisi tapaa kirjoittaa lounaslista. Yksi kirjoittaa "MAANANTAI 19.10." omalle rivilleen, toinen laittaa viikonpäivät taulukkoon, kolmas listaa lisukkeet ja hintaan sisältyvän kahvin jokaisen päivän perään. Ruokavaliomerkinnät ovat milloin suluissa, milloin pilkuilla erotettuina ruoan perässä.

Jokaiselle sivulle voisi kirjoittaa oman jäsentimen, mutta ne hajoavat juuri silloin, kun ravintola muuttaa jotain. Kielimalli lukee listan niin kuin ihminen lukee sen. Kun Gemini palauttaa saman muotoisen JSONin jokaisesta ravintolasta, kaikki kortit näyttävät samalta, ruokavaliot voi näyttää yhtenäisinä merkintöinä ja tämän päivän lounaat voi poimia suoraan.

Valitsimia tarvitaan silti, mutta enää vain rajaamaan, mistä kohtaa sivua lista löytyy. Jos valitsin ei löydä mitään, botti antaa Geminille koko sivun tekstin ja kirjaa varoituksen lokiin. Lista näkyy silloinkin. Lokista näen, että valitsin kannattaa päivittää.

Riittääkö halvin malli?

Riittää. Analytiikka-agenttini käyttää Googlen isointa mallia, Gemini 4 Argonia, mutta lounaslistan muuttaminen JSONiksi on pieni tehtävä: syötteenä on alle 1 500 merkkiä tekstiä eikä siinä tarvita päättelyä. Kokeilin Flash-Lite -mallia kaikilla viidellä ravintolalla ja tulos oli oikein ensimmäisellä kerralla. Varalla on isompi Flash-malli, jos Flash-Lite ei vastaa.

Kielimalli voi aina muuttaa sisältöä. Siksi ohje kieltää mallia keksimästä, kääntämästä tai korjaamasta ruokien nimiä. Lisäksi mallin satunnaisuutta säätelevä lämpötila-asetus on nollassa, jotta tulos ei vaihtele ajokerrasta toiseen. Sivulla kerrotaan, että listat haetaan automaattisesti.

Mitä muuta tein toisin kuin ennen?

• Vanhentunut lista tunnistetaan. Jos ravintola ei ole vielä päivittänyt listaansa uudelle viikolle, kortissa lukee, miltä viikolta lista on. Vanhaa ruokaa ei näytetä tämän päivän lounaana.
• Hakuvirhe ei tyhjennä sivua. Jos ravintolan sivu ei vastaa, edellinen onnistunut lista jää voimaan.
• Botti esittäytyy rehellisesti. Vanha skripti esiintyi Googlebotina. Uusi kertoo User-Agent-otsakkeessa, mikä se on ja mistä se tulee.
• Sivu toimii ilman JavaScriptiä. Päivävalinta toimii tavallisilla linkeillä. Saavutettavuus on tarkistettu samalla tavalla kuin muulla sivustolla.

Mihin muuhun samaa tapaa voi käyttää?

Sama malli sopii moneen yritysten arkiseen ongelmaan: tieto on jonkun toisen sivulla, PDF:ssä tai sähköpostissa vapaana tekstinä ja se pitäisi saada omaan järjestelmään. Haku ja tallennus tehdään tavallisella koodilla. Kielimalli tekee vain sen osan, joka on ennen vaatinut ihmisen: tekstin tulkinnan. Tällaisia integraatioita ja tekoälyagentteja rakennan myös asiakkaille.

Usein kysyttyä

Paljonko tällainen botti maksaa ylläpitää?

Käytännössä ei juuri mitään. Gemini ajetaan vain listan muuttuessa. Yksi lista on muutama sata tokenia. Cloud Functions ja Cloud Storage pysyvät tällä käyttömäärällä pienissä senttisummissa.

Saako ravintoloiden lounaslistoja hakea automaattisesti?

Listat ovat julkisia ja botti hakee ne harvoin: neljä kertaa päivässä yhden sivun ravintolaa kohden. Botti esittäytyy ja sivulla linkitetään jokaisen ravintolan omaan listaan. Jos ravintola ei halua olla mukana, poistan sen.

Voiko listaan lisätä ravintolan?

Voi. Uusi ravintola on yksi rivi asetuksissa: nimi, osoite ja valitsin, josta lista löytyy. Jos valitsinta ei ole, Gemini etsii listan koko sivun tekstistä.

Miksi tästä tuli niin iso hässäkkä?

Tavallisesti haavoittuvuus on yksittäisessä lisäosassa tai sovelluksessa ja se koskee vain niitä, jotka sitä käyttävät. Nyt vika oli PHP:ssä itsessään. PHP:n tiedotteen mukaan se koskee kaikkia verkkopyyntöjä palvelevia PHP-asennuksia, ajettiinpa PHP:tä PHP-FPM:llä, Apachen mod_php:llä, php-cgi:llä, FrankenPHP:llä tai LiteSpeedillä. Riski on suurin mod_php:llä, jossa hyökkäys voi käynnistyä yhdellä pyynnöllä ennen kuin sovelluksen koodia on ajettu lainkaan.

Haavoittuvuudet löytänyt Wiz Research kertoo, että ne ulottuvat lähes kaikkiin PHP-versioihin aina 5.4:stä asti. Wiz osoitti toimivan hyökkäyksen WordPressiä, Drupalia ja Joomlaa vastaan. Kun PHP pyörittää valtaosaa verkkosivuista, haavoittuvien palvelimien määrä on valtava.

Teknisesti kyse on muistinhallinnan virheistä. Kun PHP:n muisti loppuu kesken pyynnön käsittelyn, sisäinen tila voi jäädä puolivalmiiksi tai viitata jo vapautettuun muistiin. Seuraava pyyntö samassa prosessissa voi sitten käyttää tätä rikkinäistä tilaa. Wizin mukaan samalla tavalla voi myös vuotaa muistin sisältöä, kuten salasanoja ja avaimia.

Tilannetta pahensi vuoto. Julkistuksen piti tapahtua torstaina 22.10., mutta Huntressin mukaan tiedot haavoittuvuuksista ilmestyivät Hacker Newsiin jo maanantaiaamuna 20.10. Viesti poistettiin, mutta kuvakaappaukset ehtivät levitä. PHP aikaisti julkaisua yhdellä päivällä ja ilmoitti korjausten tulevan keskiviikkona 21.10.

Mitä paikkaaminen vaati?

Tämän tapauksen tärkein asia on se, että WordPressin, teeman tai lisäosien päivitys ei auta. Korjaus pitää asentaa palvelimelle, eli sen tekee ylläpitäjä tai hosting-palvelu.

• Hallinnoidussa hostingissa palveluntarjoaja hoitaa päivityksen. Esimerkiksi Seravo ilmoitti, ettei sen asiakkaiden tarvitse tehdä mitään.
• Omalla palvelimella tai VPS:llä PHP pitää päivittää itse heti, kun käyttöjärjestelmän paketit ovat saatavilla. Sen jälkeen PHP-prosessit pitää käynnistää uudelleen.
• Vanhoilla PHP-versioilla tilanne on hankalin. PHP 8.1 ja sitä vanhemmat eivät saa enää virallisia päivityksiä. PHP julkaisi versioille 7.4–8.1 vain lähdekooditason korjaukset, joten käytännössä ainoa kestävä ratkaisu on nostaa PHP vähintään versioon 8.2.

PHP:n tiedote listaa asetuksia, jotka pienentävät riskiä, mutta painottaa, etteivät ne tee asennuksesta turvallista. Ainoa kunnollinen korjaus on päivitys.

Mitä paikkauksen jälkeen kannattaa tarkistaa?

Kun PHP on päivitetty, uusia hyökkäyksiä näitä aukkoja vastaan ei enää voi tehdä. Jos sivusto oli kuitenkin haavoittuvana verkossa vuodon ja paikkauksen välillä, kannattaa tarkistaa jälkikäteen ainakin nämä:

• onko WordPressiin ilmestynyt uusia pääkäyttäjiä
• onko palvelimelle tullut tiedostoja tai muuttunut koodia, jota et tunnista
• näkyykö lokeissa poikkeavia pyyntöjä tai virheitä 20.–21.10. välillä.

Koska haavoittuvuus voi vuotaa muistin sisältöä, mieti myös salaisuuksien vaihtamista: tietokannan salasana, wp-config.php:n avaimet sekä rajapinta-avaimet esimerkiksi maksupalveluun tai ERP:hen. Tiedot hyökkäyksistä ovat ristiriitaisia. watchTowr kertoo havainneensa hyödyntämistä houkutuspalvelimillaan jo 21.10., kun taas Huntress ei ollut nähnyt hyökkäyksiä asiakkaillaan vielä saman päivän iltapäivänä. Kannattaa olettaa, että aukkoja yritetään hyödyntää. Tarkistukset kannattaa tehdä sen mukaan.

Kuinka nopeasti seuraava aukko löytyy?

Todennäköisesti aiempaa nopeammin. Wiz kertoo käyttäneensä tekoälymalleja haavoittuvuuksien etsimiseen ja hyökkäyksen rakentamiseen ja yksi tutkija teki noin viikossa työn, johon olisi aiemmin mennyt huippuryhmältä kuukausia. Wiz arvioi myös, että samasta virhetyypistä on todennäköisesti muitakin muunnelmia.

Sama työkalu toimii molempiin suuntiin. Tekoäly auttaa löytämään vuosia piilossa olleita vikoja ennen kuin niitä käytetään hyväksi, mutta se myös lyhentää aikaa julkistuksesta toimivaan hyökkäykseen. Sivuston omistajalle tämä tarkoittaa sitä, että päivitykset pitää saada asennettua päivissä, ei kuukausissa.

Pitäisikö WordPressistä ja PHP:stä luopua?

Minun vastaukseni on ei. Kriittisiä haavoittuvuuksia löytyy jokaisesta laajasti käytetystä alustasta. Javan Log4Shell vuonna 2021 on hyvä esimerkki siitä, että sama voi tapahtua missä tahansa. Alustan vaihtaminen ei poista riskiä, vaan vaihtaa sen toiseen.

Olennaisempaa on, miten sivustoa ylläpidetään. Tämän tapauksen jälkeen kysyisin omalta sivustoltani nämä asiat:

1. Onko PHP tuettu versio? PHP 8.2 saa tietoturvakorjauksia vain vuoden 2026 loppuun asti, joten 8.3 tai uudempi on parempi valinta jo nyt.
2. Kuka päivittää palvelimen ja kuinka nopeasti? Hallinnoitu hosting, kuten WordPress-sivustoille Seravo tai Laravel-sovelluksille Laravel Cloud, hoitaa tämän puolestasi. Omalla palvelimella sinun pitää tietää, kuka sen tekee.
3. Seurataanko tilannetta? Joku seuraa tietoturvatiedotteita ja huomaa, kun on kiire.

PHP:n tietoturvatiimi toimi tässä tapauksessa nopeasti: korjaukset julkaistiin noin vuorokausi vuodon jälkeen ja Linux-jakeluille ja tukipalveluille ne oli toimitettu etukäteen. Ongelma ei siis ollut PHP:n ylläpidossa vaan siinä, kuinka moni sivusto pyörii vanhalla versiolla tai palvelimella, jota kukaan ei aktiivisesti päivitä.

Usein kysyttyä

Korjaako WordPressin päivitys PHP2Shell-haavoittuvuuden?

Ei. Haavoittuvuus on PHP:ssä, ei WordPressissä. PHP pitää päivittää palvelimelle versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai uudempaan. Kysy hosting-palvelultasi, onko päivitys tehty.

Mistä näen, mikä PHP-versio sivustollani on?

WordPressissä se näkyy kohdassa Työkalut → Sivuston terveys → Tiedot → Palvelin. Hosting-palvelun hallintapaneelissa näkyy yleensä myös käytössä oleva versio. Pelkkä versionumero, esimerkiksi 8.3, ei riitä, vaan tarkista myös viimeinen numero.

Riittääkö, että sivusto on Cloudflaren takana?

Ei yksinään. Palomuuri voi torjua osan tunnetuista hyökkäysyrityksistä, mutta PHP:n mukaan ainoa täydellinen korjaus on päivitys.

Editorit ja tekoäly

• Sublime Text – nopea ja kevyt editori, kun pitää avata tiedosto heti tai käsitellä isoja tiedostoja.
• Cursor – tekoälyä hyödyntävä koodieditori isompaan kehitystyöhön.
• GitHub Copilot – koodiehdotukset suoraan editoriin.
• Claude – tekoälyavustaja ja Claude Code, jolla tämäkin sivusto on rakennettu.
• ChatGPT ja Gemini – toiset näkökulmat, haku ja vertailu. Eri mallit ovat vahvoja eri asioissa, joten käytän useampaa.

Paikallinen kehitysympäristö

• Laravel Herd – PHP- ja Laravel-kehitysympäristö Macille ja Windowsille. Eri PHP-versiot ja paikalliset sivustot ilman erillistä palvelinasennusta. Uusin lisäys on Herd Studio: selainnäkymä, jossa Herdissä hostattua paikallista sivustoa tai sovellusta kehitetään tekoälyagentin kanssa Lovablen tyyliin esikatselu vieressä.
• DBngin – paikalliset tietokantapalvelimet, kuten MySQL ja PostgreSQL, päälle ja pois yhdellä klikkauksella.
• Sequel Ace – MySQL- ja MariaDB-tietokantojen selaus ja muokkaus.
• Local – paikalliset WordPress-sivustot nopeasti pystyyn.

Palvelimet ja tiedostot

• Google Cloud – tämän sivuston Firebase-hosting ja Cloud Functions sekä Gemini-mallit Vertex AI:n kautta.
• Hetzner + Cloudflare – staging-palvelin Hetznerin Suomen konesalissa Cloudflaren proxyn takana.
• Suomi.fi-palveluväylä – liityntäpalvelin Hetznerin Suomen konesalissa.
• Laravel Forge + Hetzner – Laravel-sovellusten palvelimien asennus, julkaisut ja ylläpito.
• Laravel Cloud – Laravel-sovellusten hosting ilman omaa palvelinta.
• Transmit – tiedostonsiirrot SFTP:llä ja pilvitallennuksiin.

Pienet apurit

• SnippetsLab – oma kirjasto usein tarvittaville koodinpätkille.
• ImageOptim – kuvien pakkaus ennen kuin ne päätyvät sivustolle.
• ColorSlurp – värien poiminta ruudulta ja muuntaminen eri muotoihin.
• Omat pikatoiminnot macOS:ssä – useita itse tehtyjä Quick Actioneita toistuviin tehtäviin suoraan Finderista.

Chrome-lisäosat

• PerfectPixel – asettaa suunnittelijan kuvan sivun päälle läpinäkyvänä kerroksena, jolloin toteutusta voi verrata suunnitelmaan pikselin tarkkuudella.
• GoFullPage – kuvakaappaus koko sivusta yhdellä klikkauksella, myös siitä osasta, joka ei mahdu ruudulle.
• MeetRecorder – itse rakentamani lisäosa, josta lisää alla.

MeetRecorder: palaverista tehtävälistaksi

Rakensin itselleni Chrome-lisäosan, joka tallentaa Google Meet -palaverin äänitiedostoksi. Palaverin jälkeen tallenteesta tehdään tekoälyllä tekstitys ja siitä poimitaan minulle tehtävälista: mitä sovittiin, mitä minun pitää tehdä ja mihin mennessä.

Hyöty on yksinkertainen. Palaverissa voi keskittyä keskusteluun eikä muistiinpanoihin ja mikään sovittu asia ei jää unohduksiin. Tämä on hyvä esimerkki siitä, millaisia pieniä tekoälyagentteja kannattaa rakentaa: selkeä, toistuva tehtävä, jossa lopputuloksen voi tarkistaa nopeasti itse.

Tallentamisesta pitää aina kertoa palaverin muille osallistujille.

Tietoturva

• 1Password – salasanat ja tunnukset.
• NordVPN – suojattu yhteys julkisissa verkoissa.

Miten työ kulkee

Kehitän ensin paikallisesti omalla koneellani. Kun muutos on valmis, se siirtyy Cloudflaren välityspalvelimen takana olevalle testipalvelimelle ja tarkistetaan siellä ennen tuotantoon viemistä. Testipalvelimelle työskentelen SSH-yhteyden yli.

Näin keskeneräinen työ ei koskaan näy sivuston oikeille kävijöille ja jokainen muutos on nähty ja testattu ennen julkaisua. Lisää siitä, miten rakennan sivustoja, löydät WordPress- ja WooCommerce-palvelusta.

Usein kysyttyä

Mikä on paras editori WordPress-kehitykseen?

Se, jota osaa käyttää hyvin. Itse käytän kevyttä Sublime Textiä nopeisiin muutoksiin ja tekoälyä hyödyntävää Cursoria isompaan kehitystyöhön.

Miksi kehittää paikallisesti eikä suoraan palvelimella?

Paikallisesti voi kokeilla rauhassa ilman, että virhe näkyy sivuston kävijöille. Lisäksi työ on nopeampaa, kun jokainen muutos ei kulje verkon yli.

Voiko MeetRecorderin saada omaan käyttöön?

Se on tehty omaan käyttööni. Jos haluat vastaavan työkalun yrityksellesi, voin rakentaa sellaisen sinun tarpeisiisi.

Miten auditti tehtiin?

Auditissa oli kaksi osaa:

1. Automaattinen tarkistus. Ajoin axe-core -työkalun jokaiselle sivulle sekä työpöytä- että mobiilileveydellä. Se löytää muun muassa kontrastivirheet, puuttuvat kenttänimet ja virheelliset rakenteet.
2. Käsin tehdyt tarkistukset. Kävin sivuston läpi pelkällä näppäimistöllä, kapeimmalla 320 pikselin leveydellä ja suurennetuilla tekstiväleillä. Lisäksi tarkistin kosketuskohteiden koot ja liikkuvan sisällön.

Automaattinen tarkistus löytää tyypillisesti vain osan ongelmista. Tässä se löysi yhden kontrastivirheen ja rakennevirheen, jossa sivupalkkialueita (aside) oli sisäkkäin. Kaikki muu alla oleva löytyi käsin.

Kontrasti: punainen teksti ei riittänyt

Sivuston aksenttiväri on punainen. Kahdessa kohdassa sitä oli käytetty tekstinä, eikä kontrasti riittänyt:

• Etusivun animaatiossa punainen teksti tummalla taustalla: kontrasti 3,4:1, kun vaatimus on 4,5:1.
• Lomakkeen virheilmoitus vaalealla taustalla: 4,0:1.

Jälkimmäistä automaattinen tarkistus ei löytänyt, koska virheilmoitus ei ollut näkyvissä testin aikana. Löysin sen laskemalla kontrastit kaikille väriyhdistelmille. Korjaus oli yksinkertainen: tummalle taustalle vaaleampi punainen, vaalealle tummempi. Nyt sivuston ohjeissa on sääntö, että punaista käytetään tekstinä vain näillä kahdella sävyllä.

Vaakavieritys 320 pikselin leveydellä

WCAG 1.4.10 edellyttää, että sivua voi lukea 320 pikselin leveydellä ilman vaakavieritystä. Tämä vastaa tilannetta, jossa käyttäjä suurentaa sivun 400 prosenttiin. Minun sivustollani oli kaksi ongelmaa:

• Yläpalkin valikko ei mahtunut logon viereen.
• Pitkät suomen sanat eivät mahtuneet otsikoihin. "Verkkosivustoja," ja "saavutettavuusauditit" ovat isolla fontilla leveämpiä kuin kapea näyttö.

Suomi on tässä hankala kieli, koska yhdyssanat ovat pitkiä. Korjasin valikon rivittymään ja otin otsikoissa käyttöön tavutuksen, jolloin selain katkaisee pitkät sanat oikeasta kohdasta tavuviivalla.

Animaatio, jota ei voinut pysäyttää

Etusivulla on animaatio, jossa auditin löydöksiä korjataan yksi kerrallaan. Se pyöri loputtomiin, eikä sitä voinut pysäyttää. WCAG 2.2.2 edellyttää, että yli viiden sekunnin ajan jatkuvan liikkeen voi pysäyttää. Liike voi häiritä keskittymistä ja lukemista erityisesti silloin, kun käyttäjällä on tarkkaavaisuuden vaikeuksia.

Sivustolla oli jo huomioitu käyttöjärjestelmän asetus, jolla liikettä voi vähentää. Se ei kuitenkaan riitä, koska kaikki eivät tiedä asetuksesta. Animaatioon tuli pysäytyspainike. Sama korjaus tehtiin myös logoriville, joka liukuu jatkuvasti.

Muut löydökset

• Evästeilmoitus peitti kohdistuksen. Mobiilissa ruudun alalaidassa oleva evästeilmoitus saattoi peittää elementin, johon näppäimistön kohdistus siirtyi (WCAG 2.4.11, uusi kriteeri versiossa 2.2). Lisäksi ilmoitus oli sivun lopussa, joten näppäimistön käyttäjä pääsi siihen vasta koko sivun jälkeen. Nyt ilmoitus on heti alussa, sen voi sulkea Esc-näppäimellä ja sivu jättää sille tilaa.
• Pienet kosketuskohteet. Muutama erillinen linkki ja painike oli 22–23 pikseliä korkea. Uusi kriteeri 2.5.8 edellyttää vähintään 24 pikseliä tai riittävää tyhjää tilaa ympärillä. Väli olisi riittänyt, mutta nostin koot silti.
• Englanninkielinen teksti. Footerissa on nimike "Freelance Web Developer". Ilman kielimerkintää ruudunlukija lukee sen suomen ääntämyksellä.
• Ristiriitainen painikkeen tila. Pysäytyspainikkeessa sekä teksti että ruudunlukijalle kerrottu tila vaihtuivat, mikä tuotti sekavan ilmoituksen.
• Pakolliset kentät. Lomakkeessa ei kerrottu, että kaikki kentät ovat pakollisia.
• Uuteen välilehteen avautuvat linkit. Referenssien linkit avautuvat uuteen välilehteen. Siitä kerrotaan nyt ruudunlukijalle.

Mitä tästä voi oppia?

Ensinnäkin automaattinen tarkistus ei riitä. Tässä se löysi vain kaksi ongelmaa ja kaikki muut löytyivät käsin. Toiseksi WCAG 2.2:n uudet kriteerit, kuten kohdistuksen peittyminen ja kosketuskohteiden koko, jäävät helposti huomaamatta, koska vanhat tarkistuslistat eivät sisällä niitä. Kolmanneksi suomenkielinen sivusto tarvitsee tavutuksen, jos otsikot ovat isoja.

Yksi asia jäi vielä tekemättä: sivustoa ei ole testattu oikealla ruudunlukijalla. Teen sen seuraavaksi, koska rakenne voi olla teknisesti oikein, vaikka lukukokemus ontuu.

Jos haluat saman läpikäynnin omalle sivustollesi, se kuuluu SEO-, GEO- ja saavutettavuusauditteihin.

Usein kysyttyä

Riittääkö automaattinen saavutettavuustarkistus?

Ei. Automaattinen työkalu löytää osan virheistä, kuten kontrastit ja puuttuvat nimet, mutta ei esimerkiksi sitä, peittyykö kohdistus tai voiko animaation pysäyttää. Tässä auditissa suurin osa löydöksistä löytyi vasta käsin.

Mitä uutta WCAG 2.2 toi?

Muun muassa kriteerit kohdistuksen näkyvyydestä, kosketuskohteiden vähimmäiskoosta, raahaamisen vaihtoehdoista ja siitä, ettei käyttäjää pakoteta syöttämään samoja tietoja uudelleen. W3C:n sivulla What's New in WCAG 2.2 on koko lista.

Kuinka kauan korjaukset kestivät?

Tällä pienellä sivustolla kaikki löydökset korjattiin samana päivänä. Isommalla sivustolla korjausten määrä ja laajuus riippuvat siitä, toistuuko sama virhe sivupohjassa vai onko se jokaisessa sisällössä erikseen.

Miten sivusto tehtiin?

Aloitin Clauden chat-käyttöliittymässä, jossa syntyi ensimmäinen versio: rakenne, tyylit ja etusivu. Sen jälkeen siirryin Claude Codeen, joka toimii omalla koneellani. Siinä tekoäly pystyy muokkaamaan tiedostoja, ajamaan komentoja, testaamaan sivua selaimessa ja julkaisemaan muutokset Firebaseen.

Työtapa oli yksinkertainen: kirjoitin, mitä haluan, esimerkiksi "lisää referensseihin asiakas ja suunnittelu" tai "logoticker kahdessa rivissä vastakkaisiin suuntiin". Tekoäly teki muutoksen, testasi sen ja julkaisi sen. Sitten katsoin tuloksen ja annoin palautetta.

Mitä tekoäly teki hyvin?

• Rakenteen ja koodin. Sivusto on staattinen ja blogi ja palvelusivut generoidaan Markdown-tiedostoista. Tekoäly kirjoitti build-skriptin, sivupohjat, sivukartan, RSS-syötteen ja rakenteisen datan.
• Taustapalvelut. Yhteydenottolomake lähettää viestit Cloud Functionin ja Resendin kautta. Tekoäly rakensi funktion, testasi sen paikallisesti valeavaimella ja julkaisi sen.
• Tarkistukset. Se testasi muutokset selaimessa eri leveyksillä, mittasi animaatioiden korkeuksia ja ajoi saavutettavuusauditin koko sivustolle.
• Virheiden löytämisen. Kun pyysin tarkistamaan, oliko chat-vaiheessa tehty jotain tyhmästi, se löysi muun muassa referenssien kuvakaappaukset, jotka olivat moninkertaisesti liian isoja. Ne kutistuivat 7,8 megatavusta 2,3 megatavuun.
• Faktojen tarkistamisen. Blogiartikkeleita varten se haki tiedot lähteistä ja kertoi, kun lähteet olivat ristiriidassa.

Missä se teki virheitä?

Virheitä tuli ja ne kannattaa kertoa:

• Chat-vaiheessa tekoäly ei pystynyt ajamaan koodia, joten yksi riippuvuus puuttui ja ensimmäinen julkaisu epäonnistui.
• Ensimmäinen yritys pakata kuvia tuotti isompia tiedostoja kuin alkuperäiset. Tekoäly huomasi sen itse ja vaihtoi työkalua.
• Evästesuostumuksen peruminen jätti aluksi yhden evästeen poistamatta. Virhe löytyi testissä ja korjattiin.
• Julkaisu jäi kerran odottamaan vastausta kysymykseen, jota kukaan ei nähnyt. Nyt julkaisuskripti ei kysy mitään.

Yhteistä näille on, että ne löytyivät, koska tekoäly testasi omat muutoksensa. Ilman testausta ne olisivat päätyneet tuotantoon.

Missä tarvittiin ihmistä?

• Faktat omasta työstä. Tekoäly ei voi tietää, kuka oli referenssin asiakas tai millä teemalla sivusto on tehty. Se kysyi, eikä arvannut.
• Kieli. Ensimmäisissä teksteissä oli kömpelöä suomea, kuten "Kerro, mitä on tekeillä" ja "konsultoin, missä niistä on hyötyä". Huomasin ne ja pyysin korjaamaan, minkä jälkeen tekoäly kävi kaikki tekstit läpi.
• Makuasiat. Animaation ensimmäinen versio oli kömpelö ja etusivun pääotsikkoa muotoiltiin kahdesti, ennen kuin kirjoitin sen lopulta itse. Tekoäly tekee järkeviä oletuksia, mutta sivustosta tulee omannäköinen vasta, kun joku kertoo, mikä ei toimi.
• Päätökset. Mitä julkaistaan, milloin ja millä päiväyksellä. Kun pyysin päivämäärää, joka olisi tehnyt artikkelista harhaanjohtavan, tekoäly huomautti siitä ja kysyi.
• Tunnukset. API-avaimet ja kirjautumiset hoidin itse. Tekoäly ei nähnyt avaimia missään vaiheessa.

Mitä tästä opin?

Tekoäly ei korvaa kehittäjää, mutta se muuttaa työn. Minun aikani meni päätöksiin, tarkistamiseen ja palautteeseen, ei koodin kirjoittamiseen. Sivusto valmistui murto-osassa siitä ajasta, jonka se olisi muuten vienyt.

Kaksi asiaa ratkaisi lopputuloksen. Ensinnäkin tekoälyllä oli pääsy oikeisiin työkaluihin: se pystyi ajamaan koodia, testaamaan ja julkaisemaan. Chat-vaiheessa, jossa sitä ei voinut tehdä, syntyi eniten virheitä. Toiseksi tekoälyllä oli kirjalliset ohjeet projektista: värit, sävy, julkaisukäytäntö ja säännöt, kuten "kysy referenssin asiakas ennen lisäämistä". Ilman niitä jokainen keskustelu olisi alkanut alusta.

Samat asiat pätevät, kun rakennan tekoälyagentteja asiakkaille: agentti tarvitsee oikeat työkalut, selkeät rajat ja ihmisen hyväksymään tärkeät päätökset.

Usein kysyttyä

Voiko tekoälyllä tehdä verkkosivuston ilman kehittäjää?

Yksinkertaisen sivun voi. Kun mukana on lomakkeita, taustapalveluita, julkaisu ja saavutettavuus, tarvitaan joku, joka ymmärtää tekoälyn tekemiset ja huomaa sen virheet.

Kirjoittiko tekoäly myös tekstit?

Se kirjoitti luonnokset ja minä korjasin ja hyväksyin ne. Artikkeleissa tekoäly haki faktat lähteistä, mutta julkaisupäätös on aina minun.

Onko tekoälyllä tehty sivusto huonompi?

Ei tarvitse olla. Tämä sivusto läpäisi saavutettavuusauditin ja on nopea. Laatu riippuu samoista asioista kuin ennenkin: testaamisesta, tarkistamisesta ja siitä, että joku välittää yksityiskohdista.

Mikä Lovable on?

Lovablen oman kuvauksen mukaan se on full-stack-alusta, joka tuottaa käyttöliittymän, taustapalvelun, tietokannan, kirjautumisen ja integraatiot. Kaikki on muokattavaa koodia. Sovellukset ovat React-sovelluksia ja taustapalvelu on joko Lovablen oma, Supabaseen perustuva Cloud tai oma Supabase-projekti.

Koodi on käyttäjän omaa. Projektin voi synkronoida GitHubiin tai muuhun Git-palveluun, jolloin kehittäjä voi jatkaa sitä tavallisilla työkaluilla ja muutokset kulkevat molempiin suuntiin. Sovellus ei siis jää lukkoon yhden palveluntarjoajan alustalle, toisin kuin suljetuissa kotisivukoneissa.

Esimerkki 1: Reddy

Reddy on palvelu, jolla kuka tahansa voi avata oman paita- ja merch-kaupan ilman varastoa. Käyttäjä rekisteröityy, valitsee tuotteet, lisää omat painatuksensa ja muokkaa kaupan värit ja fontit. Reddy hoitaa tuotannon, maksut ja toimitukset. Etusivulla on interaktiivinen esikatselu, jossa kaupan ulkoasua voi kokeilla ennen rekisteröitymistä. Siellä on myös laskuri, joka näyttää myyjän katteen.

Kyse on kokonaisesta sovelluksesta, jossa on käyttäjätilit, kauppojen hallinta ja tilausten käsittely.

Esimerkki 2: Kaupunkipaidat

Kaupunkipaidat on verkkokauppa, jossa myydään painatuksia satojen suomalaisten kaupunkien ja kuntien sekä tuhansien paikkojen teemalla. Asiakas voi lisäksi suunnitella oman karttapaidan.

Mitä Lovable tekee hyvin?

• Nopeus. Toimiva ensimmäinen versio syntyy tunneissa ja muutokset saa julkaistua heti.
• Ulkoasu. Lopputulos on nykyaikainen ja toimii puhelimella ilman erillistä suunnittelutyötä.
• Taustapalvelut valmiina. Tietokanta, kirjautuminen ja tiedostojen tallennus saadaan ilman palvelinten pystyttämistä.
• Omistaja kehittää itse. Uusi ominaisuus ei vaadi tarjouspyyntöä ja kehitysjonoa, vaan sen voi kuvata ja kokeilla heti.
• Koodi on omaa. Sovellusta voi jatkaa myös ilman Lovablea.

Mihin kannattaa kiinnittää huomiota?

Tietoturva. Vuonna 2025 tietoturvatutkija löysi yli sata Lovablella tehtyä sovellusta, joiden tietokantaan pääsi käsiksi ilman kirjautumista, koska tietokannan käyttöoikeussäännöt puuttuivat. Tapaus sai tunnisteen CVE-2025-48757. Lovable kiistää vastuunsa, koska säännöt ovat kunkin sovelluksen tekijän vastuulla. Siksi jokaisen taulun käyttöoikeudet kannattaa tarkistaa ennen kuin sovellukseen tallennetaan asiakastietoja.

Hakunäkyvyys. Sivujen otsikot, kuvaukset, rakenteinen data ja sivukartta kannattaa määritellä erikseen, kuten millä tahansa alustalla. Lisää aiheesta artikkelissa GEO ja rakenteinen data.

Maksut ja integraatiot. Maksunvälitys, kirjanpito ja toimitukset kannattaa testata huolellisesti myös virhetilanteissa, kuten keskeytyneen maksun tai epäonnistuneen tilauksen siirron kohdalla.

Ylläpito. Kun sovellusta kehitetään pitkään kehotteilla, koodia kannattaa välillä siivota ja yhtenäistää. Sen voi tehdä kehittäjä tai juuri tähän työhön erikoistunut tekoäly.

Milloin Lovable kannattaa?

• Palvelu, jota omistaja haluaa kehittää itse ja nopeasti. Juuri tässä Lovable on vahvimmillaan.
• Sovellus, jossa on kirjautuminen ja omaa logiikkaa, kuten Reddyn kaltainen alusta.
• Uuden palvelun kokeilu oikeilla käyttäjillä ennen isompaa investointia.
• Sisäiset työkalut, joita käyttää pieni joukko ihmisiä.

Sisältöpainotteiseen yrityssivustoon tai verkkokauppaan, jota päivittää moni ihminen ja jossa tarvitaan monikielisyyttä tai valmiita integraatioita, WordPress ja WooCommerce ovat usein edelleen varmempi valinta. Hyvä yhdistelmä voi olla myös Lovablella tehty sovellus WordPress-sivuston rinnalla.

Jos rakennat palvelua Lovablella ja haluat käydä läpi tietoturvan, hakunäkyvyyden tai integraatiot, autan mielelläni. Lue lisää tekoälyratkaisuista.

Usein kysyttyä

Voiko Lovablella tehdä oikean verkkokaupan?

Voi, kuten Reddy ja Kaupunkipaidat osoittavat. Maksut, toimitukset ja käyttöoikeudet kannattaa testata huolellisesti ennen avaamista, kuten minkä tahansa verkkokaupan kohdalla.

Kuka omistaa Lovablella tehdyn koodin?

Lovablen mukaan koodi on käyttäjän omaa. Kun projekti synkronoidaan GitHubiin, kopio on omassa hallinnassa ja kehittäjä voi jatkaa työtä ilman Lovablea.

Voiko WooCommerce-kaupan siirtää Lovableen?

Voi. Tuotteet, asiakkaat ja tilaushistoria viedään WooCommercesta ja tuodaan uuteen tietokantaan ja vanhoista osoitteista tehdään uudelleenohjaukset, jotta hakunäkyvyys säilyy. Käytännössä kauppa rakennetaan uudelleen, mutta Lovablella se onnistuu nopeasti.

Lähtötilanne

Myymälässä myynti, varasto ja kirjanpidon pohjatiedot ovat Winposissa. Verkkokauppa toimii Shopifyssa. Ilman integraatiota saldot pitäisi päivittää verkkokauppaan käsin ja jokainen verkkotilaus kirjata kassaan erikseen. Se vie aikaa ja virheen sattuessa verkkokauppa myy tuotetta, jota ei enää ole.

Miksi serverless-funktiot Google Cloudissa?

Integraatiossa on kaksi selkeästi rajattua tehtävää: saldojen haku ja tilausten vienti. Niihin ei tarvita omaa palvelinta eikä sovellusta, joten valitsin Google Cloud Functions -funktiot. Ne käynnistyvät tarvittaessa, laskutus perustuu käyttöön, eikä ylläpidettävää palvelinta ole. Vertailin integraatioiden ajoympäristöjä tarkemmin integraatiopalvelun sivulla.

Winposin kassa tarjoaa REST-rajapinnan, jonka kautta tuotteet luetaan ja tilaukset viedään. Shopifyn puolella käytetään Shopifyn webhookeja ja Admin API:a.

Osa 1: varastosaldot Winposista Shopifyyn

Ensimmäinen funktio hakee Winposista kaikki tuotteet saldoineen. Ajastus käynnistää haun kahdesti päivässä, kello 6 ja 18.

• Sivutus. Tuotteita on paljon, joten ne haetaan rajapinnasta sata kerrallaan, kunnes kaikki on haettu.
• Saldojen yhteenlasku. Tuotteella voi olla saldoa useammassa varastossa. Funktio laskee ne yhteen ja poimii vain tarvittavat tiedot: EAN-koodin, tuotekoodin ja kokonaissaldon.
• Välimuisti. Koko tuotelistan haku Winposista kestää minuutteja. Siksi tulos tallennetaan Google Cloud Storageen ja Shopifyn puoli lukee saldot sieltä. Vastaus on nopea, eikä kassajärjestelmää kuormiteta joka kerta.

Osa 2: maksetut tilaukset Shopifysta Winposiin

Kun tilaus on maksettu, Shopify lähettää ilmoituksen toiselle funktiolle, joka vie tilauksen Winposiin. Siinä on enemmän tarkkuutta vaativia kohtia.

Ilmoituksen aitous

Funktion osoite on julkinen, joten jokaisen pyynnön aitous tarkistetaan. Shopify allekirjoittaa jokaisen webhookin ja funktio laskee allekirjoituksen itse ja vertaa sitä. Väärennetty pyyntö hylätään ennen kuin mitään tehdään.

Viiden sekunnin sääntö ja jono

Shopifyn ohjeiden mukaan webhookiin pitää vastata viidessä sekunnissa. Muuten Shopify tulkitsee toimituksen epäonnistuneeksi ja yrittää uudelleen. Winposin rajapinta voi vastata hitaammin, joten tilausta ei viedä heti. Se siirretään ensin Google Cloud Tasks -jonoon ja Shopify saa vastauksen saman tien.

Jonolla on kaksi muutakin etua:

• Uudelleenyritykset. Jos Winpos ei vastaa tai hylkää tilauksen, jono yrittää uudelleen kasvavin välein useamman kerran.
• Ei tuplatilauksia. Jonon tehtävä nimetään Shopifyn webhook-tunnisteen mukaan. Jos Shopify lähettää saman ilmoituksen uudelleen, sitä ei lisätä jonoon toista kertaa.

Tilauksen muuntaminen Winposin muotoon

Shopify ja Winpos kuvaavat tilauksen eri tavoin, joten suurin osa koodista on muunnosta:

• Tuotteiden tunnistus viivakoodilla. Shopifyn tilausilmoituksessa ei ole tuotteen viivakoodia, joten funktio hakee sen Shopifyn rajapinnasta tuotteen versioiden tiedoista. Winposissa tuote tunnistetaan juuri viivakoodilla.
• Alennukset. Winposin erillinen alennusrivi vaatisi kassan oman alennustaulukon tunnisteen, jota Shopifyssa ei ole. Siksi alennus netotetaan tuoterivin hintaan.
• Toimituskulut. Winposissa toimituskulut ovat oma tuotteensa, joten ne viedään tuoterivinä.
• Asiakas- ja maksutiedot. Asiakkaan nimi, osoite ja yhteystiedot siirtyvät tilauksen otsikkotietoihin ja maksurivi kirjataan sovitulle maksutavalle.

Kun jokin menee pieleen

Integraatio on rakennettu niin, ettei virhe jää huomaamatta:

• Puuttuva viivakoodi. Jos tuotteelta puuttuu viivakoodi, riviä ei voi viedä Winposiin. Muut rivit viedään, tilaukseen lisätään huomautusrivi ja minulle lähtee sähköpostihälytys, jossa luetellaan puuttuvat tuotteet.
• Winpos hylkää tilauksen. Funktio tarkistaa Winposin vastauksesta, hyväksyttiinkö tilaus. Jos ei hyväksytty, tehtävä palautuu jonoon ja sitä yritetään uudelleen.
• Lokit. Jokaisen tilauksen Shopify-tiedot, Winposiin lähetetty tilaus ja Winposin vastaus kirjataan Google Cloudin lokiin, joten ongelmatilanteen voi selvittää jälkikäteen.

Mitä tästä kannattaa ottaa mukaan

• Sovi kassan asetukset etukäteen. Kassanumero, varasto, kustannuspaikka ja maksutapa sovitaan Winpos-käyttäjän kanssa ennen kuin ensimmäinen tilaus viedään.
• Tuotetiedot ratkaisevat. Integraatio on yhtä luotettava kuin viivakoodit. Kun ne ovat kunnossa molemmissa järjestelmissä, tilaukset kulkevat ilman käsityötä.
• Pieni integraatio ei tarvitse palvelinta. Kaksi rajattua funktiota, ajastus ja jono riittävät. Jos järjestelmiä tulee lisää, sama logiikka siirtyy tarvittaessa omaksi sovelluksekseen.

Jos haluat verkkokaupan ja kassan tai toiminnanohjauksen keskustelemaan keskenään, lue lisää integraatioista.

Usein kysyttyä

Voiko Shopifyn yhdistää Winposiin?

Voi. Winposin REST-rajapinnan kautta saldot saa verkkokauppaan ja verkkotilaukset kassaan. Ennen toteutusta kannattaa selvittää, mitkä rajapinnan ominaisuudet omassa Winpos-ympäristössä ovat käytössä.

Kuinka usein varastosaldot päivittyvät?

Tässä toteutuksessa kahdesti päivässä. Tiheys on asetus, jota voi muuttaa tarpeen mukaan. Tihein mahdollinen päivitysväli riippuu siitä, kuinka paljon kuormaa kassajärjestelmän rajapinta kestää.

Mitä tapahtuu, jos Winpos ei ole tavoitettavissa?

Tilaus jää jonoon ja sitä yritetään uudelleen automaattisesti. Shopifyn puolella tilaus on jo vastaanotettu, joten asiakkaan ostokseen katkos ei vaikuta.

Miksi verkkokauppa on hitaampi kuin tavallinen WordPress-sivusto?

Tavallisen sivuston sivut voi tallentaa välimuistiin kokonaisina. Verkkokaupassa se ei onnistu kaikkialla: ostoskori, kassa ja oma tili ovat jokaiselle kävijälle erilaisia, joten ne lasketaan joka kerta palvelimella. Lisäksi tuotteilla on paljon lisätietoja, varianteja ja hintoja, joita haetaan tietokannasta. Siksi kauppa paljastaa heikon palvelimen tai raskaan lisäosan nopeammin kuin esittelysivusto.

Lisäosat: montako on liikaa?

Lisäosien määrä ei ratkaise, vaan se, mitä ne tekevät jokaisella sivulatauksella. Yksi huonosti tehty lisäosa voi ajaa kymmeniä tietokantakyselyjä joka sivulla, kun taas kymmenen kevyttä ei näy missään.

Käytän mittaamiseen Query Monitor -lisäosaa testiympäristössä. Se näyttää, mikä lisäosa tekee eniten kyselyjä ja mitkä kyselyt ovat hitaita. Usein syyllinen löytyy nopeasti: unohtunut tilastolisäosa, raskas sivunrakentaja tai lisäosa, joka lataa omat tiedostonsa jokaiselle sivulle, vaikka sitä käytetään vain yhdellä.

Tietokanta paisuu huomaamatta

Kolme asiaa kasvattaa WooCommerce-kaupan tietokantaa eniten:

• Tilausten tallennustapa. WooCommerce siirtyi versiossa 8.2 uuteen High-Performance Order Storage -tallennukseen (HPOS), jossa tilaukset ovat omissa tauluissaan. Uusissa kaupoissa se on oletuksena päällä, mutta vanhoissa kaupoissa se pitää ottaa käyttöön itse. Jos kauppasi on avattu ennen syksyä 2023, tarkista tilanne kohdasta WooCommerce → Asetukset → Lisäasetukset → Ominaisuudet.
• Ajastettujen tehtävien loki. WooCommerce ja monet lisäosat käyttävät Action Scheduler -jonoa. Valmiiden tehtävien lokit jäävät tauluihin ja vilkkaassa kaupassa niitä voi olla satojatuhansia rivejä.
• Automaattisesti ladattavat asetukset. WordPress lataa osan asetuksista jokaisella sivulatauksella. Kun lisäosat tallentavat sinne isoja tietoja, jokainen sivu hidastuu. WordPress 6.6 lisäsi Sivuston terveys -työkaluun tarkistuksen, joka varoittaa, kun näitä tietoja on yhteensä noin 800 kt.

Tietokannan siivoaminen tarkoittaa käytännössä rivien poistamista, joten se tehdään aina varmuuskopion kanssa ja ensin testiympäristössä.

Kuinka monta variaatiota on liikaa?

WooCommercessa jokainen tuotteen muunnelma, eli variaatio, on tietokannassa oma tuotteensa: sillä on oma rivi sekä omat hinta-, varasto-, tuotekoodi- ja ominaisuustietonsa. Kun paidalla on viisi kokoa ja kuusi väriä, variaatioita on 30. Kun mukaan tulee vielä materiaali ja painatus, määrä kasvaa nopeasti satoihin.

WooCommerce varautuu tähän itse. Sen ohjeiden mukaan tuotesivun käytös muuttuu, kun variaatioita on yli 30:

• Enintään 30 variaatiota: valikot ovat dynaamisia. Kun T-paidalla on ominaisuudet Koko ja Väri ja asiakas valitsee koon, värivalikko päivittyy näyttämään vain ne värit, joita valitussa koossa on saatavilla.
• Yli 30 variaatiota: valikot ovat staattisia. Värivalikko näyttää kaikki värit, vaikka osaa niistä ei olisi valitussa koossa. Asiakas huomaa sen vasta valittuaan, kun sivulle tulee ilmoitus, ettei yhdistelmää löydy ja pitää valita toinen.

Raja on olemassa suorituskyvyn takia. Jos saatavilla olevat yhdistelmät pitää laskea uudelleen jokaisen valinnan jälkeen, se hidastaa tuotesivua sitä enemmän, mitä enemmän variaatioita on.

Rajaa voi muuttaa suodattimella woocommerce_ajax_variation_threshold, esimerkiksi teeman functions.php-tiedostossa:

add_filter( 'woocommerce_ajax_variation_threshold', function ( $qty, $product ) {
	return 50;
}, 10, 2 );

WooCommerce neuvoo valitsemaan pienimmän arvon, joka kaupalle riittää, koska suurempi raja hidastaa tuotesivuja. Esimerkki nostaa rajan kaikille tuotteille. Suodatin saa parametrina myös tuotteen, joten rajan voi nostaa vain niille tuotteille, jotka sitä oikeasti tarvitsevat.

Muutama kymmenen variaatiota toimii hyvin. Satojen kohdalla tuotesivu ja tuotteen muokkaus hallintapaneelissa hidastuvat selvästi. Olen törmännyt kauppoihin, joissa yhdellä päätuotteella oli noin tuhat variaatiota. Silloin palvelin on kovilla jokaisella tuotesivun latauksella ja yksikin tuotteen tallennus voi kestää pitkään.

Ratkaisuja on useita:

• Variaatio vain, kun se on tarpeen. Variaatio kannattaa tehdä vain silloin, kun yhdistelmällä on oma hinta, varasto tai tuotekoodi. Valinnat, jotka eivät vaikuta näihin, kuten kaiverrusteksti tai lahjapaketointi, kannattaa toteuttaa tuotteen lisäkenttinä.
• Jaa tuote useaksi tuotteeksi. Esimerkiksi jokainen malli tai materiaali voi olla oma tuotteensa, jonka sisällä valitaan koko ja väri. Tuotteet linkitetään toisiinsa, jotta asiakas löytää vaihtoehdot.
• Laske hinta säännöllä. Mittatilaustuotteissa ja konfiguraattoreissa jokaista yhdistelmää ei kannata luoda valmiiksi. Hinta lasketaan asiakkaan valintojen perusteella vasta, kun valinnat on tehty. Tähän sopivat esimerkiksi WooCommercen oma maksullinen Product Add-Ons tai ilmainen PPOM, joiden avulla tuotteeseen lisätään valintoja, joilla on oma hintansa, ilman että jokaisesta yhdistelmästä tulee variaatio.
• Älä nosta rajaa sokeasti. Jos 30 variaation raja tulee vastaan, se on merkki tuoterakenteen tarkistamisesta, ei pelkästä asetuksen muuttamisesta.

Välimuisti: sivu, objektit ja selain

Välimuisteja on kolmea tasoa ja kauppa tarvitsee yleensä niitä kaikkia:

1. Sivuvälimuisti tallentaa valmiit sivut. Tuote- ja kategoriasivuille se sopii hyvin, mutta ostoskori, kassa ja oma tili pitää jättää sen ulkopuolelle.
2. Objektivälimuisti (esimerkiksi Redis) tallentaa tietokantakyselyjen tulokset muistiin. Siitä on eniten hyötyä juuri niillä sivuilla, joita ei voi tallentaa kokonaisina.
3. Selainvälimuisti ja kuvien optimointi huolehtivat siitä, ettei kävijän selain lataa samoja tiedostoja uudelleen.

Pelkkä välimuistilisäosa ei korjaa hidasta palvelinta. Se piilottaa ongelman etusivulta, mutta kassa on edelleen hidas ja juuri siellä kauppa tehdään.

Hosting ratkaisee enemmän kuin moni luulee

Halvassa webhotellissa kauppa jakaa palvelimen kymmenien muiden sivustojen kanssa. Kun naapurilla on ruuhkaa, sinunkin kassasi hidastuu. WordPressiin erikoistunut hallinnoitu hosting, kuten Seravo, hoitaa valmiiksi palvelimen välimuistin, PHP-version ja päivitykset. Ennen kuin kauppaa optimoidaan viikkoja, kannattaa tarkistaa, onko palvelin edes riittävä.

WPML: monikielisyyden superhidastaja

Monikielinen kauppa on oma lukunsa. Omassa työssäni WPML on toistuvasti ollut yksi suurimmista yksittäisistä hidastajista. Se on monipuolinen ja kattaa lähes kaiken, mutta se tuo mukanaan omat tietokantataulunsa, merkkijonojen käännökset ja lisää kyselyjä jokaiselle sivulle. WooCommercen kanssa tarvitaan vielä erillinen WooCommerce Multilingual -lisäosa, joka lisää kuormaa entisestään.

Mittaukset vaihtelevat sivustoittain, eikä riippumatonta vertailua ole. WPML:n oma tuki on myös kiistänyt joissakin tapauksissa merkittävän hidastuksen. Siksi mittaan aina kyseisen kaupan omilla tuotesivuilla, enkä luota yleistyksiin.

Miksi suosittelen Polylangia?

Uusiin monikielisiin kauppoihin suosittelen Polylangia. Se käyttää WordPressin omia rakenteita kielten ja käännösten tallentamiseen, joten se on kevyempi ja ennustettavampi. WooCommerce-kauppaan tarvitaan maksullinen Polylang for WooCommerce -lisäosa, joka kääntää kaupan sivut, sähköpostit ja tuoteominaisuudet sekä synkronoi muun muassa varastosaldot kieliversioiden välillä.

Polylangilla on omat rajoituksensa: siinä ei ole valmista valuutanvaihtoa ja hyvin monimutkaisissa tuotevalikoimissa WPML:n laajemmat työkalut voivat olla tarpeen. Vaihto WPML:stä Polylangiin on lisäksi aina oma projektinsa, koska käännökset pitää siirtää. Siksi teen vaihdon vain, kun mittaus osoittaa, että hyöty on todellinen.

Mistä aloittaa?

1. Mittaa nykytila: sivun latausaika, palvelimen vasteaika ja kassan nopeus.
2. Katso Sivuston terveys -työkalusta, onko varoituksia. Tarkista myös, onko HPOS käytössä.
3. Etsi Query Monitorilla raskaimmat lisäosat ja hitaimmat kyselyt testiympäristössä.
4. Tarkista, onko kaupassa tuotteita, joilla on satoja variaatioita.
5. Varmista, että palvelin ja objektivälimuisti ovat kunnossa.
6. Vasta sitten optimoi kuvat, skriptit ja muut yksityiskohdat.

Jos kauppasi kaipaa tällaista läpikäyntiä, se kuuluu WordPress- ja WooCommerce-työhöni. Nopeus ja tekninen rakenne käydään läpi myös SEO- ja GEO-auditissa, jos haluat arvion koko sivustosta.

Usein kysyttyä

Nopeuttaako välimuistilisäosa WooCommerce-kauppaa?

Osittain. Se nopeuttaa tuote- ja kategoriasivuja, mutta ostoskoria, kassaa ja omaa tiliä ei voi tallentaa välimuistiin. Niiden nopeus riippuu palvelimesta, tietokannasta ja lisäosista.

Pitäisikö HPOS ottaa käyttöön vanhassa kaupassa?

Yleensä kyllä, kunhan kaikki käytössä olevat lisäosat tukevat sitä. WooCommerce näyttää yhteensopimattomat lisäosat asetuksissa. Siirto tehdään ensin testiympäristössä ja tilaukset synkronoidaan vanhan ja uuden tallennuksen välillä, kunnes kaikki toimii.

Montako variaatiota yhdellä tuotteella voi olla?

Teknistä ylärajaa ei ole, mutta WooCommerce käsittelee tuotesivulla oletuksena dynaamisesti vain 30 variaatiota. Muutama kymmenen toimii hyvin. Jos variaatioita on satoja, tuoterakenne kannattaa miettiä uudelleen.

Kannattaako WPML vaihtaa Polylangiin?

Ei automaattisesti. Jos kauppa on hidas ja mittaus osoittaa WPML:n olevan suuri osa ongelmaa, vaihto voi kannattaa. Uudessa monikielisessä kaupassa valitsen yleensä Polylangin alusta asti.

Mitä tarvittiin?

PriceShape on tanskalainen hinnoittelupalvelu, joka seuraa kilpailijoiden hintoja. Sitä varten se tarvitsee kaupan tuotteet ja tässä kaupassa tuotteiden ja hintojen päälähde on Winpos-kassa. Kun kilpailijoiden hinnat tiedetään, hinta pitää päivittää kahteen paikkaan: WooCommerce-verkkokauppaan ja Winposiin, jotta myymälässä ja verkossa on sama hinta.

Seurantaan otettiin tuoteryhmät, joissa hintakilpailu on kovinta: puhelimet, tabletit ja älykellot.

Osa 1: tuotteet Winposista PriceShapeen

1. Haku Winposista sivu kerrallaan. Tuotteet haetaan Winposin REST-rajapinnasta sata kerrallaan, kunnes kaikki on käyty läpi.
2. Suodatus tuoteryhmän mukaan. Mukaan otetaan vain Winposin osastot, joihin puhelimet, tabletit ja älykellot kuuluvat.
3. Tarvittavat tiedot. Jokaisesta tuotteesta poimitaan EAN-koodi, tuotekoodi, nimi, osasto ja alaosasto, hinta, tuotetyyppi ja verokanta.
4. Syöte tiedostoon. Tuotteet kirjoitetaan JSON-tiedostoksi, josta PriceShape lukee ne.

Winposissa on tuhansia tuotteita. Jotta PHP:n muisti ei lopu, jokaisen sivun tuotteet kirjoitetaan tiedostoon heti ja muisti vapautuu ennen seuraavaa sivua. Jos Winpos palauttaa jollekin sivulle virheen, siitä lähtee minulle sähköposti ja muut sivut käsitellään normaalisti.

Osa 2: hinnat PriceShapesta takaisin kauppaan

Toinen osa on WordPress-lisäosa, joka lisää palvelimelle WP-CLI-komennon. Komento hakee PriceShapen hintaviennin ja päivittää hinnat.

Hinnoittelusääntö

Jokaiselle tuotteelle etsitään halvin hinta PriceShapen seuraamista kaupoista ja se pyöristetään ylöspäin täysiin euroihin. Hinta päivitetään vain, jos se päättyy yhdeksään, eli esimerkiksi 349 €. Muihin tuotteisiin ei kosketa. Sääntö pitää automaattisesti päivittyvät hinnat kaupan tutussa ...9 euron muodossa.

Tällaisia sääntöjä kannattaa miettiä tarkkaan yhdessä kauppiaan kanssa, koska ne muuttavat hintoja ilman, että kukaan katsoo niitä etukäteen.

Päivitys WooCommerceen ja Winposiin

foreach ( $targets as $sku => $new_price ) {
	// WooCommerce: vain jos hinta oikeasti muuttuu
	if ( isset( $woo_map[ $sku ] ) && (string) $woo_map[ $sku ]['price'] !== (string) $new_price ) {
		$this->update_woo_price( $woo_map[ $sku ]['id'], $new_price );
	}
	// Winpos: haetaan nykyinen hinta ja päivitetään, jos se poikkeaa
	$this->update_winpos_price( $sku, $new_price );
}

• WooCommerce. Hinta tallennetaan WooCommercen omien toimintojen kautta, jotta välimuistit tyhjenevät ja muut lisäosat, kuten hakukonelisäosa, saavat tiedon muutoksesta.
• Winpos. Integraatio hakee tuotteen nykyiset tiedot kassasta ja lähettää uuden hinnan vain, jos se poikkeaa nykyisestä.
• Loki. Jokainen muutos kirjataan lokiin vanhan ja uuden hinnan kanssa ja ajon lopuksi tulostetaan yhteenveto päivitetyistä tuotteista.

Muisti ja nopeus

WordPress ja WooCommerce on tehty ennen kaikkea sivulatauksia varten ja tuhansien tuotteiden käsittely yhdellä ajolla kuluttaa helposti kaiken muistin. Siksi komento:

• etsii tuotteet tuotekoodin (SKU) perusteella yhdellä tietokantakyselyllä 500 tuotetta kerrallaan sen sijaan, että jokainen tuote haettaisiin erikseen
• lataa WooCommercen tuoteolion vain niille tuotteille, joiden hinta oikeasti muuttuu
• tyhjentää WordPressin välimuistin ajon aikana ja raportoi lopuksi muistin enimmäiskäytön.

Miksi WooCommerce-palvelimelle?

• Tehtävät ovat selkeitä. Syötteen kirjoitus ja hintojen päivitys ajastetusti. Jonoja tai erillistä tietokantaa ei tarvita.
• Palvelin on jo olemassa. Erillistä pilvipalvelua ei tarvitse perustaa, maksaa eikä ylläpitää.
• Suora pääsy kauppaan. Hinnat päivittyvät WooCommercen omien toimintojen kautta samalla tavalla kuin hallintapaneelista.
• Ajo ei hidasta kauppaa. Ajot käynnistää palvelimen cron eikä WordPressin sivulatauksiin sidottu WP-Cron, joten ne eivät vaikuta kävijöiden sivulatauksiin.

Vertailin integraatioiden ajoympäristöjä tarkemmin integraatiopalvelun sivulla.

Usein kysyttyä

Muuttaako integraatio hintoja ilman ihmistä?

Muuttaa, mutta vain sovitun säännön mukaan ja vain seurattavissa tuoteryhmissä. Jokainen muutos kirjataan lokiin, joten muutokset voi tarkistaa jälkikäteen.

Miksi hinnat päivitetään sekä verkkokauppaan että kassaan?

Jotta asiakas saa saman hinnan myymälässä ja verkossa. Jos hinta päivittyisi vain verkkokauppaan, myymälän hinta jäisi jälkeen.

Miksi seurantaan otettiin vain osa tuotteista?

Hintavertailu on hyödyllisintä tuotteissa, joita myydään monessa kaupassa samalla EAN-koodilla ja joiden hintoja asiakkaat vertailevat. Puhelimet, tabletit ja älykellot ovat juuri sellaisia.

Mistä GEO-termi tulee?

Termi tulee vuonna 2023 julkaistusta tutkimusartikkelista, jossa tutkittiin, miten sisällön muokkaaminen vaikuttaa siihen, kuinka usein tekoälyhakukone viittaa siihen. Sittemmin termiä on käytetty laajemmin kaikesta työstä, jolla sivustoa parannetaan tekoälyhakuja varten. Uutta tieteenalaa se ei ole: suurin osa toimenpiteistä on tuttuja hakukoneoptimoinnista.

Mitä GEO on käytännössä?

Kun auditoin sivustoa tekoälyhakujen näkökulmasta, käyn läpi neljä asiaa:

1. Pääsevätkö tekoälyhakujen botit sivustolle? Tekoälypalveluilla on omat botit ja ne voi estää robots.txt-tiedostossa. Tärkeää on erottaa, mikä botti tekee mitä. Esimerkiksi OpenAI:n ohjeiden mukaan OAI-SearchBot ratkaisee, näkyykö sivusto ChatGPT:n hakutuloksissa, kun taas GPTBot kerää aineistoa mallien koulutukseen. Googlen Google-Extended puolestaan koskee Gemini-mallien koulutusta, eikä sen estäminen Googlen mukaan vaikuta Google-hakuun. Näkyvyyttä voi siis menettää vahingossa, jos estää väärän botin.
2. Vastaako sisältö kysymyksiin suoraan? Tekoäly poimii sivulta kohtia, jotka vastaavat kysymykseen. Jos vastaus on piilotettu kolmannen kappaleen loppuun markkinointitekstin sekaan, sitä ei löydetä. Hyvä rakenne on yksinkertainen: kysymys väliotsikkona, suora vastaus heti sen alla.
3. Ovatko yrityksen tiedot johdonmukaisia? Nimen, osoitteen, palvelujen ja yhteystietojen pitää olla samat sivustolla, Googlen yritysprofiilissa ja muissa palveluissa.
4. Onko väitteille lähteet? Tekoäly luottaa sisältöön, jossa on tarkkoja tietoja ja viittauksia, enemmän kuin yleiseen ylistykseen.

Mitä JSON-LD tekee?

JSON-LD on tapa kertoa koneelle sivun sisällöstä rakenteisesti. Ihmiselle sivu näyttää samalta, mutta sivun koodissa on lisäksi esimerkiksi tieto siitä, että kyse on yrityksestä, jolla on tietty nimi, osoite ja palvelut, tai artikkelista, jolla on kirjoittaja ja julkaisupäivä.

Tältä se näyttää pelkistettynä:

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Esimerkki Oy",
  "address": { "@type": "PostalAddress", "addressLocality": "Kurikka" },
  "telephone": "+358 40 123 4567"
}

Sanasto tulee Schema.orgista, jota Google, Microsoft ja muut hakukoneet käyttävät yhteisesti.

Auttaako rakenteinen data näkymään tekoälyhauissa?

Rehellinen vastaus: se auttaa koneita ymmärtämään sivua, mutta mikään tietty rakenne ei takaa näkyvyyttä. Googlen ohjeissa tekoälyominaisuuksista ei vaadita mitään erityistä tekoälyä varten tehtyä rakennetta. Ohjeet korostavat, että rakenteisen datan pitää vastata sivulla näkyvää tekstiä.

On myös hyvä tietää, että rakenteisen datan hyödyt muuttuvat. Google rajasi FAQ-rikastetut tulokset vuonna 2023 vain viranomais- ja terveyssivustoille ja Search Engine Journalin mukaan ne poistuivat hausta kokonaan kesällä 2026. FAQ-rakenteesta ei siis enää saa näyttävää hakutulosta. Rakenteena se kertoo edelleen selvästi, mitkä kysymykset ja vastaukset sivulla on.

Tarvitseeko pieni yritys rakenteista dataa?

Kyllä, mutta vähän. Pienelle yritykselle riittää yleensä:

• Yrityksen perustiedot (Organization tai LocalBusiness): nimi, osoite, yhteystiedot ja aukioloajat.
• Palvelut (Service) palvelusivuille.
• Artikkelit (BlogPosting), jos sivustolla on blogi.
• Murupolku (BreadcrumbList), jos sivustolla on useampi taso.

WordPressissä nämä saa usein hakukonelisäosalla. Tärkeintä on tarkistaa, että tiedot ovat oikein ja samat kuin sivulla, koska lisäosan oletusasetukset tuottavat helposti puutteellista tai ristiriitaista dataa. Tarkistukseen sopii Googlen Rich Results Test tai Schema.orgin validaattori.

Mistä aloittaa?

1. Tarkista robots.txt: estätkö vahingossa jonkin hakubotin?
2. Kirjoita palvelusivujen ensimmäinen kappale niin, että se vastaa suoraan kysymykseen "mitä te teette ja kenelle".
3. Lisää yrityksen perustiedot rakenteisena datana ja tarkista ne validaattorilla.
4. Varmista, että yrityksen tiedot ovat samat kaikkialla verkossa.

Jos haluat, että joku käy tämän läpi puolestasi, se kuuluu SEO-, GEO- ja saavutettavuusauditteihin.

Usein kysyttyä

Korvaako GEO hakukoneoptimoinnin?

Ei. GEO rakentuu hakukoneoptimoinnin päälle. Jos sivusto ei näy tavallisessa haussa, se tuskin näkyy tekoälyhauissakaan, koska moni tekoälyhaku hakee tietonsa juuri hakukoneiden kautta.

Pitäisikö tekoälybotit estää?

Se riippuu siitä, mitä haluat. Jos haluat näkyä tekoälyhakujen vastauksissa, älä estä hakuun käytettäviä botteja. Mallien koulutukseen käytettävät botit voi halutessaan estää erikseen, eikä se vaikuta hakunäkyvyyteen.

Voiko rakenteisen datan lisätä itse?

Perustiedot onnistuvat yleensä hakukonelisäosan asetuksista. Kun dataa tarvitaan palveluille, tuotteille tai omille sisältötyypeille, se kannattaa rakentaa teemaan tai lisäosaan, jotta se päivittyy automaattisesti sisällön mukana.

Kaksi eri lajia: sivustotyökalut ja sovelluskoneet

Kannattaa erottaa kaksi ryhmää:

• Sivustotyökalut, kuten Framer. Lopputulos on julkaistu sivusto palvelun omalla alustalla. Sisällönhallinta, hosting ja ulkoasun muokkaus ovat samassa paikassa, mutta koodia ei saa ulos.
• Sovelluskoneet, kuten Lovable, v0, Bolt ja Base44. Ne kirjoittavat oikeaa koodia (yleensä Reactia) ja tarjoavat tietokannan, kirjautumisen ja julkaisun. Niillä voi tehdä myös sivuston, mutta vahvuus on toiminnallisuudessa.

Lovable: koko sovellus kuvailemalla

Lovable tuottaa React-sovelluksen, jonka taustapalveluna on Supabaseen perustuva Lovable Cloud tai oma Supabase-projekti. Projektin voi synkronoida GitHubiin, joten koodi on käyttäjän omaa ja kehittäjä voi jatkaa sitä tavallisilla työkaluilla. Kahdesta Lovablella tehdystä verkkokaupasta kerron tarkemmin artikkelissa Sivuston tai sovelluksen rakentaminen Lovablella.

Sopii, kun omistaja haluaa kehittää palveluaan itse ja palvelussa on kirjautumista tai omaa logiikkaa.

Framer: näyttävä sivusto suunnittelijan työkalulla

Framer on alun perin suunnittelutyökalu, josta on tullut sivustoalusta. Sen tekoälyominaisuuksiin kuuluu agentti, joka luo sivuja ja osioita kehotteesta, sekä agentit sisällönhallintaan, omiin koodikomponentteihin ja julkaisua edeltävään tarkistukseen. Tarkistusagentti etsii esimerkiksi kontrastiongelmia, puuttuvia kuvien vaihtoehtoisia tekstejä ja SEO-puutteita.

Framerin oman ohjeen mukaan sivustoa ei voi viedä HTML-tiedostoina omalle palvelimelle, koska julkaisu nojaa Framerin omiin taustapalveluihin. Sivusto pysyy siis Framerissa.

Sopii markkinointisivustoon, jonka ulkoasu on tärkein ja jota suunnittelija päivittää itse.

v0: Vercelin työkalu React- ja Next.js-koodiin

v0 on Vercelin tekoälyagentti, joka rakentaa käyttöliittymiä ja kokonaisia sovelluksia. Dokumentaation mukaan se käyttää muun muassa Next.js:ää, Tailwindia ja shadcn/ui-komponentteja ja julkaisu tapahtuu yhdellä klikkauksella Verceliin. GitHub-yhteydessä v0 tekee muutokset omaan haaraansa eikä koskaan suoraan päähaaraan, joten muutokset tulevat tarkistettaviksi pull requestina.

Sopii, kun projektissa on jo kehittäjä tai Next.js-sovellus ja tekoälyä halutaan käyttää osana tavallista kehitystyötä.

Bolt: nopea alku selaimessa

Bolt rakentaa sivustoja, sovelluksia ja prototyyppejä keskustelemalla. Bolt Cloud tarjoaa hostingin, omat verkkotunnukset, tietokannat ja käyttäjien kirjautumisen. Projektin voi aloittaa myös Figma-suunnitelmasta tai GitHub-projektista.

Sopii prototyyppeihin ja demoihin, joissa tärkeintä on päästä nopeasti näyttämään jotain toimivaa.

Base44: Wixin sovelluskone

Base44 on israelilainen palvelu, jolla rakennetaan sovelluksia tavallisella kielellä. Wix osti sen kesäkuussa 2025 ja se jatkaa omana tuotteenaan. Base44 sisältää taustapalvelut valmiina, joten se sopii esimerkiksi sisäisiin työkaluihin ja pieniin liiketoimintasovelluksiin.

Sopii, kun tarvitset toimivan sovelluksen nopeasti etkä halua miettiä taustapalveluita lainkaan.

Figma Make: suunnitelmasta toimivaksi prototyypiksi

Figma Make tekee kehotteista, Figma-kehyksistä ja suunnittelujärjestelmistä toimivia prototyyppejä ja sovelluksia. Siinä on myös sisällönhallinta, joka perustuu Payload CMS:ään. Figman sivun mukaan suoraan tuotantoon julkaiseminen on vasta tulossa, joten tällä hetkellä se on ennen kaikkea suunnittelijan työkalu.

Sopii tiimille, jonka suunnittelu on jo Figmassa ja joka haluaa testata ideoita toimivina ennen toteutusta.

Mitä kaikissa kannattaa tarkistaa?

Kuka omistaa koodin? Lovablessa ja v0:ssa koodin saa omaan GitHub-varastoon. Framerissa sivusto pysyy alustalla. Muissa työkaluissa vientimahdollisuudet kannattaa tarkistaa ennen aloittamista. Jos palvelun hinta tai ehdot muuttuvat, tämä ratkaisee, kuinka helposti pääset pois.

Tietoturva. Sovelluskoneet luovat tietokannan ja kirjautumisen, mutta käyttöoikeussäännöt ovat edelleen tekijän vastuulla. Lovablella tehdyistä sovelluksista löytyi vuonna 2025 yli sata, joiden tietokantaan pääsi ilman kirjautumista. Sama riski koskee kaikkia näitä työkaluja.

Hinta käytännössä. Hinnoittelu perustuu yleensä krediitteihin tai viestien määrään. Kuukausihinta on helppo vertailla, mutta todellinen kulu riippuu siitä, kuinka paljon korjauskierroksia tarvitaan. Tarkista ajantasaiset hinnat palveluiden omilta sivuilta.

Hakunäkyvyys ja saavutettavuus. Otsikot, kuvaukset, rakenteinen data, otsikkorakenne ja kontrastit pitää tarkistaa kuten millä tahansa alustalla. Tekoäly tekee hyvän näköisen pohjan, mutta ei automaattisesti hyvää rakennetta.

Mikä työkalu kannattaa valita?

• Framer, kun tarvitset näyttävän markkinointisivuston ja suunnittelija päivittää sitä itse.
• Lovable, kun omistaja haluaa rakentaa ja kehittää sovellusta itse.
• v0, kun mukana on kehittäjä ja koodi elää GitHubissa ja Vercelissä.
• Bolt nopeisiin prototyyppeihin ja demoihin.
• Base44, kun tarvitset sisäisen työkalun nopeasti.
• Figma Make, kun suunnitelma pitää saada testattavaksi ennen toteutusta.

Sisältöpainotteiseen yrityssivustoon tai verkkokauppaan, jota päivittää moni ihminen ja jossa tarvitaan monikielisyyttä ja valmiita integraatioita, valitsen edelleen useimmiten WordPressin ja WooCommercen. Markkinointisivustojen vertailun löydät myös artikkelista Webflow vai WordPress.

Tämä sivusto on rakennettu tekoälyn avustuksella ja kokemuksista kerron artikkelissa Rakensin sivustoni testiksi tekoälyn avustuksella. Jos rakennat palvelua jollain näistä työkaluista ja haluat käydä läpi tietoturvan, hakunäkyvyyden tai integraatiot, autan mielelläni. Lue lisää tekoälyratkaisuista.

Usein kysyttyä

Mikä on paras tekoälytyökalu oman sivuston tekemiseen?

Riippuu siitä, mitä teet. Pelkkään markkinointisivustoon Framer on helpoin. Jos sivustossa on kirjautumista, tietokanta tai omaa logiikkaa, Lovable, v0, Bolt tai Base44 ovat parempia.

Voiko tekoälyllä tehdyn sivuston siirtää myöhemmin muualle?

Riippuu työkalusta. Lovablesta ja v0:sta koodin saa GitHubiin ja voi julkaista muualla. Framerista sivustoa ei voi viedä ulos, vaan se pitää rakentaa uudelleen.

Tarvitaanko kehittäjää enää ollenkaan?

Yksinkertaiseen sivustoon ei välttämättä. Kun mukana on asiakastietoja, maksuja, integraatioita tai saavutettavuusvaatimuksia, joku pitää tarkistaa, että lopputulos on turvallinen ja toimii.

Mikä ero Laravel Cloudilla ja Forgella on?

Ero on siinä, kuka omistaa palvelimen ja vastaa siitä.

• Laravel Cloud on alusta, jossa et näe palvelinta lainkaan. Yhdistät koodivaraston, valitset alueen ja resurssit ja Cloud hoitaa ajoympäristön, skaalauksen, tietokannat, jonot ja SSL-varmenteet. Taustalla on Amazonin AWS.
• Forge on hallintatyökalu omalle palvelimelle. Palvelin vuokrataan esimerkiksi DigitalOceanilta, Hetzneriltä tai AWS:ltä ja Forge asentaa ja konfiguroi sen, hoitaa julkaisut ja SSL-varmenteet. Palvelin on silti sinun ja käyttöjärjestelmän päivitykset, levytila ja valvonta ovat sinun vastuullasi.

Milloin Laravel Cloud kannattaa?

Kun et halua ylläpitää palvelinta. Tämä on Cloudin suurin etu. Käyttöjärjestelmän päivityksiä, PHP-version vaihtoa tai levyn täyttymistä ei tarvitse seurata.

Kun kuorma vaihtelee. Cloud skaalautuu kuorman mukaan ja pienet sovellukset voivat mennä lepotilaan, kun käyttäjiä ei ole. Silloin laskutetaan vain siitä ajasta, kun sovellus on käytössä. Tämä sopii hyvin esimerkiksi sisäisiin työkaluihin, joita käytetään vain virka-aikaan.

Kun tarvitaan esikatseluympäristöjä. Cloud voi luoda jokaiselle kehityshaaralle oman ympäristön, jossa muutoksen voi testata ennen julkaisua.

Kun tietokanta saa olla hallinnoitu. Cloudissa on valmiina MySQL ja serverless-PostgreSQL, välimuisti ja jonot. Niitä ei tarvitse asentaa tai varmuuskopioida itse.

Milloin oma palvelin Forgella on parempi?

Kun tarvitaan täyttä hallintaa. Omalle palvelimelle voi asentaa mitä tahansa: erikoisia PHP-laajennuksia, omia taustapalveluita tai muita kuin Laravel-sovelluksia samalle koneelle.

Kun data pitää sijaita tietyssä maassa. Laravel Cloudin lähimmät alueet ovat Frankfurtissa, Irlannissa ja Lontoossa. Jos asiakkaan vaatimus on, että data pysyy Suomessa, palvelin voidaan vuokrata esimerkiksi Hetznerin Helsingin konesalista ja hallita sitä Forgella.

Kun kuorma on tasainen ja suuri. Jos sovellus on jatkuvasti täydessä käytössä, kiinteähintainen oma palvelin voi tulla edullisemmaksi kuin käyttöön perustuva laskutus. Tämä kannattaa laskea tapauskohtaisesti.

Kun samalla palvelimella on monta pientä sivustoa. Forgella yhdelle palvelimelle voi sijoittaa useita sovelluksia ja kustannus jakautuu niiden kesken.

Miten hinnoittelu eroaa?

Laravel Cloudissa maksetaan kuukausimaksu ja sen päälle käytöstä: laskentatehosta, tietokannasta, tallennustilasta ja tiedonsiirrosta. Kuukausikulutukselle voi asettaa ylärajan, jolloin lasku ei voi yllättää. Forgessa maksetaan kiinteä kuukausimaksu Forgelle ja erikseen palvelimen vuokra palveluntarjoajalle.

Hinnat muuttuvat, joten tarkista ajantasaiset hinnat Laravel Cloudin ja Forgen sivuilta. Pienelle sovellukselle, joka on suurimman osan ajasta lepotilassa, Cloud on yleensä halvempi. Jatkuvasti kuormitetulle sovellukselle oma palvelin voi olla edullisempi, mutta siihen pitää lisätä oma ylläpitotyö.

Mitä siirto Cloudiin vaatii käytännössä?

Jos sovellus siirretään omalta palvelimelta Laravel Cloudiin, käyn läpi ainakin nämä:

• Tiedostot. Käyttäjien lataamat tiedostot eivät voi olla palvelimen levyllä, koska Cloudin palvelimet vaihtuvat. Ne siirretään objektitallennukseen.
• Ajastetut tehtävät ja jonot. Ne määritellään Cloudin asetuksissa palvelimen cron-ajojen sijaan.
• Tietokanta. Tietokanta siirretään hallinnoituun tietokantaan ja samalla tarkistetaan, toimiiko sovellus myös PostgreSQL:llä, jos vaihdetaan MySQL:stä.
• Palvelimelle asennetut lisät. Jos sovellus käyttää jotain palvelimelle erikseen asennettua ohjelmaa, sille pitää löytää korvaaja.

Mitä minä valitsen?

Uudessa projektissa lähtöoletukseni on Laravel Cloud. Säästetty ylläpitotyö on yleensä arvokkaampaa kuin mahdollinen ero kuukausilaskussa. Valitsen Forgen, kun jokin yllä mainituista syistä painaa: datan sijainti, erikoisvaatimukset tai tasainen suuri kuorma.

Vanhaa sovellusta ei kannata siirtää vain siirtämisen vuoksi. Jos oma palvelin toimii ja sitä ylläpidetään, siirto Cloudiin kannattaa yleensä vasta, kun palvelin pitäisi muutenkin uusia.

Molemmissa vaihtoehdoissa autan valinnassa, käyttöönotossa ja ylläpidossa. Lisää Laravel- ja palvelinpalveluista.

Usein kysyttyä

Voiko sovelluksen siirtää Forgesta Laravel Cloudiin myöhemmin?

Voi. Laravel-sovellus toimii molemmissa samalla koodilla. Siirrossa pitää huomioida tietokannan, tiedostojen ja ympäristömuuttujien siirto sekä se, käyttääkö sovellus jotain palvelimelle erikseen asennettua, jota Cloudissa ei ole.

Onko Laravel Cloud serverless-palvelu?

Ei samalla tavalla kuin esimerkiksi Laravel Vapor. Cloud ajaa sovellusta tavallisilla palvelimilla, jotka se hallitsee puolestasi ja skaalaa kuorman mukaan. Pienet sovellukset voivat kuitenkin mennä lepotilaan ja herätä seuraavasta pyynnöstä.

Toimiiko WordPress Laravel Cloudissa?

Laravel Cloud on tehty Laravel- ja Symfony-sovelluksille, ei WordPressille. WordPress-sivustoille suosittelen WordPressiin erikoistunutta hallinnoitua hostingia, kuten Seravoa.

Mikä ero on chatbotilla ja tekoälyagentilla?

Chatbot keskustelee. Hyvä chatbot hakee vastauksen yrityksen omasta aineistosta, kuten sivustolta, ohjeista ja tuotetiedoista. Se myös kertoo, mistä tieto on peräisin.

Tekoälyagentti käyttää lisäksi työkaluja. Se voi hakea tietoa järjestelmistä, esimerkiksi tilauksen tilan WooCommercesta. Se voi myös tehdä toimenpiteitä, kuten luoda tukipyynnön. Siksi agentin oikeudet pitää rajata tarkasti ja tärkeät toimenpiteet jätetään ihmisen hyväksyttäviksi.

Riittääkö valmis palvelu?

Valmiissa chatbot-palveluissa annetaan sivuston osoite tai ladataan dokumentteja ja botti on käytössä samana päivänä. Ne sopivat, kun:

• sisältö muuttuu harvoin, esimerkiksi ohjeet ja usein kysytyt kysymykset
• botin ei tarvitse tietää mitään asiakaskohtaista
• riittää, että vastaukset ovat suurin piirtein oikein.

Ongelmat alkavat verkkokaupassa. Hinta, varastosaldo ja tuotevalikoima muuttuvat päivittäin ja valmis palvelu lukee sivuston uudelleen omassa tahdissaan. Silloin botti voi kertoa, että tuotetta on varastossa, vaikka se loppui eilen.

Miksi "rakenna mulle chatbot" ei riitä?

Tekoälyltä voi pyytää chatbotin ja se tekee toimivan näköisen version nopeasti. Pyynnöstä jää kuitenkin puuttumaan kaikki se, mikä tekee botista luotettavan: mistä tieto tulee, miten se pysyy ajan tasalla, mitä botti saa tehdä ja miten virheet huomataan. Tuotantokelpoinen botti on enemmän tiedonhallintaa kuin keskustelua.

Mitä itse rakennettu chatbot vaatii?

RAG eli haku ennen vastausta

Kielimalli ei tunne yrityksesi tuotteita. RAG-mallissa (retrieval-augmented generation) jokaisen kysymyksen kohdalla haetaan ensin sopivat tekstinpätkät omasta aineistosta ja annetaan ne mallille vastauksen pohjaksi. Ratkaisun laatu riippuu lähes kokonaan tästä hausta.

Aineiston pilkkominen ja vektorit

Sisältö pilkotaan sopivan kokoisiksi paloiksi ja jokaisesta lasketaan vektori eli numeerinen esitys sen merkityksestä. Kysymykselle lasketaan samanlainen vektori ja haku etsii merkitykseltään lähimmät palat. Palojen rajat vaikuttavat vastausten laatuun: jos tuotteen nimi ja hinta päätyvät eri paloihin, botti voi yhdistää väärät tiedot.

PostgreSQL ja pgvector

Vektorit tallennetaan tietokantaan. Erillistä vektoritietokantaa ei yleensä tarvita: pgvector on PostgreSQL-laajennus, joka tallentaa vektorit tavallisen tiedon rinnalle ja tukee nopeita hakuindeksejä. Siitä on kaksi isoa etua:

• Vektorihaun voi yhdistää tavalliseen suodatukseen samassa kyselyssä, esimerkiksi "vain varastossa olevat tuotteet, suomenkieliset tekstit, hinta alle 100 euroa".
• Vektorihaun voi yhdistää perinteiseen tekstihakuun. Tuotekoodit ja mallinimet löytyvät tekstihaulla paremmin kuin merkityksen perusteella.

Synkronointi WordPressistä ja WooCommercesta

Tieto pitää saada tietokantaan ja pitää se ajan tasalla. Teen tähän yleensä oman WordPress-lisäosan, joka:

• avaa rajapinnan, joka palauttaa sisällön ja tuotteet botille sopivassa muodossa. Pohjana on WordPressin REST API ja vain tarvittavat kentät palautetaan.
• ilmoittaa muutoksista heti. Kun tuote tai sivu tallennetaan tai poistetaan, lisäosa lähettää tiedon botin taustapalveluun, joka päivittää vektorit. Poistot ovat tärkeitä: poistetusta tuotteesta ei saa enää vastata.
• huomioi monikielisyyden ja näkyvyyden. Luonnoksia, salasanasuojattuja sivuja tai piilotettuja tuotteita ei viedä botille.

Varastosaldot ja hinnat kannattaa usein hakea suoraan WooCommercen rajapinnasta vastaushetkellä eikä tallentaa vektoreihin, koska ne muuttuvat jatkuvasti.

Agentin työkalut ja oikeudet

Kun botti saa työkaluja, jokainen työkalu on oma rajapintansa, jolla on tarkat oikeudet. Tilauksen tilan saa tarkistaa vain tunnistettu käyttäjä ja vain omasta tilauksestaan. Agentti ei saa käyttää ylläpitäjän tunnuksia.

Tietoturva ja kehoteinjektiot

Tekoälysovellusten yleisin uhka on kehoteinjektio, joka on OWASP:n LLM-riskilistan kärjessä. Siinä käyttäjä tai jokin aineistoon päätynyt teksti yrittää saada mallin toimimaan ohjeiden vastaisesti. Siksi agentin oikeudet rajataan niin, ettei se voi tehdä mitään vahingollista, vaikka injektio onnistuisi.

Lokit, arviointi ja kustannukset

Jokainen kysymys, haetut lähteet ja vastaus kirjataan lokiin. Lisäksi tehdään testikysymysten sarja, jolla tarkistetaan, ettei botti huonone, kun aineisto tai malli vaihtuu. Kustannukset muodostuvat kielimallin käytöstä, vektorien laskennasta ja palvelimesta. Ne kannattaa arvioida etukäteen todellisella kysymysmäärällä.

Tietosuoja

Selvitä, mihin maahan ja kenelle data lähtee, onko palveluntarjoajan kanssa tietojenkäsittelysopimus ja käytetäänkö keskusteluja mallien koulutukseen. Asiakastietoja ei viedä vektoreihin ollenkaan, vaan ne haetaan tarvittaessa rajapinnasta käyttäjän luvalla.

Kumpi kannattaa valita?

• Valmis palvelu, jos haluat kokeilla nopeasti, sisältö on pääosin pysyvää eikä botin tarvitse tehdä mitään.
• Itse rakennettu chatbot, jos botin pitää tuntea verkkokaupan ajantasaiset tiedot, toimia usealla kielellä tai yhdistyä muihin järjestelmiin.
• Agentti, kun botin pitää hoitaa tehtäviä. Aloita yhdellä selkeällä tehtävällä ja laajenna vasta, kun se toimii.

Autan valinnassa ja rakennan ratkaisun. Lue lisää tekoälyagenteista ja integraatioista.

Usein kysyttyä

Tarvitaanko erillinen vektoritietokanta?

Yleensä ei. PostgreSQL ja pgvector riittävät useimpiin yritysten tarpeisiin ja tiedot pysyvät samassa tietokannassa muun sovelluksen kanssa. Erillinen vektoritietokanta voi olla perusteltu, kun aineistoa on hyvin paljon.

Voiko botti vastata väärin?

Voi. Siksi botti näyttää lähteet, jolloin käyttäjä voi tarkistaa ne. Lisäksi botti ohjeistetaan kertomaan, kun vastausta ei löydy aineistosta. Testikysymyksillä seurataan, kuinka usein virheitä tulee.

Toimiiko tämä WordPress-sivustolla ilman verkkokauppaa?

Toimii. Synkronointi toimii samalla tavalla sivuille, artikkeleille ja omille sisältötyypeille, esimerkiksi ACF:llä tehdyille kentille.

Mitä GSAP:n maksuttomuus tarkoittaa käytännössä?

Ennen moni hienoimmista ominaisuuksista oli maksullisen Club GSAP -jäsenyyden takana. Nyt kaikki on samassa gsap-paketissa, eikä erillistä lisenssiä tarvita asiakasprojekteihin. Esimerkiksi tekstin pilkkominen sanoiksi tai kirjaimiksi animaatiota varten (SplitText) ja SVG-muotojen muuntaminen toisiksi (MorphSVG) ovat nyt ilmaisia. GSAP:n mukaan SplitText kirjoitettiin samalla uusiksi ja se huomioi nyt myös ruudunlukijat.

Pieni esimerkki: kortit liukuvat esiin vieritettäessä

ScrollTrigger-lisäosalla animaatio käynnistyy, kun elementti tulee näkyviin:

gsap.registerPlugin(ScrollTrigger);

gsap.from(".kortti", {
  y: 40,
  opacity: 0,
  stagger: 0.15, // kortit tulevat yksi kerrallaan
  scrollTrigger: { trigger: ".kortit", start: "top 80%" },
});

Ja otsikko, jonka sanat nousevat paikoilleen:

const split = SplitText.create("h1", { type: "words" });
gsap.from(split.words, { y: 20, opacity: 0, stagger: 0.05 });

Kokeile: teksti, joka animoituu vieritettäessä

Alla oleva teksti on sidottu sivun vieritykseen ScrollTriggerin scrub-asetuksella. Kirjaimet animoituvat esiin sitä mukaa kuin vierität ja punainen alleviivaus ja alareunan palkki seuraavat perässä. Vieritä takaisin ylös, niin animaatio kelautuu taaksepäin.

Koodia tarvitaan vähän. Animaatio ajetaan vain, jos käyttäjä ei ole pyytänyt vähennettyä liikettä:

gsap.matchMedia().add("(prefers-reduced-motion: no-preference)", () => {
  const split = SplitText.create(".teksti", { type: "words, chars" });

  gsap.timeline({
    scrollTrigger: { trigger: ".demo", start: "top 75%", end: "bottom 35%", scrub: 0.6 },
  })
    .from(split.chars, { opacity: 0.15, yPercent: 30, stagger: 0.02 })
    .from(".korostus", { backgroundSize: "0% 0.12em" });

  return () => split.revert(); // palauttaa alkuperäisen tekstin
});

Muut kirjastot ja mihin ne sopivat

Motion on Framer Motionin seuraaja. Se toimii Reactin lisäksi tavallisella JavaScriptillä ja on avointa lähdekoodia (MIT-lisenssi). Se sopii hyvin käyttöliittymän pieniin liikkeisiin, kuten painikkeen palautteeseen:

import { animate } from "motion";
animate(".nappi", { scale: [1, 1.06, 1] }, { duration: 0.4 });

anime.js on kevyt yleiskirjasto, jonka versio 4 toi muun muassa jousifysiikan. Se on hyvä valinta, kun GSAP tuntuu liian raskaalta pieneen tarpeeseen.

three.js on tunnetuin kirjasto 3D-grafiikkaan selaimessa. Pyörivä kuutio vaatii vain muutaman rivin:

import * as THREE from "three";

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(50, innerWidth / innerHeight, 0.1, 100);
camera.position.z = 3;
const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(innerWidth, innerHeight);
document.body.append(renderer.domElement);

const cube = new THREE.Mesh(new THREE.BoxGeometry(), new THREE.MeshNormalMaterial());
scene.add(cube);
renderer.setAnimationLoop(() => {
  cube.rotation.x += 0.01;
  cube.rotation.y += 0.015;
  renderer.render(scene, camera);
});

Oikeassa projektissa kuution tilalla on esimerkiksi tuotteen 3D-malli tai vaikkapa asunnon pohjakuva, jota kävijä voi pyörittää. Alla on sellainen: seinät ja lattiat ovat three.js:n peruslaatikoita, kamera liikkuu OrbitControlsilla ja klikattu huone tunnistetaan Raycasterilla, joka laskee, mihin 3D-objektiin osoitin osuu.

tween.js on pieni kirjasto arvojen pehmeään muuttamiseen. Sitä käytetään usein three.js:n kanssa, esimerkiksi kameran liu'uttamiseen kohteesta toiseen.

Lottie toistaa After Effectsillä tehtyjä animaatioita kevyinä JSON-tiedostoina. Se sopii ikoneihin ja kuvituksiin, jotka suunnittelija tekee valmiiksi.

Rive on Lottien kaltainen, mutta sen animaatiot voivat reagoida käyttäjään tilakoneiden avulla. Se sopii esimerkiksi interaktiivisiin hahmoihin ja painikkeisiin.

Lenis pehmentää sivun vierityksen. Se on suosittu näyttävillä markkinointisivuilla, mutta sitä kannattaa käyttää harkiten, koska se muuttaa selaimen omaa vierityskäytöstä.

Joskus kirjastoa ei tarvita ollenkaan

Selaimet osaavat yhä enemmän itse. CSS:n vieritykseen sidotuilla animaatioilla tehdään esimerkiksi lukemisen edistymispalkki ilman JavaScriptiä:

.lukupalkki {
  position: fixed; top: 0; left: 0; width: 100%; height: 4px;
  background: #d43a2e; transform-origin: 0 50%;
  animation: kasva linear;
  animation-timeline: scroll();
}
@keyframes kasva { from { transform: scaleX(0); } to { transform: scaleX(1); } }

Tuki ei ole vielä kaikissa selaimissa, erityisesti Firefoxissa, joten tarkista tilanne MDN:stä ja tee niin, että sivu toimii ilmankin. Toinen hyödyllinen selaimen oma ominaisuus on View Transitions API, jolla sivujen tai näkymien vaihtumiseen saa pehmeän siirtymän.

Muista saavutettavuus

Liike voi aiheuttaa joillekin pahoinvointia tai vaikeuttaa keskittymistä. Siksi:

• Kunnioita käyttäjän asetusta. Kun käyttöjärjestelmässä on valittu vähennetty liike, animaatiot pitää jättää pois tai tehdä hyvin hillityiksi. GSAP:ssa tähän sopii gsap.matchMedia(), CSS:ssä @media (prefers-reduced-motion: reduce).
• Anna mahdollisuus pysäyttää. Jos liike jatkuu yli viiden sekunnin ajan, sen pitää voida pysäyttää.
• Älä piilota sisältöä animaation taakse. Jos animaatio ei käynnisty, sisällön pitää silti näkyä.

Tarkistan nämä asiat saavutettavuusauditissa yhdessä muiden WCAG-vaatimusten kanssa.

Mikä kirjasto kannattaa valita?

• GSAP, kun animaatioita on paljon, ne on sidottu vieritykseen tai ajoitus on tärkeää.
• Motion tai anime.js käyttöliittymän pieniin liikkeisiin.
• three.js 3D:hen ja WebGL-efekteihin.
• Lottie tai Rive, kun suunnittelija tekee animaation valmiiksi.
• Pelkkä CSS, kun se riittää. Se on aina kevyin vaihtoehto.

Animaatiot kuuluvat räätälöityihin WordPress-toteutuksiini, mutta ne toimivat millä tahansa alustalla, myös Webflow'ssa.

Usein kysyttyä

Onko GSAP ilmainen myös asiakasprojekteissa?

Kyllä. GSAP:n mukaan koko kirjasto lisäosineen on ilmainen, myös kaupallisessa käytössä. Tarkista ajantasaiset lisenssiehdot GSAP:n sivuilta ennen käyttöä.

Hidastavatko animaatiot sivustoa?

Huonosti tehtynä kyllä. Animoi ensisijaisesti ominaisuuksia transform ja opacity, joita selain pystyy käsittelemään kevyesti. Lataa raskaat kirjastot, kuten three.js, vain sivuille, joilla niitä tarvitaan.

Toimiiko GSAP WordPressissä?

Toimii. Sen voi ladata teeman skripteihin tai lisätä animaatiot omiin lohkoihin, jolloin sisällön päivittäjä voi käyttää niitä ilman koodia.

Mikä Webflow on?

Webflow on selaimessa toimiva visuaalinen työkalu, jossa sivusto suunnitellaan ja rakennetaan samassa paikassa. Hosting, varmuuskopiot ja päivitykset sisältyvät palveluun. Webflow tuottaa siistiä HTML- ja CSS-koodia ja sen käyttöliittymä on lähellä CSS:n omaa logiikkaa, joten se sopii suunnittelijalle, joka ymmärtää verkkosivujen rakennetta.

Missä Webflow on vahvempi?

• Visuaalinen suunnittelu. Suunnittelija voi toteuttaa sivun tarkasti ilman kehittäjää. Animaatiot ja vuorovaikutus tehdään samassa työkalussa.
• Ei ylläpitoa. Lisäosia, teemoja tai palvelinta ei tarvitse päivittää. Tietoturvasta huolehtii Webflow.
• Nopea alku. Pieni markkinointisivusto voi olla valmis nopeammin, kun sama ihminen suunnittelee ja toteuttaa.

Missä WordPress on vahvempi?

• Omistajuus ja siirrettävyys. WordPress on avointa lähdekoodia. Sivuston voi siirtää mihin tahansa hostingiin ja kaikki sisältö ja koodi ovat sinun. Webflow'ssa sivusto on Webflow'n palvelussa. Koodin voi viedä ulos, mutta viennistä puuttuvat dynaamiset osat, kuten CMS-sisältö ja lomakkeet.
• Sisällön määrä ja rakenne. Webflow'n CMS:ssä on suunnitelmakohtaiset rajat kokoelmien, kenttien ja sisältöjen määrälle. WordPressissä vastaavia rajoja ei ole ja omat sisältötyypit ja kentät, esimerkiksi ACF:llä, voi rakentaa vapaasti.
• Verkkokauppa. WooCommerce on kattava verkkokauppa, johon saa suomalaiset maksutavat, kuljetusyhtiöt ja yhteydet kirjanpitoon tai toiminnanohjaukseen. Webflow'n verkkokauppa sopii suppeampaan käyttöön.
• Monikielisyys. WordPressissä monikielisyys hoituu esimerkiksi Polylangilla. Webflow'ssa se on lisäpalvelu, jolla on omia rajoituksiaan.
• Integraatiot. WordPressiin voi tehdä oman lisäosan, joka avaa rajapinnan tai yhdistää sivuston muihin järjestelmiin. Webflow'ssa integraatiot tehdään sen rajapinnan kautta, jolla on suunnitelmakohtaiset rajat.
• Kustannukset pitkällä aikavälillä. WordPressin hosting ja ylläpito maksavat, mutta hinnoittelu ei riipu sivujen tai muokkaajien määrästä samalla tavalla kuin Webflow'ssa.

Miten hinnoittelu eroaa?

Webflow'ssa maksetaan kahdesta asiasta: sivustokohtaisesta suunnitelmasta, joka määrää muun muassa CMS:n rajat ja liikennemäärät, sekä työtilan paikoista niille, jotka rakentavat ja muokkaavat sivustoa. Monikielisyys ja verkkokauppa ovat omia lisäpalveluitaan tai suunnitelmiaan. Hinnat muuttuvat, joten tarkista ajantasaiset tiedot Webflow'n sivuilta.

WordPressissä maksetaan hostingista, mahdollisista maksullisista lisäosista ja ylläpidosta. Muokkaajien tai sivujen määrä ei vaikuta hintaan. Kokonaiskustannuksia kannattaa verrata viiden vuoden ajalle, ei ensimmäisen kuukauden laskulle.

Entä tietoturva?

Webflow'n etu on, ettei hyökkäyspintaa ole juuri lainkaan, koska lisäosia ei ole. WordPressin tietoturva riippuu ylläpidosta: päivitetyt lisäosat, hyvä hosting ja varmuuskopiot. Hallinnoitu WordPress-hosting, kuten Seravo, hoitaa ison osan tästä. Huolimattomasti ylläpidetty WordPress on riski, hyvin ylläpidetty ei ole.

Kumpi kannattaa valita?

Valitse Webflow, jos:

• sivusto on pääasiassa markkinointisivusto, jossa on vähän sisältöä
• suunnittelija haluaa toteuttaa ja muokata sitä itse
• et halua huolehtia ylläpidosta.

Valitse WordPress, jos:

• sivustolla on paljon sisältöä tai omia sisältötyyppejä
• tarvitset verkkokaupan, useita kieliä tai integraatioita
• haluat omistaa sivustosi ja pystyä vaihtamaan hostingia tai kehittäjää vapaasti.

Usein valinta ratkeaa sen mukaan, kuka sivustoa päivittää ja mihin se on menossa viiden vuoden päästä. Jos sivuston pitää kasvaa verkkokaupaksi tai yhdistyä muihin järjestelmiin, siirto Webflow'sta WordPressiin myöhemmin on käytännössä uusi projekti.

Jos harkitset headless-ratkaisua, vertailin sitä artikkelissa Storyblok vai WordPress.

Autan valinnassa ja WordPress-puolella myös toteutuksessa. Lisää WordPress- ja WooCommerce-palvelusta.

Usein kysyttyä

Onko Webflow parempi hakukoneoptimoinnissa kuin WordPress?

Ei lähtökohtaisesti. Molemmilla saa tehtyä hakukoneystävällisen sivuston. Ratkaisevaa on sisältö, rakenne ja nopeus, ei alusta. WordPressissä hakukoneoptimointi on helpompi laajentaa esimerkiksi rakenteisella datalla.

Voiko Webflow-sivuston siirtää WordPressiin?

Voi, mutta käytännössä sivusto rakennetaan uudelleen. Sisällön voi viedä CSV-tiedostoina ja tuoda WordPressiin, mutta ulkoasu ja toiminnallisuus toteutetaan alusta.

Pystyykö WordPressiä päivittämään yhtä helposti kuin Webflow'ta?

Kyllä, jos sivusto on rakennettu hyvin. Räätälöidyillä lohkoilla ja kentillä sisältöä päivitetään WordPressin editorissa ilman, että ulkoasu hajoaa.

Mikä on headless-CMS?

Perinteisessä sisällönhallinnassa, kuten WordPressissä, sama järjestelmä tallentaa sisällön ja näyttää sen sivustona. Headless-CMS hoitaa vain sisällön: sisältö haetaan rajapinnan kautta ja sivusto tai sovellus rakennetaan erikseen esimerkiksi Next.js-, Nuxt- tai Astro-kehyksellä. Nimi tulee siitä, että järjestelmästä puuttuu "pää" eli näkyvä sivusto.

Mikä Storyblok on?

Storyblok on itävaltalainen headless-CMS, jonka vahvuus on visuaalinen editori. Toisin kuin monessa headless-järjestelmässä, sisällön muokkaaja näkee muutokset sivun esikatselussa reaaliajassa. Sisältö rakennetaan komponenteista, joten samaa tuotekorttia tai banneria voi käyttää eri sivuilla ja kanavissa. Koska yritys on eurooppalainen, EU-alueelle sijoitettu data on helppo järjestää, mikä helpottaa tietosuojakysymyksiä.

Missä Storyblok on vahvempi?

• Monikanavaisuus. Sama sisältö verkkosivulle, mobiilisovellukseen ja muihin kanaviin yhdestä paikasta.
• Kehittäjän vapaus. Sivusto voidaan tehdä millä tahansa nykyaikaisella kehyksellä ja se voi olla hyvin nopea, koska se julkaistaan esimerkiksi staattisena tai reunapalvelimilta.
• Tietoturva. Julkinen sivusto ja sisällönhallinta ovat erillään. Hallintapaneeli ei ole samassa osoitteessa, eikä sivustolla ole lisäosia, joihin hyökätä.
• Komponentit. Sisältö pysyy rakenteisena ja johdonmukaisena isossakin organisaatiossa.

Missä WordPress on vahvempi?

• Kokonaisuus. WordPressissä on valmiina sivusto, hallinta, käyttäjät, haku, lomakkeet ja tuhansia lisäosia. Headless-ratkaisussa jokainen näistä pitää rakentaa tai liittää erikseen.
• Kustannukset. Headless-sivustossa maksetaan sisällönhallinnasta, sivuston hostingista ja jatkuvasta kehityksestä. Storyblokin hinnoittelu riippuu muun muassa käyttäjien määrästä ja liikenteestä. WordPress-sivusto on yleensä edullisempi rakentaa ja ylläpitää.
• Verkkokauppa. WooCommerce on valmis verkkokauppa. Storyblokin kanssa kauppa toteutetaan erillisellä verkkokauppa-alustalla ja yhdistetään siihen.
• Itsenäisyys. WordPress-sivustoa voi päivittää ja kehittää moni toimija. Headless-sivusto on sidottu siihen kehyskoodiin, jonka joku on kirjoittanut, joten kehittäjän vaihto on raskaampaa.

Mitä headless-projekti vaatii?

Storyblokin hinta on vain osa kokonaisuutta. Headless-sivustossa pitää rakentaa tai valita erikseen ainakin nämä:

• Sivuston koodi valitulla kehyksellä, esimerkiksi Next.js:llä tai Astrolla ja jokaiselle sisältökomponentille sitä vastaava osa koodiin.
• Hosting sivustolle, joka on eri palvelu kuin sisällönhallinta.
• Esikatselu, jotta visuaalinen editori näyttää muutokset oikein.
• Lomakkeet, haku ja sivukartta, jotka WordPressissä tulevat valmiina tai lisäosana.
• Julkaisuputki, joka päivittää sivuston, kun sisältöä muutetaan.

Mikään näistä ei ole vaikeaa kokeneelle kehittäjälle, mutta ne kaikki pitää tehdä ja ylläpitää.

Entä headless WordPress?

WordPressiäkin voi käyttää headless-tyyppisesti: sisältö haetaan sen rajapinnasta ja sivusto tehdään erikseen. Tämä yhdistää WordPressin tutun hallinnan ja vapaan kehyksen, mutta samalla menetetään osa WordPressin eduista, kuten lisäosien toiminnot ja editorin esikatselu. Käytän sitä yleensä vain, kun WordPress on jo käytössä ja sisältöä tarvitaan myös sovelluksessa.

Kumpi kannattaa valita?

Valitse Storyblok, jos:

• julkaiset samaa sisältöä useaan kanavaan
• sinulla on kehitystiimi tai pitkäaikainen kehityskumppani
• tarvitset hyvin nopean, nykyaikaisella kehyksellä tehdyn sivuston.

Valitse WordPress, jos:

• tarvitset sivuston tai verkkokaupan, jota voi päivittää ja kehittää ilman jatkuvaa kehitystiimiä
• haluat valmiita toimintoja lisäosina
• budjetti on rajallinen.

Pienempien alustojen vertailun löydät artikkelista Wix ja Squarespace vai WordPress.

Usein kysyttyä

Onko headless-sivusto nopeampi kuin WordPress?

Usein on, koska se voidaan julkaista valmiiksi rakennettuina sivuina. Hyvin tehty WordPress-sivusto hyvällä hostingilla on kuitenkin myös nopea ja nopeusero näkyy lähinnä raskaissa sivustoissa.

Pystyykö sisällöntuottaja käyttämään Storyblokia ilman kehittäjää?

Sisällön päivittäminen onnistuu visuaalisessa editorissa hyvin. Uudet sivutyypit ja komponentit tarvitsevat kuitenkin kehittäjän, koska ne pitää toteuttaa myös sivuston koodiin.

Voiko WordPressistä siirtyä Storyblokiin?

Voi. Sisältö siirretään rajapintojen kautta ja sivusto rakennetaan uudelleen valitulla kehyksellä. Siirto on käytännössä uusi sivustoprojekti.

Mitä Wix ja Squarespace ovat?

Wix ja Squarespace ovat kotisivukoneita: sivusto tehdään selaimessa valmiiden pohjien päälle ja hosting, tietoturva ja päivitykset kuuluvat kuukausimaksuun. Squarespacen pohjat ovat tunnettuja tyylikkyydestään. Wix on joustavampi ja siinä on enemmän lisätoimintoja sovelluskaupasta.

Missä kotisivukoneet ovat vahvoja?

• Helppous. Sivuston saa pystyyn päivässä ilman teknistä osaamista.
• Ei ylläpitoa. Päivityksistä ja tietoturvasta vastaa palveluntarjoaja.
• Ennustettava hinta. Yksi kuukausimaksu kattaa hostingin ja työkalut.
• Valmiit pohjat. Etenkin Squarespacessa pohjat näyttävät hyviltä sellaisinaan.

Missä kotisivukoneet rajoittavat?

Sivusto on vuokralla. Et omista sivustoa samalla tavalla kuin WordPress-sivustoa. Jos palvelun hinta nousee tai ehdot muuttuvat, vaihtoehdot ovat vähissä.

Siirtäminen on vaikeaa. Tämä yllättää useimmat. Wixistä ei voi viedä koko sivustoa muualle, joten siirto tarkoittaa käytännössä sivuston rakentamista uudelleen. Blogin artikkelit saa siirrettyä, mutta sivut ja ulkoasu eivät siirry. Squarespacen vienti tuottaa WordPress-muotoisen tiedoston, mutta mukaan tulevat vain tavalliset sivut ja yksi blogi. Esimerkiksi kauppasivut, tuotteet, portfoliosivut, video- ja äänisisältö, tyylit ja oma CSS jäävät pois.

Laajentaminen on rajattua. Kun tarvitaan jotain, mitä palvelussa ei ole valmiina, esimerkiksi oma sisältötyyppi, yhteys toiminnanohjaukseen tai erikoinen hinnoittelulogiikka verkkokauppaan, vaihtoehtoja on vähän. WordPressiin sen voi rakentaa.

Suomalaiset tarpeet. WordPressiin ja WooCommerceen löytyvät valmiina suomalaiset maksutavat, kuljetusyhtiöt ja kirjanpidon integraatiot. Kotisivukoneissa valikoima riippuu siitä, mitä palvelu tukee.

Entä hakukoneet?

Wixin ja Squarespacen sivustot näkyvät hakukoneissa nykyään hyvin ja perusasiat, kuten otsikot, kuvaukset ja sivukartta, onnistuvat niissä. Rajat tulevat vastaan, kun halutaan tarkempaa hallintaa, esimerkiksi omaa rakenteista dataa, tarkkoja uudelleenohjauksia tai laajaa sisältöä hyvin rakennettuna. WordPressissä nämä ovat kokonaan omassa hallinnassa.

Jos nykyisen sivustosi näkyvyys hakukoneissa ja tekoälyhauissa mietityttää, sen voi selvittää alustasta riippumatta SEO- ja GEO-auditilla.

Mitä WordPress vaatii vastineeksi?

WordPress vaatii ylläpitoa: päivitykset, varmuuskopiot ja hyvän hostingin. Sen voi hoitaa itse, ostaa hallinnoidulta hosting-palvelulta, kuten Seravolta, tai sopia ylläpidosta kehittäjän kanssa. Ilman ylläpitoa WordPress-sivusto vanhenee ja muuttuu tietoturvariskiksi. Tämä on rehellinen hinta joustavuudesta.

Mitä siirto WordPressiin vaatii?

Jos päätät siirtyä, siirto kannattaa tehdä suunnitellusti, jotta hakunäkyvyys ei katoa:

1. Kartoita nykyiset osoitteet. Listaa kaikki sivut ja artikkelit, myös ne, joihin muut sivustot linkittävät.
2. Siirrä sisältö. Tekstit, kuvat ja blogin artikkelit siirretään ja tarkistetaan. Tässä vaiheessa kannattaa samalla siivota vanhentunut sisältö pois.
3. Rakenna uusi sivusto. Ulkoasu ja toiminnallisuus toteutetaan WordPressiin ja lomakkeet, analytiikka ja evästeasetukset otetaan uudelleen käyttöön.
4. Tee uudelleenohjaukset. Jokainen vanha osoite ohjataan vastaavaan uuteen osoitteeseen. Tämä on hakunäkyvyyden kannalta tärkein vaihe.
5. Seuraa julkaisun jälkeen. Google Search Consolesta näkee, löytyykö rikkinäisiä linkkejä tai puuttuvia sivuja.

Kumpi kannattaa valita?

Wix tai Squarespace riittää, jos:

• tarvitset esittelysivuston, jossa on muutama sivu
• haluat tehdä ja päivittää sen itse
• et tarvitse integraatioita tai laajaa verkkokauppaa.

Valitse WordPress, jos:

• sivuston pitää kasvaa tai siinä on paljon sisältöä
• tarvitset verkkokaupan suomalaisilla maksutavoilla ja kuljetuksilla tai yhteyksiä muihin järjestelmiin
• haluat omistaa sivustosi ja voida vaihtaa hostingia tai kehittäjää vapaasti.

Jos olet jo kotisivukoneessa ja seinä tulee vastaan, autan siirrossa WordPressiin niin, että hakunäkyvyys säilyy. Lisää WordPress- ja WooCommerce-palvelusta.

Usein kysyttyä

Onko WordPress kalliimpi kuin Wix tai Squarespace?

Alussa usein on, koska sivuston rakentamiseen käytetään enemmän työtä ja ylläpito maksaa. Pitkällä aikavälillä ero kapenee ja WordPressissä ei tarvitse aloittaa alusta, kun tarpeet kasvavat.

Voiko Wix-sivuston siirtää WordPressiin?

Voi, mutta sivusto rakennetaan käytännössä uudelleen. Blogin artikkelit voidaan siirtää ja vanhoista osoitteista tehdään uudelleenohjaukset uusiin, jotta hakunäkyvyys säilyy.

Voinko päivittää WordPress-sivustoa itse yhtä helposti?

Voit, jos sivusto on rakennettu sitä ajatellen. Rakennan sivustot niin, että tekstit, kuvat ja tuotteet päivittyvät editorissa ilman koodia ja ilman, että ulkoasu hajoaa.

Tapa 1: oikea lohko build-prosessilla

WordPressin virallinen tapa on luoda lohkolle oma lisäosa create-block-työkalulla:

npx @wordpress/create-block@latest yhteystietokortti
cd yhteystietokortti
npm start

Työkalu luo valmiin rakenteen: block.json kuvaa lohkon, edit.js määrittää lohkon ulkoasun editorissa ja save.js sivulle tallennettavan sisällön. Tekoälylle annetaan tehtäväksi kuvata lohko, esimerkiksi "yhteystietokortti, jossa on kuva, nimi, titteli ja puhelinnumero. Kuvan voi vaihtaa sivupalkista." Tekoäly muokkaa nämä tiedostot. Lopuksi npm run build kääntää koodin ja npm run plugin-zip paketoi lisäosan asennettavaksi.

Sopii, kun lohkossa on paljon vuorovaikutusta editorissa, se on osa isompaa teemaa tai lisäosaa ja koodia ylläpidetään versionhallinnassa.

Haittana on Node.js-ympäristö ja build-vaihe, jota ilman koodia ei voi muuttaa. Jos tiedostoja muokataan suoraan palvelimella, muutos ei vaikuta mihinkään.

Tapa 2: ACF Blocks

ACF:llä lohko tehdään PHP:llä ja kentillä. Editorin puoli syntyy ACF:n kenttäryhmästä, joten JavaScriptiä ei tarvita. ACF 6.0:sta alkaen lohko määritellään samalla block.json-tiedostolla kuin WordPressin omat lohkot ja ACF:n asetukset ovat acf-avaimen alla:

{
  "name": "acf/yhteystietokortti",
  "title": "Yhteystietokortti",
  "category": "widgets",
  "acf": { "mode": "preview", "renderTemplate": "template.php" }
}

Lohkon HTML kirjoitetaan PHP-sivupohjaan:

<div class="yhteystietokortti">
  <h3><?php echo esc_html( get_field( 'nimi' ) ); ?></h3>
  <a href="tel:<?php echo esc_attr( get_field( 'puhelin' ) ); ?>">
    <?php echo esc_html( get_field( 'puhelin' ) ); ?>
  </a>
</div>

Lohko rekisteröidään teemassa tai lisäosassa register_block_type()-funktiolla ja kentät luodaan ACF:n hallintanäkymässä.

Sopii, kun sisältö on rakenteista ja päivittäjän pitää täyttää vain tietyt kentät. Tekoäly tuottaa ACF-lohkon luotettavasti, koska rakenne on yksinkertainen.

Haittana on, että ACF Blocks vaatii ACF PRO -lisenssin ja editorin esikatselu on hieman jäykempi kuin JavaScript-lohkossa.

Tapa 3: kevyt lohko ilman build-vaihetta, zip-tiedostona

Yksinkertaisen lohkon voi tehdä tavallisella JavaScriptillä, joka käyttää suoraan WordPressin editorin valmiita kirjastoja. Lisäosassa on neljä tiedostoa samassa kansiossa:

lainauslaatikko.php

<?php
/**
 * Plugin Name: Lainauslaatikko
 * Description: Yksinkertainen lainauslohko.
 * Version: 1.0.0
 */
add_action( 'init', function () {
	register_block_type( __DIR__ );
} );

block.json

{
  "apiVersion": 3,
  "name": "peltopiri/lainauslaatikko",
  "title": "Lainauslaatikko",
  "category": "text",
  "attributes": {
    "teksti": { "type": "string", "source": "html", "selector": "p" }
  },
  "editorScript": "file:./index.js"
}

index.asset.php kertoo WordPressille, mitä kirjastoja skripti tarvitsee:

<?php return array( 'dependencies' => array( 'wp-blocks', 'wp-element', 'wp-block-editor' ), 'version' => '1.0.0' );

index.js

( function ( blocks, element, blockEditor ) {
	const el = element.createElement;
	const { RichText, useBlockProps } = blockEditor;

	blocks.registerBlockType( 'peltopiri/lainauslaatikko', {
		edit: ( { attributes, setAttributes } ) =>
			el( 'div', useBlockProps( { className: 'lainauslaatikko' } ),
				el( RichText, {
					tagName: 'p',
					value: attributes.teksti,
					onChange: ( teksti ) => setAttributes( { teksti } ),
					placeholder: 'Kirjoita lainaus…',
				} )
			),
		save: ( { attributes } ) =>
			el( 'div', useBlockProps.save( { className: 'lainauslaatikko' } ),
				el( RichText.Content, { tagName: 'p', value: attributes.teksti } )
			),
	} );
} )( window.wp.blocks, window.wp.element, window.wp.blockEditor );

Kansio pakataan zipiksi (zip -r lainauslaatikko.zip lainauslaatikko) ja asennetaan kohdasta Lisäosat → Lisää uusi → Lataa lisäosa.

Sopii pieneen, yksittäiseen lohkoon, jonka haluaa sivustolle nopeasti ilman kehitysympäristöä.

Haittana on, että koodi on kömpelömpää kirjoittaa kuin JSX:llä ja lohkon kasvaessa siitä tulee nopeasti vaikea ylläpitää.

Sudenkuoppa 1: sivusto kaatuu

Tekoälyn tekemä lisäosa voi sisältää PHP-virheen, joka kaataa koko sivuston. WordPress 5.2:sta alkaen palautustila lähettää tällöin ylläpitäjän sähköpostiin linkin, jolla pääsee hallintaan ja voi poistaa vikaantuneen lisäosan käytöstä. Se toimii vain, jos sivuston sähköposti toimii ja ylläpitäjän osoite on oikea.

Jos sähköpostia ei tule, lisäosa pitää poistaa käytöstä palvelimen puolelta:

• SFTP:llä tai hosting-palvelun tiedostonhallinnassa: nimeä lisäosan kansio uudelleen wp-content/plugins-kansiossa.
• SSH:lla ja WP-CLI:llä: wp plugin deactivate lainauslaatikko.

Ennen kuin asennat mitään, tarkista, että sinulla on jokin näistä pääsyistä. Jos ainoa pääsy sivustoon on WordPressin hallintapaneeli, olet kaatumisen jälkeen hosting-palvelun tuen armoilla. Ota myös varmuuskopio ja kokeile lisäosaa ensin testiympäristössä, jos sellainen on.

Sudenkuoppa 2: lohkon validointivirhe

JavaScript-lohkon save-funktio tallentaa HTML:n sivun sisältöön. Jos tekoäly myöhemmin muuttaa sitä, jo tehdyt lohkot näyttävät editorissa virheilmoituksen, jonka mukaan lohko sisältää odottamatonta sisältöä. Ratkaisuja on kaksi: lohkolle määritellään sen vanhat tallennusmuodot (deprecated), tai lohko tehdään dynaamiseksi, jolloin HTML tulostetaan PHP:llä joka kerta. ACF Blocks ovat aina dynaamisia, joten niissä tätä ongelmaa ei ole.

Sudenkuoppa 3: kuka vastaa tietoturvasta?

Zip-tiedostona asennettu lisäosa ajetaan samoilla oikeuksilla kuin WordPress itse. Se voi lukea tietokantaa, lähettää dataa ja muuttaa mitä tahansa. Tekoälyn koodi näyttää usein valmiilta, mutta siitä voi puuttua:

• tulosteiden suojaus, kuten esc_html(), esc_attr() ja wp_kses_post()
• käyttöoikeuksien tarkistus ja nonce-tunnisteet, jos lohko tallentaa tai hakee tietoja
• syötteiden tarkistus.

Vastuu on sillä, joka asentaa koodin. Valmiille lisäosalle tulee päivityksiä tekijältä, mutta itse tehtyä ei päivitä kukaan muu. Siksi jokaisella omalla lisäosalla pitää olla nimetty ylläpitäjä, koodi versionhallinnassa ja tieto siitä, mitä se tekee. Koodin pitää myös olla jonkun ihmisen lukema ennen asennusta.

Mikä tapa kannattaa valita?

• Build-prosessi, kun lohko on osa ammattimaisesti ylläpidettyä teemaa tai lisäosaa.
• ACF Blocks, kun sisältö on rakenteista ja ACF PRO on jo käytössä. Teen itse suurimman osan lohkoista näin.
• Kevyt zip-lohko, kun tarvitaan yksi pieni lohko nopeasti ja ymmärrät, mitä koodi tekee.

Jos haluat sivustollesi omia lohkoja, jotka on rakennettu ylläpidettäviksi ja turvallisiksi, se kuuluu WordPress-työhöni.

Usein kysyttyä

Voiko tekoälyn tekemän lisäosan asentaa suoraan tuotantoon?

Ei kannata. Kokeile ensin testiympäristössä, ota varmuuskopio ja varmista, että pääset tarvittaessa poistamaan lisäosan palvelimen puolelta.

Tarvitaanko ACF Blocksiin ACF PRO?

Kyllä. ACF Blocks on ACF PRO -lisenssin ominaisuus. Ilmainen ACF riittää kenttiin, mutta ei lohkoihin.

Mitä teen, jos sivusto näyttää vain virheilmoituksen?

Tarkista ylläpitäjän sähköposti palautuslinkin varalta. Jos sitä ei tule, poista viimeksi asennettu lisäosa käytöstä SFTP:llä, hosting-palvelun tiedostonhallinnalla tai WP-CLI:llä, tai pyydä apua hosting-palvelun tuesta.