I feel like this year has again started with many posts about how people are switching jobs. Don’t get me wrong – I’m sure it has been the right move and I’m really happy for them. Nevertheless, it has caused a little bugging feeling inside me.

When people share about their new jobs, they are justifiably always excited. The little bugging feeling is, that I think those posts do need a counterbalance. In the form of posts telling how great people’s current job still is. Otherwise, it’s easy to fall into thinking that you should find a new job just because “everyone is changing jobs, should also I?”.

Continue reading “On switching jobs.”

Here at Dude, we use the same database for the site’s all development and staging environments. With this neat arrangement, we always have the latest content shared between our developers, which is crucial as the team might be working on the same project at the same time. No need for database migrations or moving dump files. Backend developer can just tell to frontend developer that the new page is there and needs styling.

Continue reading “Using the same database for development and staging environments with WordPress Network”

Earlier today I needed to get posts across the entire WordPress Network installation into ACF post object field. To my surprise, this isn’t possible with ACF itself and few plugin implementations found from Github were abandoned or didn’t fit fully to my needs.

So what developer does in this kind of situation? Writes a plugin that adds a new field type.

Continue reading “ACF field for network post relations”

During the last six months, I’ve been thinking more and more how grateful I am for being able to contribute to the WordPress project. It has taught me so much on so many levels. Helping event organizers allows me to go (virtually) around the world and learn from different cultures. I get to work with amazing and super talented persons. New friendships and connections have been established. I’ve been trusted to take care of complex things and resolve those on my own.

It always gives a long-lasting good feeling, when you see someone you helped to make a blast out of their event or success in their contribution. But the utmost valuable thing has been endless warmth and respect for each other. Even if we wouldn’t always agree, everyone’s opinion is heard and taken into consideration. We work together towards the same goal.

Without my involvement in the project and without the discussion with thoughtful individuals, I wouldn’t be the person I’m today. WordPress project has given me the feeling of being part of something bigger and far more important than I’ve felt ever before, although I have been involved in too many soups to this age.

Continue reading “Three years on Contributing to WordPress project”

For a few years now, there has been silent, but a continuous bad feeling in my head about how much I use and depend on services of Google and Facebook. I’ve have fantasized about the idea of burning the bridge between me and these two giants. But as said before, my everyday life really depends on their products. Even thinking the amount of work on burning bridges has gotten me forget the plans.

Continue reading “Going Google and Facebook free”

Kirjoitus on julkaistu alunperin Duden blogissa.

Duden blogissa on puhuttu viimeaikoina suhteellisen paljon siitä, paljonko nettisivut maksavat ja mistä se hinta sitten koostuu. Jokaisessa kirjoituksessa olemme kertoneet sivuston olevan aina räätälöity 100% asiakkaan tarpeita varten, tuo räätälöinti ulottuu aina visuaalisesta ilmeestä syvälle konepellin alle.

Roni tiivistikin aiemmin osuvasti tuota konepellin alla olevaa osuutta. Ajattelin nyt avata tätä teemaa hieman enemmän näin back-end kehittäjän roolissa kahdessa erillisessä kirjoituksessa.

Kehitämme projektia mieluusti eteenpäin ja ainakin rakennamme sivustomme sellaiseksi, että niitä pystyy kehittämään eteenpäin.

Ensimmäisessä osassa käsittelen tietorakenteen suunnittelun tärkeyttä ja kerron miten me Dudella hoidetaan asia. Seuraavassa osassa kerron minkä takia ja miten kiinnittää huomiota myös hallintapaneeliin.

---

Kävijä näkee sivustosta ainoastaan ns. julkisen puolen, sen miltä kaikki tieto näyttää hienosti ja visuaalisesti aseteltuna. Tuskinpa kukaan tulee ajatelleeksi millä tavalla jokin tieto on tallennettu tietokantaan tai minkälaisilla palikoilla visuaalisuus on kasattu.

Käytännössä projektin koodaamisen aloitus alkaa aina tietorakenteen suunnittelusta. Yhtään riviä koodia ei kirjoiteta, ennen kuin tietorakennetta on mietitty vähintään päässä, mieluusti jopa analogisella paperilla.

Miksi suunnitella tietorakennetta?

Selkeyden vuoksi samaan asiaan liittyvän tiedon hallinnoiminen on hyvä olla mahdollista yhdestä paikkaa. Sivuston sisällön ylläpitäjälle on paljon selkeämpää päivittää yhden ominaisuuden kuvausta itse ominaisuuden muokkasnäkymästä, kuin erikseen jokaisella sivulla missä kyseinen ominaisuus näkyy tavalla tai toisella.

