1. Logga in till din databas, lämpligen via phpMyadmin
2. På fliken SQL skriver du in följande kod som kommer visa vilket tema du har på din blogg

SELECT *
  FROM wp_options
    WHERE option_name = 'template'
    OR option_name = 'stylesheet'
    OR option_name = 'current_theme';

3. Skriv ned vad som står i fältet option_value, detta ifall det går åt skogen ännu en gång kan du åtminstone ändra tillbaka som det var innan.
4. Ändra nu dessa värden till ett annat tema, förslagsvis default, det gör med följande SQL-kod

UPDATE wp_options SET option_value = 'default' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'default' WHERE option_name = 'stylesheet';
UPDATE wp_options SET option_value = 'WordPress Default' WHERE option_name = 'current_theme';

5. Om du inte fick några felmeddelanden på ovanstående steg ska du nu ha bytt ditt tema till det vanliga blå som följde med din blogg.

I ovanstående exempel har jag utgått från att du valde wp som prefix vid installation av din databas, har du något annat får du ändra i SQL-koden ovanför till det prefix du har valt. Det du ska ändra är alltså wp_options till ditt egna prefix_options, vad du nu valde. Om du är osäker kan du kolla vad tabellerna heter när du loggat in med phpMyadmin

Kortfattat tar Fabian upp dessa problem

1. Frames
   Hela sidan är uppbyggd med frames, varför är ett mysterium då sidan skulle fungera lika bra utan, dock så slipper man ju se alla de hemska och världslånga länkarna i adressfältet, vilket är problem nr 2. Sedan att frames inte ens finns med i kommande html5 kan ju inte kännas framtidssäkert (även om webbläsare även stödjer äldre tekniker)
2. URL
   Alla länkar är hur långa som helst, de berättar inget om sidan. En länk idag ska vara kort och i princip vara sidans titel
3. Redirects
   Alla gamla sidor har man nu slängt och går man in på en gammal sida får man felmeddelande, korrekt hade givetvis att göra en http 301 till motsvarande sida på den nya webbplatsen.
4. Tabeller
   Sidan är uppbyggd med tabeller, de som jobbar med webbdesign säger no no. Tabeller tabulerar man data i, inte bygger upp sidans struktur. Man hör det nästan på namnet- t-a-b-e-l-l
5. Inline kod
   Både javascript samt css hittas inline lite varstans, lite för frekvent, vilket gör sidornas storlek onödigt stora. Alla byte små blir snart en kilobyte stor.

Nu får jag inte heller betalt för att analysera sönder deras webbsida men en sak som är fel, som i ett riktigt fel är teckenkodningen. Deras server matar ut sidan i utf-8 men i alla metataggar på sidorna anges iso-8859-1. Dags att bestämma sig, jag röstar på utf-8

Sedan kan man även tycka att det är onödigt skicka med dubugg-meddelanden ut till vanliga besökare, likaså att skicka med js och css för adminsidorna och 10000 tomrader.... Önskar mig även roligare titlar på sidorna, nu har ni satt samma på alla och jag vet vad ni heter, jag vill t.ex. ha bakverkens namn osv.

Gör man en nslookup på http://www.steinbrenner-nyberg.se hamnar man på 217.28.193.41 vilket ägs av Webb Kooper AB, därmed bekräftat att de är medskyldiga till att visa hur man ej ska göra en webbsida är 2010.

Jag föreslår att Kooper börjar läsa på lite om webbdesign hur den utförs idag och hur den utfördes innan 2000
Ni kan börja träna genom att få bort lite valideringsfel, inte för att jag är petig med sådant själva men övning ger färdighet. Öppnar man en tagg, ska man även stänga den

Från att haft rubriken 0470515249 - Vi vet vem som har ringt dig bytte jag till Har 0470515249 ringt dig? - Vi vet vem det är

Folk som söker efter ett telefonnummer för att kolla vem det är har givetvis en fråga, besvara deras fråga och intresset att besöka din sida ökar. Nu hade min konkurrent redan varit smart, kopierade idéen från honom

Ökningen har i de flesta fall legat på 10-30% och tack vare att sidan har relativt många telefonnummer, där var och ett får ett antal träffar blir summan av kardemumman bra optimering på lite nedlagd tid.

Dipparna i kurvan beror på helger, då verkar det inte ringas lika många samtal och således söker inte folk efter dessa telefonnummer lika frekvent. Har lagt in en trendlinje så ser man ökningen lättare. Ska bli spännande och se om ökningen håller i sig även nästa månad.

