Så da var det gjort, jeg har overført Snooze.no til Wordpress. Det var definitivt en del arbeid, men det bestod hovedsaklig av å overføre spill, videoer og annet inn i Wordpress. På grunn av det nye designet jeg har utformet, var jeg nødt til å lage nytt bildemateriale til alt som lå der, som også gjorde at jeg ikke tok meg bryet med å kode en automatisk konvertering fra det gamle systemet (eller rettere sagt SQL) til Wordpress. Totalt var det over 500 forskjellige spill og videoer på Snooze, men jeg valgte å begrense overføringen til i underkant av hundre. En av årsakene til dette er at jeg har brukt videoer og spill som ikke lenger er tilgjengelige, men også fordi det rett og slett ikke var verdt tiden. Valget gjorde jeg ved å se på trafikken det siste året i Google Analytics, og velge de som var mest besøkt, eller som hadde lenker tilbake. Jeg vil anta at jeg fortsatt har alle sidene som står for 80-90 prosent av all trafikken.

Friendly URL og 301 redirect
Når jeg overførte til wordpress, fikk jeg endelig fjerna en del slett arbeid fra tidlig utvikling av Snooze. På grunn av at jeg ikke kjente godt nok til CakePHP som jeg brukte, ble det ikke så pene URLs som jeg hadde ønsket. Når jeg kom endre inn i systemet innså jeg at jeg kunne gjøre akkurat som jeg ville med URLs, f.eks. som jeg har gjort på KinoFilmer, men dette ble hardkodet i Snooze, og derfor ikke så enkelt å endre etter at siden har vært online en stund. Det er selvsagt viktig å bevare så mange lenker inn til spesifikke saker som mulig, og passe på at besøk fra Google ikke kommer til en 404-side mens Google oppdaterer sitt register, så derfor har jeg lagt inn 301-redirect (permanent flyttet). Dette var langt enklere enn jeg trodde, men måtte alikevel manuelt fikse hver eneste en, siden det ikke fantes noen logisk måte å mappe fra gammel til ny URL. 301-redirect i .htaccess-filen fungerte utmerket, inkludert RSS-feed, slik at jeg ikke mister lesere derfra. For å redirecte i .htaccess, bruker du syntaxen nedenfor, og det fungerer fint selv med Wordpress Rewrite Rules:

Hvordan ikke bruke AJAX
Da jeg lagde forrige versjon, brukte jeg en god del javascript for å forbedre funksjonaliteten. Det jeg vil anbefale alle andre som skal gjøre det samme å gjøre, er å basere seg mindre på AJAX, altså asynkom javascript og XML. For kommentarer kan det absolutt være nyttig, men regelen min fra nå av er; Om du ikke skal sende inn noe, så prelast alt første gang siden laster og ikke hent nytt innhold ved hjelp av AJAX. Årsaken til dette er enkel, det er ingen grunn til å vente med å hente innhold om du vet hva for innhold du potensielt skal hente. Det finnes kanskje unntak, som f.eks. kommentarfeltet i YouTube, men om jeg noen gang får så mye data at overføringen av siden blir et problem, så får det så være. Bruk AJAX for stemmegiving, kommentarer og annet interaktivt, og unngå det så langt som mulig på innhold som ellers kunne vært statisk.

Bygg en solid grunnmur (eller bruk noen andres solide grunnmur)
I programmering finner vi mange såkalte design patterns, altså problemstillinger som gjentar seg flere ganger. Når du møter slike problemer, bør du enten ha kunnskapen eller tilegne deg kunnskapen som trengs for å løse problemet dette problemet, altså lære design patternet (designmønster på norsk, men det høres bare rart ut). Dette kan overføres til flere av problemene jeg hadde, blant annet kommentarer, innlegg og brukere. Dette er vanlig innhold på de aller fleste sider på nettet, og det finnes ikke annen grunn enn at du vil lære om du vil utvikle det selv. Sjansene er store for at andre har gjort det bedre og sikrere allerede, dessuten sparer du tid. Det samme gjelder CMS. Etter hvert som jeg har brukt Wordpress mer og mer, så har jeg blitt gladere og gladere i custom fields. De kan inneholde hva jeg vil, og de kan brukes slik jeg vil. Så lenge du har innhold i en eller annen form, som er knyttet til brukere (trenger ikke nødvendigvis å være noen relevans) og de har kommentarer (eller ikke), så er det mulig å bruke Wordpress (eller andre sterke CMS for den saks skyld). Jeg så på det som et stort steg da jeg hoppet fra MySQL+PHP til CakePHP, unngikk hele problematikken med database, og fikk et godt skille mellom presentasjon og logikk i systemene, men det er enda et nytt steg å kunne bruke en ferdig backend med administrasjon. Et annet godt prinsipp etter min mening i programmering, programmer på så høyt nivå som mulig. Andre ting jeg er glad for at jeg slipper å bekymre meg for mer er UTF-8 vs. ISO-8859-1 (som var en rot på den gamle versjonen), tidligere omtalte Captcha (Aksimet) og tags.

