Har i et stykke tid gået og barslet med en idé – brugeren skal kunne vælge mellem flere forskellige webdesign. Jeg synes at brugeren gerne må få en oplevelse af en „personlig” side som hun/han selv kan ændre designet af. Jeg synes rent personligt at det er fantastisk at man ved at skifte ”stylesheet ” og dermed ændre designet radikalt.

Målet for projektet er:
Give brugeren muligheden for at kunne ”customize” sitet ved at vælge mellem flere forud definerede design. Dog vil jeg begrænse mig til kun at lave et ekstra layout i denne opdatering og fokusere mest på at få selve koden til at virke. Det alternative design vil kun ændre header billede og farver. Men det er min mening at forberede løsningen til at man kan lave ”helt” andre webdesign.

Teknologier:

• Javascript (cookies, onload event og DOM manipulation)
• (x)html (form — dropdown menu)
• CSS (ekstra ”stylesheet ”som tilføjer ændringer af designet)

Flowcharts for applikationen:
Flowchart over onload eventen

Flowchart over onchange eventen

Workflow
Jeg fik hurtigt implementeret løsningen.

Skrev hurtigt de to funktioner.

For at give brugeren mulighed for at vælge mellem designs oprettede jeg en dropdown menu (select) og gav den en id så det var muligt at finde den via javascript.

Samtidig satte jeg onchange til setStyleCookie(). På den måde vil setStyleCookie() blive kaldt hver gang brugeren vælger en værdi.

Umiddelbart gik det nemt og smerte frit. Men desværre virkede løsningen ikke som forventet. Nogle dage efter fandt jeg ud af applikationen ikke kunne håndtere hvis brugeren ikke havde været på siden før. Det viste sig at jeg havde lavet min if struktur lidt for hård. Derfor løste jeg op for den så jeg bare checkede på Cookie(’mode’). Det tog noget tid at få det til at virke efter hensigten.

Men nu er løsningen klar så den kan nemt udvides og fin justeres.

Under en søgning efter et Sitemap plugin fandt jeg et plug-in som kunne generere forskellige ”sitebars” til forskellige sider og indlæg. Det havde jeg så tænkt mig at benytte senere. Fik hurtigt og smerte frit installeret plug-in’et. Dog virkede det ikke umiddelbart – manglede noget kode i min sitebar.php fandt jeg ud af. Rettede funktionskaldet: dynamic_sidebar() til generated_dynamic_sidebar(). Og så virkede det – nu var det bare at oprette en sitebar og tilføje den til de sider hvor den skulle vises. For at håndtere dette findes en dropdown menu under sider / indlæg i administrator modulet. Og nu kunne jeg så gå ind og finde sitebaren under ”widgets” og så tilføje de ”widgets” jeg vil have på den ”sitebar”.

Der opstod dog et problem – ikke alt i ”sitebaren” var genereret af ”widgets”. Disse elementer måtte jeg fjerne fra ”sitebar.php”.

Nyt problem
Nu har jeg en masse sider hvor jeg gerne vil have forskellige ”sitebarer” på. Men jeg havde ikke særlig mange ”widgets”. Så jeg måtte ud og finde ”widgets” som kunne forbedre mit site visuelt og funktionelt. Jeg fandt en del gode ”widgets” som jeg installerede dog også nogen jeg afinstallerede igen. Bl.a installerede jeg et ”widget” der kunne indsætte et RSS link på ens side. Jeg ville installere et RSS link så brugere kan abonnere på ændringer på min side – men grundlæggende synes jeg bare det er en pæn detalje med et RSS logo. Desværre var der fejl i så jeg fik 404 fejl i min rapport over SEO.

Egen løsning – RSS link
Men jeg overvejede at det nok var rimeligt simpelt at lave en løsning selv via html text plug-in’et. Det er bare at oprette et link med en id. Også oprette en regel med noget god padding og et baggrundsbilled. Selve logoet havde jeg fra den tidligere ”widget”. Lavede samme løsning til mine Flikr og Facebook links kunne nu også afinstallere et andet ”widget” (find-me-on). Jeg synes dette er en meget bedre løsning især fordi jeg helt har kontrol med hvad der er oprettet.

Et andet lækkert widget
Information om hvem der er online på sitet – synes jeg ikke er så væsentligt men det tilføjer dynamik på siden – på den måde at brugeren får indtryk af at siden er levende og bliver opdateret. Men samtidig giver det her plug-in mange muligheder i backend’en bl.a. kan man følge med i hvem der er online nu. Og hvem der har været online i de sidste 30 dage. Man kan tydeligt se ip-adresse, siden de kigger på og hvilken side de kommer fra eller om de har tastet adressen direkte. Desuden kan man se dem som prikker på et verdenskort. Søgemaskiner bliver også registret. Fantastisk plug-in.

