E-handelsutvikling: nehrebeccy.pl

#To personer oppdaterer siden mellom arrangementene

Det er nyttig å begynne med hvem som faktisk skriver inn innholdet, for det avgjorde flere tekniske valg i dette prosjektet enn noe annet. R&K Nehrebeccy er et kunstnerisk byrå i Gdynia, drevet av Renata og Krystian Nehrebecki, i sammenhengende drift siden 1994. Det er de to som legger inn et nytt arrangement, ofte mellom to andre oppgaver, og som laster opp bildene fra kvelden i etterkant.

Et redaksjonsteam tåler et system med regler. To personer som gjør dette ved siden av sitt egentlige arbeid, gjør det ikke. Derfor er nettstedet bygget slik at feil er vanskelige å gjøre, ikke slik at de er mulige å rette opp. Konkret betyr det felter i stedet for fritekst, lister som genereres av relasjoner i stedet for lister noen vedlikeholder for hånd, og forhåndsdefinerte bildestørrelser i stedet for en vurdering ved hver opplasting.

Det er også grunnen til at det bevisst ikke finnes noen sidebygger her. Den som legger inn et arrangement skal fylle ut felter, ikke designe en side. Å designe en side ved hver oppføring er den korteste veien til et nettsted der tjue undersider ser ut som tjue forskjellige nettsteder, og det problemet oppstår ikke i uke én, det oppstår i år tre når ingen lenger husker hvordan den første ble satt opp.

#Innholdsmodellen: utøver og arrangement

Løsningen kjører på WordPress, og den første avgjørelsen handlet om hva en utøver er i databasen og hva et arrangement er. Den tilsynelatende billigste veien, å beskrive begge som vanlige innlegg eller enda verre som sider, sparer en ettermiddag under byggingen og koster ved hver eneste senere endring. Et vanlig innlegg har ingen plass til en arrangementsdato, et sted, eller rollen en bestemt utøver hadde nettopp den kvelden. Alt havner da i brødteksten, altså i ett tekstfelt det ikke går an å lese noe ut av programmatisk.

Utøver og arrangement er derfor egne innholdstyper her, knyttet sammen av en relasjon. Ett arrangement har flere medvirkende, én medvirkende har mange arrangementer, og nettopp den strukturen gjør det mulig å bygge to visninger av ett datasett: profilen med listen over opptredener, og arrangementssiden med listen over hvem som deltok. Hadde de listene vært skrevet inn for hånd på begge sider, ville hver endring krevd redigering to steder, og etter et år ville halvparten av dem stille ha kommet i utakt.

Taksonomier ordner det samme fra en tredje retning. Inndelingen av medvirkende i forfattere, skuespillere og journalister, og av arrangementer i konsert, forfattermøte, åpning og jubileum, gir lister ingen trenger å vedlikeholde. En ny oppføring med riktig kategori dukker opp på riktig liste av seg selv.

Byrået arbeider med over hundre polske og utenlandske forfattere, skuespillere og journalister, og har et eget gjenkjennelig format med litterære kvelder rundt møter med bokforfattere. Et slikt omfang er nettopp det som gjør forskjellen mellom en generert og en håndholdt liste merkbar.

#Hovedfunksjonene på siden

Utøverporteføljen er hovedvisningen. Hver profil samler bilder, en beskrivelse av arbeidet og historikken for samarbeidet, og rekkefølgen på informasjonen har én oppgave: å la noen avgjøre på få sekunder om denne personen passer til kvelden de holder på å planlegge. Derfor står bilde og kort beskrivelse over den fulle biografien, og listen over opptredener er synlig uten å scrolle til bunnen.

Kalenderen og arkivet er de samme dataene sett fra to sider. Kommende arrangementer er informasjon til et publikum, tidligere arrangementer er bevis overfor en oppdragsgiver. Et arrangement forsvinner derfor ikke når datoen passerer, det bytter visning.

Multimedia ligger inne i oppføringen og er ikke limt på til slutt. Galleriet fra en kveld er som regel det som overbeviser neste kunde, så det må være lett å legge til og raskt å åpne. De to kravene trekker mot hverandre, og hele ytelsesarbeidet i prosjektet handlet om å forene dem.

Galleriet krever i tillegg en vurdering som ingen av cache-lagene løser. En kveld gir bilder i et antall ingen ser gjennom på én gang, og å laste alle filene når siden bygges lar den besøkende betale for bilder hun aldri kommer frem til. Galleriet leverer derfor miniatyrer først og henter de store versjonene når noen åpner dem. Det høres selvsagt ut i dag, men på byggetidspunktet var utsatt lasting egen kode og ikke en opplysning i bildeelementet som nettleseren følger av seg selv.