Et eksempel på hacks av Wordpress
Jeg har et lite eksempel på hvordan jeg ignorerer hele flyten om normalt er i wordpress. Jeg har nyheter på Snooze, som jeg henter fra Google News via RSS. Jeg lagde enkelt og greit et par sider, lagde en listen hack i page.php med switch-case, og vips, så henter den ikke lenger innholdet som egentlig ligger der, men benytter seg istedet for RSS-feed. All design, sidebars og caching blir beholdt som vanlig i Wordpress, siden innholdet uansett vil “gå gjennom systemet”.

Wordpress er en gave fra Gud?
Neida, det finnes fortsatt problemer med Wordpress, og jeg har absolutt støtt på noen. Et av disse problemene var da jeg skulle hente ut excerpt fra innleggene for å lage knapper med lenke, beskrivelse og tittel til sosiale bokmerker. Du kan vel kanskje si at the_excerpt skal fungere fint til dette? Problemet er bare at alle funksjonene jeg har funnet i Wordpress som automatisk henter/lager excerpt (kort utsnitt av teksten eller egendefinert tekst) har innebygd echo, som gjør at det blir printet ut på siden. Jeg ønsket å kjøre det gjennom urlencode() og potensielt htmlspecialchars() for å få fjernet potensielle ‘ og ” som kunne ødelegge lenke-taggen. Den eneste funksjonen som ikke automatisk printet det ut som jeg fant, var get_the_content, men da måtte jeg selv skrive kode for å lage excerpt, og den benyttet seg ikke av potensielt egendefinert excerpt. Altså et eksempel på at man har begynt å nærme seg grensen for hvor høyt opp man kan programmere. Jeg har en følelse av at det er mulig å hente ut dette på annen måte i loopen, men har ikke funnet noe, kommenter gjerne om du vet noe. Forresten, i forbindelse med DRY-prinsippet jeg snakket om i forrige innlegg, så har jeg funnet ut at jeg må legge til og konfigurere sosiale bokmerker for alle sidene jeg har, og på flere plasser, noe som gjør at jeg trolig er tjent med å lage en plugin for norske bokmerker. Kanskje vi ser den snart, forhåpentlig et alternativ til AddThis for norske sider, med ekstra norske sider som Kudos, Nettby og Biip (som jeg ikke har sjekket ut enda om har funksjonalitet for å legge ut saker, hersens mobil-signup).

Men det blir mer Wordpress?
Sider jeg tidligere brukte en uke på å lage, tar nå en dag, og jeg har mer enn ti norske sider som venter på å bli fylt opp og markedsført. Dessuten har jeg både KinoFilmer.com og CopyPasteCode som lider av de samme sykdommene som Snooze, og derfor skal overføres til Wordpress. Etter at disse to er overført, så kjører faktisk alle sidene jeg har på Wordpress. CopyPasteCode blir det mest interessante, fordi det krever brukerinteraksjon, altså jeg må løse problemet med å la brukerne registrere seg, ha oversikt over egne koder, og innholdet er langt fra normalt blogg-innhold. Det blir nok det mest interessante prosjektet med tanke på hvor langt jeg klarer å strekke Wordpress, og jeg satser på å ha en ny post ute når jeg har kommet i gang med det. Ett av prosjektene som ikke baserer seg på Wordpress er IP Tracker (eller SiteTracker/SEO Tracker som jeg potensielt kaller det). Det er såpass spesielt innhold at jeg lager eget system. Et pluss er at nåværende versjon av CakePHP har et langt kraftigere bruker-system i bunnen, som jeg dermed kan benytte meg av. Det kjører forresten som det skal, og overvåker alle sidene mine, samt konkurrenter, på hvor de ligger i SERP, Pagerank, Analytics-tall, indekserte sider og innlenker. Det eneste problemet nå er at Analytics-tall krever Google innloggingsdetaljer, noe jeg ikke kan forvente at noen vil oppgi. Derfor blir jeg nødt til å enten gjøre den frivillig, eller se om det nye Google Analytics API kan hjelpe meg med saken.