Problem med ”Who is online” plug-in’et
Desværre var dette plug-in ikke oversat til dansk. Så jeg måtte sætte mig ind i hvordan man oversætter sprog filerne til WordPress. Det viser sig at de anvender GNU oversættelses ”frameworket” – GNU gettext. Altså et Linuxbaseret værktøj. Du kan læse mere om oversættelse af WordPress her. Der findes en mere behagelig udgave til windows Poedit. Poedit kan åbne et oversættelses katalog altså en *.pot fil. Når man åbner en sådan fil i Poedit. Listes original sproget i en kolonne og oversættelses sproget i en anden. I bunden findes to tekst bokse øverst vises en gentagelse af den celle man har valgt i de to kolonner. Man kan så oversætte i den nederste tekst boks. Når man så gemmer – gemmer man en *.po fil hvor den danske oversættelses kode da_DK er den sidste del af navnet. Bagved gemmes også en *.mo fil som er den endelige oversættelses fil. Efter jeg havde oversat kunne jeg oploade disse to filer til ”language” mappen i plug-in mappen.

Grundlæggende er første led i en optimering klaret, titlerne står allerede på den optimale måde.

Næste trin er at oprette sitemap og robots.txt.

Selvom meta tags ikke har den store effekt på moderne søgemaskiner opretter jeg dem alligevel for den effekt de alligevel har.

For nemt at oprette meta anvender jeg metamaten.dk (tip fra vejleder Jesper) som hurtig opretter metatags som så kan kopieres ind i header.php. Jeg har også et par sites ”jazzsiten” og ”VI” som ikke skal indexeres af robotter derfor oprettes en meta i disse.

Sitemap
Et sitemap er et xml dokument der beskriver siderne i et site og som er udformet så søgemaskiner kan læse og forstå det. Her søgte jeg efter et plugin på WordPress.org under extensions. Fandt plug-in’et „XML-Sitemap Generator for WordPress”. Ganske god applikation til formålet.

Under min søgning efter sitemap plug-in fandt jeg et andet plug-in til SEO som endnu bedre kan håndtere titlerne på siderne. Samtidig kan det monitorere 404 fejl – altså sider som ikke længere findes. Desuden lister plug-in’et en masse whitepapirs om SEO. Det hedder ”SEO Ultimate”. Det var hurtigt installeret.

Google webmaster tools / GWT
Nu kunne jeg gå ind på GWT og aktivere min side. Altså ved at tilføje en speciel meta id i header.php, som var genereret af GWT. Ganske simpelt og hurtigt.

Herefter kunne jeg uploade Sitemap’et til GWT – det blev indlæst uden fejl.

Nu var turen kommet til robots.txt som bare er et regelsæt for hvad hvilke søgemaskiner må indexere.

Jeg åbnede for alle søgemaskiner og begrænsede specifikke mapper f.eks. wp-admin o.lign.

I de her dage går jeg og holder meget øje med hvad der sker og sender mit Sitemap igen når jeg laver ændringer på mit site. Jeg søger hele tiden at eliminere 404 fejl og stramme op hvor jeg kan.

Tilmeldte sitet til Bing (MSN Search). Funktionalitet en helt identisk med den på GWT – den eneste forskel er at der skal stå en ekstra regel i robots.txt altså en sti til hvor sitemappet kan hentes fra. GWT brokker sig over linien – men jeg har skrevet den som sidste regel i robots.txt for at være sikker – men vil checke op det i de kommende dage.

Yderligere optimering
Allerede efter kort tid fik sitet jævnlige besøg af søgerobotter — desværre kunne jeg se i min 404 log (liste over sider som ikke bliver fundet) at der var nogle links som ikke virkede efter hensigten. Fejlen skyldes at jeg anvender relative links og ikke havde tænkt over at konteksten skifter alt efter om man kommer ind via tags eller kategorier. Løsningen er desværre at benytte fulde stier. Så jeg har ændret links.

Men det nytter ikke noget bare at ændre disse referencer / links for google vil jo stadig have de forkerte links i deres system. Derfor er det nødvendigt også at oprette en 303 omdirigering. Altså en regel som fast sender brugeren videre til det rigtige sted. For at kunne foretage omdirigeringer  installerede jeg et plug-in som kan håndtere omdirigeringer. På denne måde får f.eks. google besked på at referencen er ændret fremover. Her den 7. januar 2010 kom der en enkelt 404 på min log. Og der vil nok komme flere men tror nok jeg har fanget de fleste.