Har ni några smarta tips på enkla förbättringar för oss lata människor? Med lat menar jag att jag ofta inte har alltför stor energi att göra stora ändringar då jag jobbar heltid med webbutveckling på ett  företag. Hoppas dock på att mina sidoprojekt någon dag tar fart och att jag kan lägga hela min tid på dessa

Data sidan använder kommer ifrån SynLex, i framtiden hoppas jag dock kunna köpa in en riktig lista, då blir nog sidan annonsfinansierad i samma veva för att ha chans att åtminstone täcka kostnaden för inköpet. Tills vidare får sidan dock rulla på utan annonser, förutom på mobilsidan där jag testar mobilannonser via Adsense samt att jag har några länkar för att driva trafik till 2 av mina andra sidor.

Antalet besökare är inte imponerande, sidan tuffar dock på och kräver i princip ingen tid från min sida. Jag får ha den lite som en lekplats för att testa nya saker och har redan testat och lärt mig nya saker. Det jag har gjort på sidan som förhoppningsvis ska uppskattas:

• Mobilanpassat designen, en lite enklare design visas för iPhone och Android
• Accelerator till Internet Explorer 8
• Sökplugin till diverse webbläsare

Att anpassa designen för mobiler verkade vara uppskattat då antalet besökare via denna kanal fördubblats sedan månadsskiftet. Det dumma är att jag bara testat sidan i Sony Ericsson X10 och inte med iPhone, så den kanske ser helt knas ut för dessa besökare. De andra nya funktionerna har jag inte fört statistik på även om jag kunnat, kände inget behov helt enkelt.

Några bra tips och idéer på vad jag kan göra på sidan för att förbättra upplevelsen ytterligare?

Målet detta året är att hamna på top 2 när man söker på synonymer, får se hur nåbart det blir utan några större insatser från min sida Med tanke på att detta inte är en MFA-sida kanske folk länkar till den om den bara blir tillräckligt intressant, redan idag ligger den på plats 4 när jag kollade Google nyss.

Ett så stort företag som Google tycker jag allt kan hålla lite mer koll än att alla bor i USA, särskillt när man just besöker google.se kunde man tro datumen var anpassade för Sverige. Liten tabbe

Senaste erbjudandet jag fick var från en webbyrå i Stockholm, Trafficlight, som jag lite tveksamt tackade ja till. Företaget som anser sig vara en sökmotorvänlig webbyrå borde nog tänka till lite, sätta sig i lugn och ro och läsa sökmotorernas riktlinjer och regler. Dock betyder ju detta att inlägget passar i min klagoblogg.

Går man till Google kan man klar och tydligt läsa några saker som är förbjudna:

• Länkar avsedda att manipulera PageRank
• Köpa eller sälja länkar som höjer PageRank

De påpekar även att man ska undvika att använda knep för att förbättra rankningarna i sökmotorn. Detta är nog det som är värst för alla som driver webbsidor. Det är självklart alla vill lägga högst upp på sökmotorer och därav använder diverse knep. Då tycker jag mer man får ta in sin personliga moral och fundera vad både en själv och företaget vill stå för.

Skulle jag driva en webbyrå och sälja tjänster inom SEO, då hade jag tänkt till både en eller två gånger innan jag gick ut och köpte inlägg från Blogvertiser, jag kanske hade kanske satt en http 301 på övriga sidor (ex. webbyrastockholm.se) som kan uppfattas som gråzooner. Visst länkar jag kors och tvärs mellan mina webbsidor, några mer eller mindre MFA-sidor, ofta för att antingen driva trafik eller för att manipulera sökresultaten, det känns dock inte lika stort då jag endast har dessa sidor som hobbyprojekt.

Alla mins vi nog stormen då bl.a. Compricer och Folkia drabbades. Allt är inte svart och vitt inom SEO-branschen och vi kommer nog lång tid framöver se fler liknande händelser. Jag följer många personer i denna värld vad de skriver om och tycker många skriver både bra och vettiga saker.

Uppenbarligen är jag inte bättre själv med sökmotoroptimering, förvisso skyller jag på att jag inte ens jobbat med detta för kunder, har jag iaf satt nofollow på utlänken då Google bestämt att man ska göra så på betalda länkar, vilket just detta inlägg i grund och botten är. Borde stått tydligt i uppdragsbeskrivningen att alla skulle gjort detta så hade problemet varit ur världen.