Tietorakenteen suunnittelu liittyy hallintapaneelin käyttömukavuuden ja selkeyden lisäksi vahvasti jatkokehityksen ennakointiin. Kuvitellaan tilanne, jossa esimeriksi ominaisuuksia listataan ainoastaan etusivulla ja etusivulle on luotu lisätietokentät ominaisuuksien lisäämistä varten. Mitä sitten kun asiakas haluaakin listata ihan samoja ominaisuuksia, edes osaa niistä muilla sivuilla tai jokaiselle ominaisuudelle oman laajan esittelysivun?

Kaikki aiempi ominaisuuksiin liittyvä back-end koodi muuttuu turhaksi ja hommat joudutaan tekemään tältä osin nollasta uusiksi. Jos tietorakennetta on taas mietitty etukäteen edes hieman ja luotu ominaisuuksille oma sisältötyyppinsä (custom post type, CPT), on homma todennäköisesti paljon kivuttomampi.

Miten Dude tekee tämän käytännössä?

Projekti käydään vielä kerran läpi yhdessä graafikon kanssa, jotta saadaan vastauksia seuraaviin kysymyksiin: minkälaisia sisältötyyppejä sivustolle tarvitaan? miten sen artikkelit jäsennellään? tarvitaanko kategorioita? onko sisältötyypillä arkisto tai sen yksittäisillä artikkeleilla julkista näkymää? linkittyykö joidenkin sisältötyyppien tiedot keskenään? mikä on sisältötyypin osoiterakenne (slug)? mikä on koko projektin kaiken sisällön osoiterakenne?

Vasta kun nämä asiat alkaa olla selvillä, aletaan kasaamaan sisältötyyppejä, niiden lisätietokenttiä (metadata) ja sivupohjia.

Käytännössä Duden back-end kehittäjän workflow lisäkenttien luomiseen ja sivuston julkiselle puolelle saamiseksi on seuraava:

1. Huomataan että esimeriksi etusivulla on nostoja tuotteen ominaisuuksista ja jokainen nosto sisältää otsikon, ikonin sekä lyhyen kuvauksen.
2. Selataan leiskat läpi ja katsotaan onko joillain toisella sivulla samanlainen elementti tai samat sisällöt esitettynä hieman eri tavalla.
3. “Ahaa, kaikki ominaisuudet esitellään yhdellä koontisivulla ja siellä näyttäisi olevan sama otsikko sekä ikoni, mutta eri kuvaus ja erilainen visuaalisuus.”
4. Luodaan ominaisuus -sisältötyypin artikkelille lisätietokentät ikoni, lyhyt kuvaus, lyhyt kuvaus etusivun nostossa ja käytetään otsikkona ominaisuuden nimeä.
5. Luodaan etusivulle lisäsisältökenttä josta voi valita nostettavat ominaisuudet, tai vaihtoehtoisesti luodaan yksittäisen ominaisuuden muokkaukseen valinta tätä varten. Tapa riippuu hieman siitä, miten etusivun muu sisältö rakentuu ja tarvitaanko ominaisuusnostoja myös muualla.
6. Luodaan teemaan osat (template part) erikseen yksittäisen ominaisuuden nostolle koonti- ja etusivulla. Näissä käytetään edellä mainittuja lisätietokenttiä. Ensimmäistä osaa käytetään ominaisuuksien koontisivun listassa ja toista etusivulla.
7. Teeman osissa tulostetaan kaikki olennaiset tiedot, tässä tapauksessa otsikko, edellä mainitut lisätietokentät ja yksittäisen ominaisuuden osoite ilman html-rakennetta (poislukien kuvien, otsikoiden ja linkkien html tagit).

Sama rumba toistetaan sivupohja kerrallaan ja sivun elementti kerrallaan.

Käytännössä Duden työmallilla, jossa jokaisessa projektissa on erikseen back-end ja front-end kehittäjät, sivuston julkinen puoli näyttää hyvin rujolle näiden työvaiheiden jälkeen, ennen kuin front-end kehittäjä rakentaa asettelun visuaaliseen muotoon. Kaikki sisältö on näkyvissä kuten kuuluukin, mutta ei kovin nätisti.

Front-end kehittäjä rakentaa projektista riippuen html-rakenteen ja css-tyylit sisällön ympärille ennen tai jälkeen taustatyön, usein antaen lisätehtäviä, korjaustöitä tai muita muutoksia back-end kehittäjälle. Loppu projektista etenee siis samaan aikaan front-end sekä back-end kehittäjän pöydillä yhteistyötä tehden.

PS. Ollaan Ronin kanssa höpöttämässä marraskuussa Tampere WordPress Meetupissa meidän tavasta tehdä sivustoja, tulehan ihmeessä paikalle!