GWT
Jeg logger tit på og ser hvordan min side bliver placeret i søge resultater hos google. Det er ret fantastisk, at se det virker at søgemaskine optimere. Mit site ligger nu som første resultat  i visse søgninger (i skrivende stund — kan jo ændre sig). Du kan læse nærmere om hvorfor det er godt at være højt placeret i søgninger her.

Beskrivelse
Justering af title tag i HTML’en. Grundlæggende skrives titlen med navnet på portalen først og herefter navnet på siden. Jeg synes ikke at det information der skal fanges af søgemaskinen først skal være navnet på portfolien det bør være navnet på selve siden. Da navnet på siden eller indlægget bedst beskriver indholdet af siden. Derfor vil jeg ændre på rækkefølgen af disse nøgleord.

Foretog følgende rettelser
Ændrede på rækkefølgen og tilføjede en fast tekst til forsiden. Her er koden som jeg lavede i header.php

<title><?php if(is_front_page()){echo "Portfolio for Thomas Riis, Multimediedesigner Studerende @ Knord"; } ?><?php wp_title(); ?></title>

Jeg har dog efter denne rettelse tilføjet et plug-in som kan håndtere titlerne endnu bedre. Så løsningen er ikke så relevant for mig mere men det virkede.

Beskrivelse af issue
Issuet går ud på at når brugeren går ind under indlæg — vises kategorien som de er listet under som „parent”. Jeg vil hellere have at man kan se siden man kommer fra.

Idé
Jeg vil fortage en nem løsning af issuet i Javascript og anvende „document.referrer”.

Løsning / workflow

• Fandt ud af at der fandtes et javascript til sitet som jeg kunne skrive koden i.
• Gik ind i header.php for at  indstille „BreadcrumbNavXT”, til at skjule kategorien når et ’single’ indlæg er loaded.
• Samtidig tilføjer jeg et ekstra span element med id’en „postnavn”.
• Herefter manipulerede jeg document.referrer vedhjælp af split(’/’);
• Og så finder jeg næst sidste emne i result arrayen fra split() altså navnet på tidligere side er nu fundet.
• Dette navn sættes ind som et link som får referrer som href og samme navn som titel.
• For at få fat i „postname” id’en benyttede jeg den velkendte Jquery eller Mootools funktion$(’postname’); som svarer til getElementById()

Workflow

• Søgte efter løsninger på Google og wordpress.org
• Fandt frem til at jeg kunne lave en „custom function” som kunne iterere igennem indlæg– eller sidedata. Ville så splitte input ved hvert „p” element. Her kunne jeg anvende PHP funktionen explode() der returnerer en array med alle de forskellige linier.
• Så skulle array’en bare fordeles mellem „content_left” og „content_right”. Her dividerede jeg længden af array’en med 2 og afrundede. Brugte følgende if-sætninger for at udvælge data til kolonne 1 og 2. if ($i <= round($len/2)) og if ($i >= round($len/2)). Det tog lidt tid at nå til denne præcise if-sætning prøvede uden round i begyndelsen men det virkede ikke ordentligt — fordelingen blev ikke god. For at returnere dataene til websitet benyttede jeg følgende wordpress funktion: wpautop()
• Fandt denne funktion anvendt under en søgning på Google: Se anvendelsen her iøvrigt anvendes en funktion der minder om min. Den inspirerede mig til at lave lidt ændringer.
• Nu var det så bare at finde ud af hvordan jeg kunne samle dataene til at sende over til funktionen.
• Prøvede at tilskrive returværdien af the_content() til en variabel jeg sendte videre til funktionen. Men problemet er bare at sidedata alligevel genereres før funktionen startes så jeg endte op med den tidligere visning plus visning i to koloner i bunden. Søgte på google her var medicinen.

<?php ob_start();  ?>
<?php the_content();  ?>
<?php $con = ob_get_clean(); ?>
Kunne nu ryde op, teste yderligere og flytte løsningen over til WordPress installationen på mit eget domæne og lave ændringerne for „single.php” altså indlæg vist alene.

Installering af WordPress på Surftowns server:

• Lavede en installation via „1-kliks” installeren gik fint – men konstaterede det var en ret gammel version af WordPress så jeg valgte at opdatere.
• Opdateringen lavede jeg via WordPress’ „opdatér”
• Herefter hentede jeg en backup af WordPress databasen hos skolens host.
• Og her efter lavede jeg en opdatering af tabellerne uden at slette data som kunne være en del af opdateringen.
• Herefter hentede jeg filer over fra skolens host over til den nye installation.
• Desværre kunne jeg konstatere at der var noget galt – front-end view’et blev ikke genereret.

Afinstallerede WordPress og begyndte forfra. Alt virkede som det skulle. Fik installeret temaet.

