WordPress on noussut yhä useammin haastajaksi Drupalille, Episerverille ja Liferaylle isoissa verkkosivustoissa. Silti WordPressillä on useita heikkouksia, joiden sietäminen ei vain ole kaikille asiakkaille mahdollista. Käyn tässä artikkelissa eniten North Patrolin projekteissa vastaantulleet WordPressin heikkoudet läpi.
Mediahallinnan puutteet
WordPressin mediahallintakyvykkyys on varsin suppea. Mediakirjasto ei tue edes kansiointia, joten esimerkiksi isojen kuvakokoelmien hallinta on käytännössä mahdotonta. WordPress on kyllä varsin kyvykäs kuvien käsittelyssä ja optimoinnissa, mutta mediatiedostojen hallinta on hyvin puutteellista. Tätä voi joillain lisäosilla parantaa, mutta tälle alueelle ei ole yleistynyt mitään yksittäistä lisäosaa, jota laajalti käytettäisiin. Monet tosin tekevät mediahallinnan erillisillä kuvapankki- tai DAM (digital asset management) -järjestelmillä, joten aina julkaisujärjestelmältä ei erityistä kyvykkyyttä edes vaadita.
Samasta puutteellisuudesta kärsitään usein myös liitetiedostojen hallinnan kanssa, koska esimerkiksi monilla julkishallinnon sivustoilla erilaiset julkaisut, raportit ja lomakkeet ovat edelleen tärkeässä roolissa, eikä WordPressin mediahallinnalla näitä pysty mitenkään kansioimaan, metatiedottamaan tai luokittelemaan. Tätä puutetta voi joskus kiertää tekemällä esimerkiksi omia sisältötyyppejä, joiden sivuihin liitteet kiinnitetään, mutta tätä ei voi pitää mitenkään eleganttina mallina.
Käyttöoikeushallinnan puutteet
WordPressin käyttöoikeusmalli on varsin yksinkertainen, eikä se malli ole kovin helposti laajennettavissa. Esimerkiksi metatietojen tai hierarkiatiedon perusteella ei voi määritellä erilaisia käyttöoikeuksia. Rooli- ja ryhmäpohjaisten käyttöoikeuksien määrittelyä ei ole WordPressissä ollenkaan, joten käyttöoikeusmallien täytyy olla varsin yksinkertaiset, jotta WordPressin rooleihin ja sisältötyyppeihin sidottu malli riittää. Etenkin laajojen sisällöntuottajajoukkojen kanssa tämä voi tulla haasteeksi, koska WordPressissä joutuu helposti antamaan sisällöntuottajille erittäin laajat oikeudet sisältöihin ja mediatiedostoihin vaikka sisällöntuottajalta ei edellytettäisi kuin jonkin yksittäisen osion ylläpitämistä.
Kieliversioinnin puutteet
WordPress ei tue perustoiminnoissaan lainkaan monikielisyyttä, joten kaikki monikielisyyslisäosat ovat keksineet omanlaisensa tavat monikielisyyden toteutukseen. Näitä monikielisyyslisäosia on myös useita, eikä näiden väliltä valitseminen ole aivan selkeätä, koska ne on suunniteltu aika erilaisiin käyttötapauksiin. Raskain lisäosa, WPML, on kyllä hyvin monipuolinen, mutta on myös erittäin laaja-alainen lisäosa, jonka varaan ei välttämättä ole erityisen turvallista rakentaa monien kymmenien eri kielien ja/tai maasivustojen kokonaisuutta. Kilpailevat lisäosat ovat taas selkeästi suppeampia toiminnoiltaan, eivätkä välttämättä tue muita lisäosia kovin laajasti.
Kieliversioinnissa tulevatkin usein vastaan ne haasteet, jotka WordPressin lisäosiin perustuva systeemi aina sisältää. Jos iso sivustokokonaisuus nojaa kymmeniin eri lisäosiin, niin muutokset yksittäisissä lisäosissa voivat myös vaikuttaa kokonaisuuden toimintaan. Iso ja monimutkainen kokonaisuus voi olla mahdollista tehdä WordPressillä, mutta syntyvä kokonaisuus on helposti hauras, jolloin jatkokehitys ja palvelun luotettava ylläpito voi olla haasteellista.
Rakennehallinnan vaikeudet
WordPressin sisällönhallintanäkymät ovat hyvin sivukeskeisiä, jolloin esimerkiksi laajan ja hierarkisen sivuston rakenne- ja navigaatiohallinta voi olla haastavaa sisällöntuottajalle hahmottaa. Sivut toki tukevat hierarkista luokittelua, mutta tämä tehdään käytännössä yksittäisten sivujen metatietoja muokkaamalla.
Metatiedoilla tehtävä luokittelu on sisällöntuottajien kannalta usein vaikeasti hahmotettavaa, joten etenkin isoilla tietopankki-tyyppisillä sivustoilla tämä voi osoittautua aika merkittäväksikin ongelmaksi. Tähänkin on lisäosia olemassa, mutta mikään lisäosa ei ole vakiinnuttanut asemaansa.
Onneksi laajojen sivuhierarkioiden tarve on vähenemään päin. Monet sivustot siirtyvät kohti mediasivusto-tyyppisiä kategoriarakenteita, ja tässä maailmassa WordPress on tietysti aivan omimmillaan. Kaikki sivustot tuskin kuitenkaan mediasivustojen sisältövirtamaiseen esittämistapaan tulevat siirtymään jatkossakaan.
Joustavien sivupohjien puuttuminen
Sivukeskeisestä ajattelusta syntyvä toinen haaste liittyy lisäosien ja erilaisten lisätoimintojen kiinnittämiseen yksittäisiin sivuihin. Lisäosat ja lisätoiminnot kiinnitetään WordPressissä nimittäin aina sivupohjiin, joista ne sitten periytyvät alaspäin yksittäisille sivuille. Etenkin isoilla sivustoilla tämä voi johtaa tilanteeseen, jossa jokaisen sivun muokkausnäkymässä on valtavasti erilaisia valikkoja ja elementtejä, koska sivupohjasta periytyvät elementit ovat aina käytettävissä kaikilla sivuilla.
Erityisesti markkinointihenkisillä sivustoilla tämä tiukasti sivupohjiin sidottu malli voi johtaa varsin kaoottiseen sisällöntuottajakokemukseen. Markkinointi kun ei WordPressissä voi tehdä helposti yksittäisestä sivusta vaikkapa kampanjatarkoituksiinsa täysin erilaista sivua, jossa on erilaiset karusellit ja nostoelementit, vaan kaikki tarvittavat erikoiselementit tehdään sivupohjatasolla, jolloin ne myös periytyvät kaikkiin muihin sivuihin (ne eivät tietenkään tule sivuston käyttäjille näkyviin, mutta ruuhkauttavat sisällöntuottajien kokemusta).
Onneksi tätä asiaa helpottavat monet lisäosat (kuten ACF, eli Advanced Custom Fields) sekä toimistojen tekemät omat laajennukset (esim. ACF:ää hyödyntäen). Kilpailevia tapoja ratkaista tätä ongelmaa on kuitenkin pelkästään Suomessa kymmenittäin, ja eri toimistojen käyttämät lähestymistavat voivat olla hyvinkin erilaisia. Erityisesti hyvin monipuolisilla sivustoilla nämä kirjavat ratkaisumallit voivat osoittautua merkittäväksi ongelmaksi sisällöntuotannon ja -hallinnan näkökulmasta. Lisäksi erikoisista ratkaisuista peruuttaminen pois tai siirtyminen eteenpäin voi olla jopa täysin mahdotonta, koska iso osa näistä ”elementtieditoreista” ( tai ns. ”page-buildereista”) tallentaa sisällöt täysin omanlaiseensa rakenteeseen, joka ei ole siirrettävissä helposti mihinkään toiseen malliin.
Digimarkkinointikyvykkyyksien puutteet
WordPressin lisäosamaailma on hyvin monipuolinen, ja esimerkiksi sähköpostiuutiskirjeiden ja erilaisten analytiikkapalveluiden saralla WordPressin tarjonta on huikeata. Jotkut kehittyneemmät digimarkkinoinnin osa-alueet edellyttävät kuitenkin julkaisujärjestelmältä sisäänrakennettua kyvykkyyttä. Käytännössä yleensä puhutaan personoinnista, eli mahdollisuudesta näyttää eri sisältöjä eri käyttäjäryhmille. WordPress ei tällaista kyvykkyyttä sisällä lainkaan, eikä lisäosamarkkinakaan ole tähän oikein herännyt.
Myös monet markkinoinnin automaatioon liittyvät osa-alueet ovat sellaisia, joissa julkaisujärjestelmässä sisäänrakennettu tuki auttaisi merkittävästi. Esimerkiksi Episerver on hyvä esimerkki julkaisujärjestelmästä, jossa nämä toiminnot ovat sisäänrakennettuja ja koko järjestelmän käytettävyys on mietitty näitä toimintoja ajatellen. WordPressin on vaikea kilpailla tällä alueella, koska sen kanssa joudutaan nojautumaan kolmannen osapuolen työkaluihin, joiden kanssa toimiminen on käytännössä paljon monimutkaisempaa. Usein WordPressin kanssa myös vaaditaan koodarin avustusta, jotta oikeat tagit ja vaihtoehtoiset sisältöpalaset saadaan toimimaan kuten halutaan.
Yhteenveto: WordPress ei ole kovin monipuolinen julkaisujärjestelmä
Jos edellä mainitut asiat eivät ole ongelma, niin WordPress todennäköisesti palvelee loistavasti verkkosivuston julkaisujärjestelmänä. Jos taas useampi mainituista puutteista on itselle kriittinen asia, niin todennäköisesti kannattaa suunnata katse järeämpien kilpailijoiden suuntaan.
Erityisesti vahvasti markkinointipainotteisten ja laajojen sivustojen kohdalla WordPressin puutteet usein korostuvat. WordPressissä kun ei ole sisäänrakennettua mallia sivujen sisällä olevien elementtien sijoitteluun ja hallintaan, niin sivukohtaisia ratkaisuja on aina tehtävä jonkun lisäosan tai erityisvirittelyn avulla. Maailmassa, jossa jokaisen sivun pitäisi olla potentiaalinen laskeutumissivu, WordPressin tiukasti sivupohjiin sidottu maailma voi tuntua kovin kankealta.
Kaipaatko neuvoa omaan verkkopalveluhankkeeseesi? » Ota yhteyttä!
Web-ostajan opas 
27.2.2017 at 12:32
Olisi kiva kuulla samanlainen artikkeli myös Episerverin ja Drupalin heikkouksista.
TykkääLiked by 1 henkilö
27.2.2017 at 13:18
Episerverin ja Sitecoren välistä vertailua löytyy tuolta (2015 vuodelta): https://buyersguidetowebprojects.com/2015/10/06/philosophical-differences-sitecore-vs-episerver/
Epin ja Drupalin välisiä eroja löytyy tuolta (2014 juttu): https://buyersguidetowebprojects.com/2014/05/20/cms-battle-drupal-vs-episerver/
Ja kiitos ideasta, sama on ollut kyllä mielessä, että tän tyyppinen lähestyminen voisi olla hyödyllistä myös Epin ja Drupalin suhteen. Voi olla, että Episerver voisi olla se seuraava kohde, koska se on niin selkeästi erilaisin WordPressistä. Monet nämä WP:n haasteethan löytyvät myös Drupalista, koska on filosofisesti vähän samanlainen esim. sisällöntuottajan kannalta.
TykkääTykkää
27.2.2017 at 14:02
Niin mikä on sitten sellainen all-around julkaisujärjestelmä, jossa on kaikki kohdallaan ja löytyy vielä kehittäjiäkin? Haasteet joita tässä postauksessa nostit esille ovat olemassa, mutta monia niistä voidaan taklata asiantuntevalla lisäosien käytöllä. Lisäosat pitää tuntea ja päivitystilanteessa pitää olla asiantuntemusta korjata mahdolliset konfliktit.
Olemme toteuttaneen kohtuullisen laajojankin sivustokokonaisuuksia WP:llä. Asiakkaat ovat olleet sisällöntuotannon yksinkertaisuuteen tyytyväisiä. Monesti kysymys on siitä, että mitä haetaan. Laajassa sivustossa haetaan usein yhtenäistä näyttävää toteutusta, joka saavutetaan antamalla käyttäjille selkeät raamit, missä sisällönsyöttöä voi tehdä. Käyttöoikeustasoja voi eritellä tietyissä tilanteessa myös WordPressin multisite ominaisuudella.
Olemme toteuttaneet myös ennemmän monipuolisia laskeutumissivuja sisältäviä markkinoinnillisia toteutuksia. Niissä lähestymistapa on sivupohjien näkökulmasta erilainen kuin laajoja asiakokonaisuuksia sisältävillä sivuilla. Näissä olemme tehneet niin, että asiakas voi poimia tietyt lohkot ja muokata niiden sisällöt. WordPressiin on mahdollista saada myös monipuolisempia editoreja mutta ne mahdollistavat sisällönsyöttäjän näkökulmasta yleensä liikaa asioita. Kun käyttäjän vapauksia lisätään, niin monesti myös sivusto on helpompi saada sekaisin.
TykkääTykkää
7.3.2017 at 11:47
Järjestelmävalinta tarkoituksen mukaan – se lienee oleellisinta. Ch5 keksi pari pointtia lisää (tietoturvallisuus ja integroitavuus) kun havaittiin, että tässä listatut WP:n heikkoudet vastaavat aika suoraan Liferayn vahvuuksia. Ch5-sivuilla artikkelissa pohditaan myös, päteekö homma päinvastoinkin; WP:n vahvuudet ovat Liferayn heikot kohdat…? https://www.ch5finland.com/artikkelit/2017/fi_FI/liferayn-vahvuudet-taklaavat-wordpressin-heikkoudet/
TykkääLiked by 1 henkilö
12.3.2017 at 18:33
Kiitos kommentista, Anna. Ja kiinnostava jatkojuttu teiltä. On ihan totta, että Liferay esimerkiksi on monissa noissa mainituissa kohdissa aivan eri tasolla. Toisaalta, minusta se on ihan odotettua, koska onhan Liferay nyt merkittävää kertaluokkaa myös raskaampi ja kalliimpikin järjestelmä.
Esimerkiksi käyttöoikeusmalli on todellakin sellainen asia, joka rajaa WordPressin käyttöä esim. extranet-puolella erittäin paljon, kun taas Liferayssa se on yksi isoimpia vahvuuksia sillä puolella. Jutun lopussa tiivistätte hyvin, että Liferay on todellakin portaali, joka sopii hyvin tilanteisiin joissa integraatioiden keskiössä oleminen on kriittinen ominaisuus. Verkkosivustot aika harvoin ovat sellaisia, ja verkkosivustoihin liittyy sitten paljon muutakin usein. Siksi varmaan WordPress vs. Liferay ei ole lopulta kovin yleinen vertailu meilläkään North Patrolissa. Ne ovat hyvin eri asioihin suunniteltuja työkaluja.
Ymmärrän toki, että teillä on tarve kirjoittaa omassa blogissanne Liferay-lasit päässä, joten en lähde oikomaan sen tarkemmin jutun kaikkia kohtia, joiden kanssa voisin olla eri mieltä (niitä on kohtuullisen paljon), mutta pääpiirteittäin pointtinne ovat allekirjoitettavissa 🙂
Noista laajennuksistanne en ehkä ole aivan samaa mieltä. Esimerkiksi tietoturvan osalta en lähtisi väittelemään edes, koska kumpikin on aktiivisesti kehittyvä järjestelmä, josta pidetään kyllä huolta.
Nykyisin myös painotetaan tietoturva-asioissa paljon uusiin uhkiin reagointia, ja sillä saralla WordPressin coren automaattinen päivitysjärjestelmä on aivan toisella tasolla kuin perinteisemmin asiaa lähestyvillä järjestelmillä, kuten Liferayn tapauksessa. Täten tietoturvan suhteen voi hyvinkin tulla Liferaylle ns. turpaan, jos lähtee oikeasti matsia ottamaan 😉 Mutta kuten todettua, en nostaisi tätä asiaa edes pöydälle tässä yhteydessä.
WordPressin väittäminen jotenkin tietoturvattomaksi järjestelmäksi (sen perustarkoituksessa käytettynä, eli verkkosivustojen alustana) alkaa jo minulle edustamaan vähän tietämättömyyttä asioista. Plugareiden tietoturvasta toki voi puhua, mutta silloin aletaan olla jo aika kaukana perusjärjestelmän tietoturvasta, ja kolmannen osapuolen palikoita ja systeemejä on käytössä yleensä muillakin järjestelmillä (joten keskustelu karkaa nopeasti aika filosofiseksi siitä milloin kolmansien osapuolien työkaluihin luottaminen osana kokonaisuutta on järkevää ja milloin ei).
Integraatioiden saralla Liferayn ja WordPressin vertailu on myös hieman ongelmallista, koska ne lähestyvät asioita niin kovin eri tavoilla. Liferaysta on toki helppo väittää, että se on erittäin hyvin integraatioita tukeva alusta, mutta sitten taas WordPressin kohdalla on olemassa tuhansia täysin valmiita integraatiopalikoita tuhansiin erilaisiin järjestelmiin. Jos asiakas haluaa integroida CMS:n esim. sähköpostiuutiskirjetyökaluun ja CRM:aan, niin integraatiot hyvin todennäköisesti onnistuvat ilman koodaamista WordPressin kohdalla. Liferay:n ekosysteemi taas on täysin olematon verrattuna WordPressiin, joten Liferayn kohdalla pitää ryhtyä aina koodaamaan niitä integraatioita.
Tietysti jos puhutaan integraatioista nimenomaan hyvin asiakaskohtaisiin järjestelmiin tai tietovarastoihin, niin sitten asia on eri, mutta suurin osa verkkosivustoista ei integroidu eksoottisiin järjestelmiin, jos integroituu mihinkään. Täten verkkosivustojen saralla Liferayn arvioitu järeämpi integraatiokyvykkyys ei välttämättä ole kovin merkittävä asia kovinkaan monille asiakkaille. Ymmärrän toki hyvin, että Liferay:n (ja Liferay-kumppaneiden) näkökulmasta on järkevää nostaa integroitavuutta vahvuutena, mutta siitä on vielä mielestäni pitkä matka siihen, että voisi väittää WordPressin kärsivän siitä, että siihen olisi jotenkin vaikea integroitua. Nykyisin esim. REST API -kehityksen myötä ja ylipäätään plugariekosysteemin kehitystä katsoessa, on aika vaikea mennä väittämään, että WordPress olisi jotenkin suljettu järjestelmä johon ei voisi integroitua.
TykkääTykkää
28.6.2017 at 22:10
Tämän sinun postauksesta on jo aikaa, mutta päätinpä silti kommentoida. Allekirjoitan kaikki kirjoittamasi. Olen tehnyt sivuprojekteina WordPress-sivustoja – tosin pienille yrityksille. Vaikka ne ovat pienille, niin silti WP:n heikkouksia on tullut usein vastaan. Se on blogialusta ja siitä ei pääse yli eikä ympäri. Suurimmat hankaluudet ovat tulleet ylläpidon hankaluudesta sekä backend-käyttöliittymän monimutkaisuudesta. Itselle se on tietenkin selkeä, koska WordPressin kanssa on tullut touhuttua pitkän aikaa. Asiakas kuitenkin kokee sen joskus epäloogiseksi. Kun joudun ratkaisemaan asiakkaan väärinymmärryksiä tai selittämään mikä ylläpidollinen toiminta tapahtuu mistäkin, niin tajuan samalla, että sen tulisi pystyä tekemään helpommin.
Toinen on plugareiden monikirjavuus ja se epäluotettavuus, että onko niille tukea koko verkkosivun eliniän ajan. Ja tietoturvallisuus on tietenkin oma seikkansa. En ole tutkinut asiaa, mutta tuntuu että WordPress-sivustoja yritetään hakkeroida eniten.
Tein vähän aikaa sitten päätöksen, etten tee enää WordPress-sivustoja. Tai jos pyyntö tulee, niin teen nämä heikkoudet erittäin selväksi. Onhan tuo sentään pelkkä ”harrastus”. Tuo harrastus on aiheuttanut paljon tukipyyntöjä ja jälkiopastusta, jolloin joutuu ns. ylipalvelemaan siihen nähden mitä asiakas on maksanut verkkosivuista.
Uskon, että julkaisujärjestelmäksi on paljon parempia vaihtoehtoja. Itse olen tykästynyt Drupaliin sen ylläpitouden helppouden vuoksi, mutta itseltä ei löydy osaamista sellaisen sivuston luomisesta tai muokkaamisesta.
Tässä sekalaisesti pari omaa ajatusta WordPressistä 🙂 Mutta kiitos hyvästä postauksesta.
TykkääTykkää