Personligen följer jag rådet hos Martin, Därför ska du inte arbeta med SEO, och jobbar som kodapa främst i back end och håller koll på funktion samt säkerhet. Hoppas detta blir ännu en tankeställare för alla inom denna uppenbarligen både utsatta och gråa verksamhet. Har absolut inget emot Martin utan det blev bara enklare att skriva om något som trillade in i min e-post.

Även rutan med sökförslag har fått mindre designändringar.

Slutligen har även sidan med sökresultaten fått ett förändrat utseende i vänsterkolumnen. Du kan bland annat välja uppdateringar (Twitter, Facebook) samt diskussioner (olika forum), söka efter bilder på webbsidor och mycket mer. Ni får testa allt i detalj själva när det är er tur

Den vackra designen, kräver dock Silverlight

Update: Portalen är nu nere för tekniskt underhåll, finally.

HemmaHos är en hyresgästportal som Familjebostäder har lanserat till sina hyresgäster. Inne på portalen kan man felanmäla och följa sitt ärende, annonsera om lägenhetsbyte och man kan också ta del av lokal information från sin bovärd och distriktschef.

Spännande tänker jag, äntligen något som kan bli riktigt lovande. Det här är mina synpunkter efter cirka 10 minuters användande.

Förhoppningen med detta inlägg är att få upp ögonen på folk att säkerhet är viktigt, fastän jag påpekat brister hos Familjebostäder för snart 1 månad sedan har inget gjorts åt detta utan de lever i sin falska trygghet tack vare deras okunskap.

Säkerhet under all kritik

Portalen som har utvecklats av konsultbolaget Know IT som åtminstone inte jag hade velat anlita till något uppdrag inom webbutveckling. Så vad är det nu som är galet?

Vid inloggningen anger du ditt personnummer och lösenord och klickar på "Logga in". (Tack vare att ASP.net bara tillåter ett formulär ?) har Know IT kommit på den bra ideen att de på den mottagande sidan kollar vilken knapp man tryckte på, tex om det var sökrutan eller logga in på hyresgästportalen. Där görs sedan en 302 redirect till http://hemmahos.familjebostader.goteborg.se/signon/?username=xxx&password=yyy, skitsmart eftersom detta nu lagras detta i webbläsarens historik. Den bättre fullösningen hade givetvis varit att göra en post istället.

Här visas både personnummer och lösenord på alla som loggat in från denna dator.

Vem som helst kan alltså bara börja skriva in webbadressen och får sedan upp en lista på alla som loggat in på datorn, inte alls bra att logga in på offentliga datorer med andra ord. Folk har dessutom en tendens att använda samma lösenord på fler webbsidor, vilket givetvis ni läsare inte gör?

Sessionen på portalen verkar de dock ha satt till 15 minuter, åtminstone om man ska grunda det på texten i deras dokument om portalen.

Varför loggas man ut efter 15 minuter?
Utloggningen görs av säkerhetsskäl, för att en obehörig inte ska kunna använda HemmaHos med någon annans användaruppgifter.

En första sak som tyder på att de ens haft säkerhet i åtanke.

Eftersom man endast fick fram personnummer och lösenord på folk som loggat in på den dator man är vid kan man tycka att man sitter halvsäkert i båten. Vid en fortsatt koll på flödet görs ännu fler 302 redirect varav den sista går till http://hemmahos.familjebostader.goteborg.se/signon?loginresult=xxx (xxx är alltså användarnamnet, eller rättare sagt hyresgästens personnummer.) Efter alla, i min värld, stora säkerhetsrisker vågade jag knappt testa om de var så korkade att det räckte att besöka den sista webbsidan för att loggas in. Sagt och gjort så skickar jag länken till en kompis och han blir inloggad som mig.

Vem som helst kan alltså logga in genom att endast ange personnumret på personen man vill logga in som. Smidig lösning, det tackar jag och övriga 18 000 hyresgäster för.

De två sista sakerna jag ska klaga på när det gäller säkerhet är att man bör använda kryptering, skaffa ett SSL certifikat så skickas allt åtminstone inte i klartext över Internet och sist men inte minst: lagra inte lösenord i klartext. Eftersom man kan beställa lösenordet till sin e-post och man får det gamla man hade kan de omöjligen ha lagrat mitt lösenord hashat vilket är god praxis hos alla andra företag.