• Nu kunne jeg så installere de plug-ins jeg benyttede tidligere.
• Da jeg havde installeret „lightboxen” bemærkede jeg at front-end view’et ikke blev genereret igen.
• Nu vidste jeg hvor problemet kom fra.
• Søgte på problemet og fandt ud af at det skyldes at PHP4 blev anvendt.
• Checkede phpinfo() – kunne slå fast at hosten kørte med PHP4.
• Gav Surftown besked om at jeg gerne ville køre PHP5 i stedet.
• Det ville tage 48 timer at skifte over til PHP5.
• Nu kunne jeg så hente data over til mit site valgte at benytte WordPress eksport / import.
• Det virkede meget nemt – men kunne konstatere at ikke alle billedfiler blev hentet over.
• Fandt et nyt problem – alle billeder havde fulde stier til skolens host. Så alle billeder blev hentet fra skolens host. Problemet gjaldt også links.
• Ændrede alle links og filreferencer til relative stier i stedet for – fremover vil jeg anvende relative links på WordPress installationer så det er nemt at skifte domæne.
• I øvrigt virkede alle plug-ins nu. Testede systemet igennem og konstaterede alt virkede helt.

Ville videre med sitet i weekenden 5. og 6. december. Desværre ville Surftown opdatere alle deres systemer så jeg kunne ikke flytte helt. Derfor måtte jeg opdatere mit portfolio under skolens domæne. Det er faktisk først nu her den 8. december at jeg kan komme i gang med at overføre de sidste artikler til mit eget domæne.

Inden jeg valgte at flytte WordPress installationen til mit eget domæne. Havde jeg følgende overvejelser.

• Det er lidt farligt at installere plug-ins uden at kunne tage backup. Vil have egen kontrol over databasen således at jeg selv kan tage backup og reetablere igen hurtigt samme dag.
• Siden skal være mere personlig.
• Jeg vil gerne kunne bruge „modrewrite”.
• På sigt skal mit site alligevel væk fra skolens domæne – da jeg kun har adgang så længe jeg er under uddannelse.
• Vil kunne lave subdomæner til alle projekt sites.

Jeg var ganske godt tilfreds med WordPress-temaet. Men synes at det manglede en „breadcrumb”. Således at slutbrugeren tydeligt kan se, hvilken side hun eller han er på. Altså her på mit portfolio. Dog vil indlæg ikke kunne vise den foregående side i hierarkiet. F.eks. linker Studieprojekter siden over til flash-bannerkampagne som er et blog emne desværre ved blog emner ikke hvilket link der fører til dem. Så i stedet for vil jeg anvende kategorier. BreadcrumbNavXT understøtter den funktionalitet. Senere vil jeg fikse dette således at jeg anvender javascript og „document.referrer” til at indsætte tidligere besøgte side i stedet for kategorien. Og så vil jeg indstille BreadcrumpNavXT til at skjule kategorien.

Workflow:

1. Søgte først efter om der var en udvikler der havde lavet et breadcumb plugin. Fandt et jeg kunne lide.
2. Downloadede applikationen og uploadede den til min wordpress installation.
3. Herefter aktiverede jeg plug-in’et.
4. Først kunne jeg ikke se outputtet fra plug-in’et.
5. Men ved hjælp af firebug var det nemt — kunne hurtigt finde tag elementet.
6. Lavede en ny CSS-regel til at styre klassen breadcrumb med.
7. Havde issues med den markup der blev generet. Der var ikke noget jeg kunne anvende til at markere nuværende sidenavn.
8. Fandt ud af at jeg kunne ændre på indstillingerne i plug-in’et så nuværende sidenavn fik class-attributten „current”. Så var det nemt at lave en regel for nuværende sidenavn.

Det var dejligt nemt at tilføje plug-in’et. Synes faktisk det er mere besværligt at tilføje et lignende plug-in i Joomla!.

Nu hvor jeg var i gang med at ændre i css’en besluttede jeg mig til at fjerne de ekstra side links som var i temaet. I stedet for ville jeg hellere vise links til ressourcer der interesserer mig. Ændrede herefter sorteringen i hovedmenuen. Rykkede siden om mig helt til sidst da den ikke skal være siden man kommer først ind på. Da det ikke er det vigtigste i portfolien.

Ændrede i „parmalinks” for at gøre sitet mere „SEO” (Search Engine Optimazation) venligt. Således at url’en forklarer destinations siden. Ændrede også lidt i titlerne for at få bedre urls. Kunne dog ikke anvende den metode jeg helst ville. Ville anvende mod_rewrite. Men urlen index.php/yyyy/mm/dd/titel er ganske fint. Når systemet ikke er opsat til mod_rewrite er der ikke så meget andet at gøre.