Det finnes et programmeringsprinsipp som heter DRY eller Don’t Repeat Yourself. Om du koder det samme på flere steder, bør du finne en løsning hvor du kun trenger å programmere det en gang. Dette kan også utvides til det som på godt norsk heter “ikke finn opp hjulet på nytt”. Altså, ikke gjør det noen andre har gjort før igjen, med mindre du vet du kan gjøre det bedre, mer effektivt eller gjør det for å lære.

Da jeg starta å utvikle nettsider som jeg etterhvert håpet å kunne leve av, lagde jeg alt fra begynnelsen av, eller iallefall på toppen av rammeverket CakePHP. Dette gjorde at jeg måtte programmere alt selv, fra AJAX-kall, kommentarer, XML Site Map, sidevisninger, tags, database, caching og så videre. Jeg kunne skrevet et kapittel om hver av disse problemene, hvordan jeg gjorde det og hvordan jeg kunne ha gjort det bedre. Alt i alt en veldig god trening i programmering.

Nå har en del av disse sidene ligget brakk i nesten et år, f.eks. Snooze.no. En av de tingene jeg ikke rakk å gjøre ferdig før jeg igjen tok til med studiene på høsten, var å implementere Captcha-beskyttelse på kommentarer, noe som resulterte i at jeg nå har måttet slette 27 000 spam-kommentarer som har ligget på sidene mine. I tillegg har jeg en tips-side som jeg ikke en gang gidder å sjekke, siden de ikke blir lagt ut på sidene uansett. Jeg har nå implementert PHP-captcha (som jeg kanskje kan skrive en post om), men innså at jeg også måtte gjøre det samme for de andre sidene som har egen kode.

Dette gjør at jeg innser at den fasen hvor jeg trenger å bygge mine egne CMS er ferdig. Det er ingen grunn til at jeg skal gjøre det. Det var nyttig å gjøre det en gang, kanskje to ganger og tre ganger, for å lære språket, design og så videre, men ærlig talt er det ikke verdt det. Jeg bruker ti ganger så mye tid på å vedlikeholde en side som jeg selv har bygd, siden jeg må programmere all ny funksjonalitet selv, i forhold til å bruke et CMS som Wordpress. Årsaken til at jeg utviklet et eget system for disse sidene er at det ikke er standard blogg/nyhets-sider. Nå har jeg derimot brukt Wordpress som CMS så lenge at jeg innser at jeg kan gjøre akkurat det jeg vil med det. En post, kategori og side i Wordpress kan inneholde akkurat det jeg selv ønsker, kan vises slik jeg selv vil. Fordelene er innlysende. Spesielt er det nyttig med et oversiktig administrasjonspanel, hundrevis av nyttige plug-ins for kommentarer, SEO, video og annonser. Jeg trenger ikke å lage dette selv. Jeg fokuserer på å markedsføre siden. Det er vondt for mitt programmeringshjerte å måtte ta denne avgjørelsen, da det er utviklingen av sidene jeg virkelig synes er mest moro, men når jeg ser på tiden som blir brukt i forhold til det jeg får ut av det, er det ikke verdt det. Jeg får trøste meg med at det blir uansett en del custom deler i prosjektene.

Jeg tenker jeg kommer tilbake med en ny post om hvordan det er å migrere en side med trafikk og mye innhold inn til Wordpress. Det blir interessant å se hvordan jeg skal løse en del problemer med forskjellig innhold (kode, videoer, bilder) og hvordan det vil gå å endre perma-urler (og om jeg kan automatisere 301-redirecting). Firefox kræsjet når jeg skulle laste opp bildet til saken, noe som igjen illustrerte en fin finesse i Wordpress, autolagring av utkast. Denne posten ville aldri kommet frem om jeg hadde mitt eget CMS på denne siden.