Beställaren kan inget om webb

Det är helt uppenbart att de från Familjebostäder som beställde uppdraget inte har koll på Internet och hur webbsidor är tänkt att fungera. Hela portalen är gjord i Silverligt, detta eftersom reklambyrån som stod för framtagande av design skapade en som inte var anpassad till webbsidor. Citerar ur konversation med Familjebostäder:

För två år sedan fick vi ett förslag från en välrenommerad reklambyrå  ;-) i stan med de visuella lösningar (dra och släpp, flytta runt sömlöst, formulär som kommer ut ur gadgetar etc) som vi nu använder. Vår konsult gav oss två alternativ för bygget av de dynamiska delarna: Java och Silverlight

Att man kan göra lull-lull med Silverlight kan jag förstå, men hur Java löser problemet mer än ASP.NET, PHP osv förstår jag inte, någon annan kanske har detta svar. Javascript kan jag köpa, men vem vill ha Javascript och AJAX-lösningar när man kan ha Silverlight.

Jag frågade Familjebostäder om man ens tänkt på konsekvenserna det får att inte använda vanliga webbstandarder, att Silverlight inte finns till alla operativsystem, att synskadade inte kan använda sina program som baseras på texten.

Inte speciellt många har hört av sig angående problem med att logga in eller att få fram sidan beroende på problem med Silverlight.

Ett svar som egentligen inte säger så mycket mer än att de uppenbarligen haft samtal från folk som ej kunnat använda deras portal.

Påpekade även problemet att när man klickade på en länk som ska öppnas i ett nytt fönster fastnar det hos Firefox, något som beror på att man kodat felaktigt och tillika detta fick jag ett underhållande svar.

Pop-up-blockering i Firefox är en installningsfråga i din webbläsare. Enkelt att fixa själv.

Jag som är van användare av Internet och dessutom jobbar som webbutvecklare vet hur jag gör detta, men det är bara fel att be alla användare att ändra deras inställningar.

När jag testade portalen först fungerade heller inte vissa funktioner såsom att skapa serviceanmälan i Firefox, något som dock gick bra i internet Explorer, på grund av alla fel som upplevdes kan de knappt ha testat sidan själva i andra webbläsare än Internet Explorer. Nu fungerar dock sidan bra även i Firefox, tummen upp.

Avslutningsvis vill jag bjuda på ännu en sak jag fick av Familjebostäder när de skulle felsöka varför min serviceanmälan på portalen inte ville sparas när jag använde Firefox.

Om du kan tänka dig att skicka p-nr och lösenord ska jag titta på detta ihop med vår ärendehanteringsguru.

• Komprimera med Gzip
  Genom att komprimera webbsidan innan den skickat till klienten överförs mindre data, klienten packar sedan upp allt innan det visas i webbläsaren. Om sidan använder PHP kan man övers på sidorna lägga in följande kod:
  <?php if(!ob_start("ob_gzhandler"))ob_start(); ?>
• Kombinera filer
  Genom att kombinera många mindre filer till en större blir det mindre anrop som behöver göras och därför även mindre data.
  Exempel på saker är att kombinera bilder med sprites, lägga ihop JavaScript i färre filer.
• Minimera DNS-uppslagningar
  Varje ny domän/subdomän slås upp med DNS, genom att inte missbruka antal externa uppslagningar spar man tid. Bra tips på större webbplatser är att lagra statiska filer såsom bilder, js-kod och css på en egen subdomän som har en optimerad webbserver för filöverföring och inget annat. Loopia erbjuder exempelvis Autobahn, se specifikt för WordPress.
• Minska filernas storlek
  Komprimera bilder, CSS och JavaScript kan krympas i storlek genom att använda speciella program, t.ex. YUI Compressor eller minify,  som tar bort onödiga tecken.

För de flesta som inte har alltför djup teknisk kompetens kommer man långt genom att

• minimera antal filer som laddas in
• komprimera bilder, js och css
• ange höjd och bredd på alla bilder så kan webbläsaren rendera sidan i förväg
• läs in filer från ett begränsat antal domäner/subdomäner
• om du har wordpress utnyttja plugins som cachar (skapar statiska filer, så övriga ovanstående punkter är bra kika på ändå)

Relaterade verktyg

• Firefox med Firebug och t.ex.
  • Yslow
  • Google page speed