Vuosi WordPressin kanssa

 

Olen nyt tehnyt reilun vuoden päätyökseni WordPress-sivuja lukuunottamatta muutamaa viikkoa, jolloin olen tehnyt html-sivuja tai taittoa. Teen tässä yhteenvetoa joistakin WordPressin perustavanlaatuisista asioista, jotka ovat selvinneet vuoden aikana. Tähän aluksi haluan mainita, että olen asentanut juuri äsken tämän blogin täysin alusta uuteen tietokantaan ja se tuntuu nykyisin rutiinitoimenpiteeltä.

Aloitin WordPressin itseopiskelun vuosi sitten heinäkuussa. Tietoa löytyy pääasiassa WordPress.orgista ja alan ammattilaisten blogeista. WordPress on open sourcea, eli avointa lähdekoodia käyttävä järjestelmä ja sitä opetellessa täytyy olla kiitollinen kaikista keskustelupalstoilta löytyvistä tiedoista, koska ne ovat usein ainoat ja parhaat mahdollisuudet saada tietoa koodatessa eteen tuleviin pulmiin. Tieto on todella pirstaleista ja ratkaisut perustuvat omaan kokeiluun.

Suurin yllätys ja takaisku WordPressin kanssa tuli eteen noin vuosi sitten: WordPress-sivuja ei voi siirtää kuin html-sivuja, sillä käyttöliittymän puoli menee jumiin. Jumittuminen johtuu WordPress-järjestelmän olemisesta sidottu satelliittiaikaan, jonka se ottaa käyttöönsä WordPressin asennuksessa. Siirrettäessä sivut kansiona osoitteesta toiseen järjestelmän aikakäsitys sekoaa ja käyttöliittymä menee osittain jumiin. Useimmiten kuitenkin WordPress-sivustot devataan eli koodataan ennen julkaisua jossain muualla kuin niiden lopullisessa osoitteessa ja siirtäminen tulee eteen.

wordpress_grunge
Sivuston voi siirtää suhteellisen nopeasti kopioimalla tietokannan ja siirtämällä sivut paloina: asentamalla haluttuun osoitteeseen WordPressin, käyttämällä sivustosta kopioitua tietokantaa ja lataamalla palvelimelle teeman ja pluginit ja käymällä varsinkin pluginit käyttöliittymän puolella läpi. Viime aikoina, kohdattuani viimeisimmän WordPressin päivityksen (3.6) jälkeen suhteellisen paljon erilaisia ongelmia, olen siirtynyt “koulukuntaan”, joka kannattaa useimmissa tapauksissa sivujen asennusta täysin uuteen, freshiin tietokantaan siirrettäessä sivut lopulliseen osoitteeseen.Sivuja devattaessa on tullut useimmiten tehtyä paljon kokeiluja, kokeiltua plugineita, jotka on kuitenkin hylätty pois käytöstä ja tietokanta on usein käynyt läpi jo joitakin WordPressin versiopäivityksiä. Kaikki tämä saattaa olla tietokannan rasitteena. Asentaminen tyhjään tietokantaan teettää hieman enemmän töitä, mutta on uusi tietokanta on varmasti kevyt ja toimiva, eikä siellä ole mitään ylimääräistä rasitetta.

Olen myös huomannut, että mitä enemmän käytössä olevaan teemaan on rakennuttu käyttäjälle käyttöliittymän puolelle mahdollisuuksia ladata kuvia ja tehdä erilaisia päivityksiä normaalien blogitoimintojen lisäksi, sitä hitaammin sivut latautuvat. Parasta on korvata kaikki mahdolliset käyttöliittymän puolelle rakennetut päivitysmahdollisuudet normaalilla koodilla ja pitää käyttöliittymän kautta päivitettävien osioiden käyttö minimissä. Käyttöliittymän puolelta monipuolisiksi rakennetut teemat menevät myös WordPressin versiopäivitysten yhteydessä helpommin jumiin. Olenkin asentanut erilaisin tavoin tämän vuoden aikana WordPress-sivuja yli 20 kertaa alusta ja hommasta on tullut hyvin rutiininomaista. Pitää vain aina ottaa tiedostoista ja tietokannoista turvakopioita itselleen.

 

wordpress-plugins-bg

 

Akismet

WordPressin asennuksen mukana tuleva plugin Akismet kannattaa poistaa heti. Pluginista kerrotaan, että se on miljoonien käyttämä spam-kommenttien estämiseen tarkoitettu plugin, mutta jos erehdyt menemään pluginin sivuille, huomaat, että se on maksullinen, kun useimmat WP-pluginit ovat ilmaisia. Käytyäsi Akismetin sivustolla ostamatta pluginia käyttöön sivustollesi alkaa tulemaan paljon spam-kommentteja ja koko sivuston toiminta hidastuu. Akismet kannattaa siis poistaa ensimmäisenä ja miettiä vaihtoehtoja uudelleen sitten, jos spam-kommentteja alkaa ilmestyä.

CSS

Useissa teemoissa ja niiden muokkausohjeissa kehotetaan tekemään custom_style.css-tiedostoja. En suosittele custom_style.css:n tekemistä, sillä custom_stylea tehtäessä CSS:ää tulee usein hallittavaksi monikertainen ja päällekkäinen määrä. Jos kerran osaa CSS:ää koodata, kannattaa se tehdä suoraan style.css:n tilalle. Siltikin useimmissa teemoissa on sen lisäksi useita lisä-CSS-tiedostoja, joista osa on muokattavissa vain palvelimen puolella eikä käyttöliittymän Editor-osassa, joten muokattavaa CSS:ää riittää. En ole löytynyt mitään järkeä siihen, että useisiin teemoihin on siroteltu vielä käyttöliittymän puolelle erilaisia Custom CSS-bokseja.

blog-html5-css311