Deling i sosiale medier hører til funksjonaliteten her, ikke til pynten. Nyheten om et forfattermøte sprer seg gjennom profilene til dem som deltar og gjennom sidene til institusjonene som er vertskap, så hver oppføring trenger riktige delingsdata: tittel, beskrivelse og et bilde som ikke er et tilfeldig utsnitt av bakgrunnen.

#Arkivet er salgsargumentet

På de fleste nettsteder med kalender er et passert arrangement avfall. Her er forholdet omvendt, og den ene omvendingen bestemmer hvordan datoen må lagres.

Et kunstnerisk byrå selger ikke et produkt en kjøper kan undersøke på forhånd. Det selger en kveld som ennå ikke finnes. Det eneste beviset den som bestemmer har tilgang til, er listen over kvelder som allerede har vært og navnene som opptrådte der. En side som forteller hva byrået kan gjøre, er svakere enn en side som viser hva det har gjort.

Den nærliggende løsningen er å henge datoen på oppføringen som et tilleggsfelt. I WordPress havner et slikt felt i metatabellen, der verdier er lagret som tekst og ikke som dato. En spørring etter fremtidige arrangementer slutter da å være en datosammenligning og blir en tekstsammenligning, som gir tull i det øyeblikket et dagsorientert format krysser et månedsskifte. I tillegg legger hver slik spørring på en kobling mot metatabellen, og filtrering og sortering på samme felt legger på flere.

Det finnes to rene utveier, og begge krever en beslutning ved starten og ikke etter et år. Enten skrives datoen i et format som sorterer riktig som tekst, altså år først og uten skilletegn, eller så bærer oppføringens egen publiseringsdato arrangementsdatoen og håndteringen av fremtidsdaterte oppføringer justeres, noe som flytter hele utvalget over på en indeksert kolonne i innleggstabellen. Forskjellen er usynlig ved femti oppføringer og godt synlig når arkivet har vokst i et tiår, som er nettopp det arkivet finnes for.

Den andre fellen gjelder adresser. Siden til et arrangement fra for noen år siden blir gjerne lenket fra biblioteket eller kulturhuset som var vertskap. Hvis adressen er bygget rundt hvorvidt et arrangement er kommende eller passert, endrer datoskiftet adressen og alle de lenkene brekker. Adressen må beskrive hva arrangementet er, aldri hvilken fane det tilfeldigvis vises i.

#Utfordringer og implementerte programmeringsløsninger

Å bla gjennom et stort utvalg uten full sideinnlasting kom først. Filtrering av medvirkende etter kategori og henting av flere deler av listen skjer over AJAX, og det betyr en konkret mekanisme: forespørselen går til WordPress sitt felles inngangspunkt for asynkrone kall. Det er verdt å vite hva det koster, for det forklarer resten av valgene. Hver slik forespørsel starter hele WordPress med alle utvidelser, og koster altså omtrent like mye som å generere en hel side, selv om svaret er et utsnitt av en liste. Over en økt der noen bytter filter flere ganger, summerer det seg.

Derfor holdes listen kort, filteret snevrer inn mengden inne i spørringen og ikke i nettleseren, og resultatet av en gitt filterkombinasjon kan mellomlagres. Alternativet, å hente alle medvirkende på én gang og sile dem i nettleseren, frister fordi koden blir enklere, og slutter å fungere nøyaktig når utvalget er stort nok til at det koster mer å sende hele enn å gjøre de ekstra kallene.

Ytelse på et medietungt nettsted kom deretter. En objektcache i minnet forkorter databasearbeidet for alt som uansett må gjennom PHP: sett av innlegg, taksonomibegreper, innstillinger. Et leveringsnett tar over filene, altså bilder og opptak, og i dette prosjektet er det derfra mesteparten av den merkbare forskjellen kommer, fordi bilder tatt i konsertsaler er det tyngste som leveres. Dette er to forskjellige problemer løst med to forskjellige verktøy, og det er verdt å si rett ut: en objektcache gjør ikke en bildenedlasting raskere, og et kantnett forkorter ikke en databasespørring.

Responsivt oppsett var den tredje utfordringen, og her er det verdt å plassere løsningen i sin tid. Da siden ble bygget, hadde nettlesere ennå ingen måte å velge bildevariant på klientsiden, og WordPress fikk den evnen flere år senere. Avgjørelsen om hvilken versjon av et bilde som skulle sendes, ble derfor tatt på serveren, ut fra registrerte bildestørrelser. Et galleri lastet opp rett fra fotografens kamera trengte derfor egne mellomstørrelser definert på forhånd, ellers lastet en telefon ned filen som var laget for en skjerm på et skrivebord.

En stilark-preprosessor var i den situasjonen ikke pynt, men verktøyet som holdt bruddpunktene på ett sted. Uten det sprer breddegrensene seg utover hele stilarket, og enhver endring i rutenettet berører et dusin steder samtidig. Oppsettet er også eldre enn native rutenett i nettlesere, så kolonnene hvilte på flytende elementer og prosentbredder, noe som krever forsiktighet når et galleri har varierende antall elementer og radene skal lukkes rent.

Til slutt: innhold, konfigurasjon og kode ligger i hver sin lag. Den egenskapen viser seg først ved den første mislykkede endringen etter lansering. Avhenger utseendet til en seksjon av hva noen skrev i brødteksten, er en visuell rettelse en innholdsendring og kan ikke rulles tilbake uten å kaste redaksjonelt arbeid. Holdt fra hverandre betyr en tilbakerulling at ett av lagene beveger seg, ikke alle tre.

#Support og vedlikehold

Oppfølgingen omfatter oppdateringer av kjerne og tema, gjennomgang av logger og sikkerhetskopier. Rekkefølgen betyr noe: en sikkerhetskopi ingen noen gang har gjenopprettet, er ikke en sikkerhetskopi, men en fil. Å verifisere gjenopprettingen er en del av arbeidet og ikke et tillegg til det.

Oppdateringer har en egen risiko på et nettsted bygget rundt relasjoner mellom innholdstyper. Når koblingen mellom en medvirkende og et arrangement holdes av et mellomlag, kan en endring der legge om hvordan koblingene lagres, og listevisningen ser da riktig ut helt til noen legger inn en ny oppføring. Derfor går oppdateringer først på en kopi, og kontrollen består i å opprette en ny kobling, ikke i å se på forsiden.

Små visuelle og funksjonelle endringer i vedlikeholdet følger samme regel som byggingen: en endring går inn i laget den hører hjemme i. En ny arrangementstype er et taksonomibegrep, ikke en ny mal. Andre proporsjoner i galleriet er en endring av registrerte bildestørrelser og en regenerering, ikke en stilregel limt på én underside.

#Slik gikk prosjektet

Det hele tok rundt seks uker, fra avklaring av omfang til publisering. Oppsett og plassering av elementer kom fra kunden, så fasen som spiser mest kalender i andre prosjekter falt bort her. Tiden gikk til innholdsmodellen og til de delene en skisse ikke viser: relasjonen mellom medvirkende og arrangement, hvordan datoen lagres, bildestørrelsene, og hvordan listene oppfører seg under filtrering.

Kantstilfellene ble testet mot en kopi av produksjonen, ikke mot en tom installasjon. På et nettsted med denne formen er forskjellen konkret: en tom installasjon har ingen oppføring med åtti bilder i ett galleri, ingen medvirkende knyttet til arrangementer spredt over flere år, og ingen oppføringer der datofeltet er fylt ut ujevnt fordi noen en gang skrev det inn for hånd i et annet format. Alle tre dukker først opp på ekte data, og hver av dem kan velte en listevisning.

Den avgjørende beslutningen ble tatt tidlig og handlet om å behandle arkivet som en fullverdig visning og ikke som restene etter kalenderen. Alt annet, fra datoformatet via adressenes form til at et passert arrangement beholder sin egen side, følger av det ene valget. Prosjekter der beslutningen tas et år etter lansering, ender med omskrevne adresser og tapte innkommende lenker, og den regningen betales av kunden og ikke av den som bygde.

Etter lansering gikk nettstedet over i vedlikehold drevet på byråets side, med vår støtte ved oppdateringer og ved endringer som går ut over redigering.

#Oppsummering

nehrebeccy.pl er nettstedet til et kunstnerisk byrå, bygget rundt to enheter, den medvirkende og arrangementet, og relasjonen mellom dem. Alle visninger kommer ut av den strukturen: profilen med opptredener, arrangementssiden med deltakere, listene etter kategori, og arkivet som i denne bransjen er et argument og ikke ballast.

Teknisk hviler løsningen på WordPress, en objektcache i minnet, et leveringsnett for medier og et responsivt oppsett fra en tid da responsivitet betød håndarbeid på hver bildevariant. Organisatorisk hviler den på noe enklere: et nettsted to personer driver ved siden av sitt egentlige arbeid, må tåle at ingen husker reglene fra overleveringen.