Varje år firas dagen den 9:e April, och WordPress Gurun är med för andra året i rad. Var med du också!

Jag skriv ihop ett litet filter som gör att inga WordPress css:er laddas:

function wpguru_strip_styles() {
    return "";
}
add_filter( 'style_loader_src', 'wpguru_strip_styles' );

Lägg till koden i din functions.php så tas all style bort från tillägg och annat. Filen hittar du om du går in i Administrationspanelen och väljer ”Utseende > Redigerare”.

Dessutom måste du gå in i header.php som du hittar om du hittar på samma ställe som functions.php. Här letar du upp en rad som ser ut ungefär så här:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />

Kommentera ut raden genom att ersätta den mot följande:

<!--<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />-->

Så, spara(!) och all din style ska nu vara helt borta från din hemsida.

Ha detta igång under hela dagen, för att vara med och fira Naked CSS Day 2011.

För det första har W3Schools inge koppling till World Wide Web Consortium (W3C), den internationella communityn som skapar webbstandarder på internet. W3C har flera gånger bett W3Schools att påpeka detta på deras hemsida för att inte skapa förvirring, men de vägrar.

Fortsättningsvis delar de ut certifieringar, som ingen varken känner igen eller värderar. Till skillnad från Microsoft’s MCP och Cisco’s CCC har W3Schools ingen kontroll över sakerna de påstår certifiera.

Slutligen fortsätter de att frekvent publicera felaktig och missvisande texter och exempel på sin sida, utan att tillåta folk att rätta till det.

Problemet med detta är att folk lär sig inkorrekt, och ökar felaktig kodning på internet vilket snarare är bakåtsträvande än motsatsen.

Ett fyrtio tal kända namn i internetvärlden har fått nog av W3Schools felaktigheter och har skapat ett dokument för att påvisa varför man inte ska använda W3Schools som referenskälla. Dokumentet hittas på W3Fools och det är också därifrån min information till den här artikeln kommer ifrån.

På sidan W3Fools påvisas en mängd fel som W3Schools har på sin site, och trots att de inte fått någon direkt kontakt med W3Schools så har flertalet av punkterna faktiskt förbättrats efter publiceringen. Men fortfarande är hemsidan full av felaktigheter.

Var ska man hitta sin information istället

Jag skriver detta inlägg för att följa upp kampen om att leda människor till andra källor, när de letar efter sina svar. W3Fools själva rekommenderar följande:

• Html Dog som ger en bra och komplett introduktion till HTML och CSS.
• Opera Web Standards Curriculum som täcker basen av webbstandardbaserad webbutveckling i HTML och CSS.
• Google’s HTML, CSS, and Javascript from the Ground Up presenterar grunläggande webbutveckling med hjälp av videotutorials med hjälp av Google experter på webbutveckling.
• SitePoint är enligt W3Fools en helt okej dokumentation till HTML, CSS och JavaScript där de påpekar framtida webbläsarstöd och beskriver kända webbläsarbuggar.
• W3C, själva, har en wiki-baserad allmän Utbildningssida förutom deras dokumentation av HTML-element.
• The MDC (Mozilla’s Doc Center) erövrar scenen för den mer avancerade CSSen och dokumenterar JavaScript bättre än någon annan.

W3Fools tipsar också om att i dina framtida Google sökningar lägga till -w3schools för att slippa deras sökresultat och istället starta sökningen med MDC för att få resultat från Mozilla’s Doc Center.

Så hjälp till även nu att sprida informationen om att W3Schools är en dålig källa för säker information. Glöm inte också att läsa dokumentet W3Fools för att få all information om saken.

Nu ska jag gå igenom mina gamla inlägg och ändra länkningar till W3School, för jag tänker inte hänvisa till dem i fortsättningen.

Skillnaden mellan Post Format och Custom Post Types

Sedan version, jag tror att det var 2.9 alternativt 3.0 har det funnits någonting som heter Custom Post Types, eller något i stil med ”valbara inläggstyper”. Detta är ett väldigt dåligt val av ord, som Mark Jaquith poängterar i ett inlägg, då det egentligen borde ha hetat någonting i stil med valbara innehållstyper, då dessa syftar på typen av innehåll inte på olika sorters inlägg.

Olika typer av innehåll skulle kunna vara Författare, Meny element eller Produkter, medan olika typer av inlägg skulle kunna vara Galleri, Länk, Chat eller Video.

Varför använda inläggstyper

Anledningen till att vilja sortera sina inlägg i olika grupper kan vara flera, men oftast så vill man att de ska presenteras på olika sätt på framsidan. Ett galleriinlägg vill man kanske ska visa en bild. En länk ska kanske låta titeln vara den externa länken och en aside (likt ett Twitter inlägg) kanske inte ska ha någon titel.

Matt har länge använt sig av detta och på bilden ovan kan vi se ett aside-inlägg (utan titel) och ett galleri-inlägg (med en bild).

Tidigare har det inte funnits någon standard för att lösa detta i WordPress, utan man har fått utnyttja kategorier, och sen beroende på ifall ett inlägg har en viss kategori visa den på ett visst sätt. Och visst det fungerar ju bra, tills du väljer att byta tema, och ingenting längre visas som det ska. Dessutom måste du som temaskapare utbilda användaren av temat om hur personen ska göra för att få saker att visas på vissa sätt.

Ange stöd till dina inläggsformat

Nu har äntligen lösningen kommit, Post Formats.

Man implementerar det lätt i function.php:

add_theme_support( 'post-formats', array( 'aside', 'gallery' ) );

och just like that så finns de att välja under publicerings boxen när du skriver ett inlägg. Temat TwentyTen har självklart blivit uppdaterad med detta redan.

Enligt Codex kan man se att man kan ange stöd för följande inläggstyper:

Använd dig av inläggsformaten

När en inläggstyp är satt på ett inlägg händer egentligen inte så mycket per automatik, men du som tema skapare har möjlighet att göra en hel del.

Först och främst dyker formatet nu mera upp som en extra klass med hjälp av funktionen post_class(), som bör vara satt på alla inlägg. Dessa visar i sig i formen format-<typen> så ett inlägg som skulle vara av typen galleri skulle få klassen format-gallery. Dessa kan du sedan använda till att styla med i din css:

.format-link h1{
    color: #900000;
}

Fortsättningsvis finns det en ny funktion som heter get_post_format() som du kan använda för att ta reda på inläggets typ i loopen. Men hjälp av den kunskapen kan du sedan skapa olika utskrifter i loopen beroende på vilken typ av inlägg man har specificerat inlägget som (pseudo-kod):

while( the_loop() ) :
    $format = get_post_format();
    if( $format == 'link' ) :

        //Gör saker om det är en länk
    elseif( $format == 'galleri' ) :
        //Gör saker som ett galleri borde vilja

    else :
        //Annars gör så här (standard)
    endif;
endwhile;

Om ett format inte skulle vara satt, eller om man sätter ett format som inte är giltigt så kommer inlägget automatiskt att få typen ”standard”.

Template filer med hjälp av post_format()

Om man vill stödja alla olika typer av inlägg kan din villkorssats bli väldigt lång, med väldigt mycket liknande kod, vilket kommer göra det rörigt ifall du skulle vilja ändra någonstans. Doglas Gunter hittade på en riktigt bra lösning där man med hjälp av funktionen get_template_part(), som låter dig hämta en fil som börjar med någonting, och slutar med någonting annat, bryta ut de olika typernas kod till separata templatefiler.

Koden ser ut så här:

while( the_loop() ) :

    get_template_part( 'format', get_post_format() );
endwhile;

Det den gör är att hämta innehållet i en fil som börjar med format och slutar med namnet på ditt format. Ett inlägg av typen galleri skulle alltså använda filen format-gallery.php. Fördelarna med det här sättet är att (1) du får mindre kod i din index fil, (2) du får lättöverskådliga templatefiler och (3) det är perfekt för child teman, eftersom ifall format-gallery.php inte kan hittas, så letar den efter samma fil i ett alternativt parent tema, skulle den fortfarande inte hittas, faller den tillbaka på filen format.php, och skulle inte den finnas i barn temat så letar den slutligen efter format.php i förälder temat. Tack vare detta kan man enkelt skriva över en viss templatefil i ett barntema utan att förstöra hur någonting annat ser ut. Och skulle ett temat inte göra någonting speciellt med en viss typ av inlägg, så faller den enkelt tillbaka till standard filen, format.php (den måste dock finnas för att det ska fungera).

Betatesta funktionen

Eftersom funktionen fortfarande bara är i betaversion, så går den inte att använda på din vanliga WordPress installation, men om du ändå vill leka med kontrollerna så kan du alltid följa min guide om hur du blir en beta testare, så är det bara att sätta igång och testa och uppgradera ditt tema så att det är fit for fight när version 3.1 äntligen kommer.

Men vad gör du ifall just ditt typsnitt inte existerade i den listan. Och som grafisk designer kan du inte ha det på något annat vis än att använda just ditt specialdesignade typsnitt. Bilder är inget alternativ, så vad gör du då?

Med css definitionen @font-face är det möjligt. @font-face låter dig definiera en egen font-familj och låta besökaren ladda ner det aktuella typsnittet och sedan visa din hemsida precis som du vill ha den. Funktionen är egentligen en CSS2 definition, men då var det bara Internet Explorer som stödde den, och då endast med specialformatet .eot (vilket för övrigt fortfarande är det ända IE stödjer). Nu när CSS3 och HTML5 gör intåg stödjer alla stora webbläsare @font-face till en viss grad, och med lite special kodning och alternativa typsnitt att falla tillbaka på kan vi visa hemsidan precis som vi vill ha den utan att oroa oss för att gamla webbläsare och uråldriga användare inte ska kunna hänga med.

Bulletproof smily version av @font-face

Koden som rekommenderas att använda för @font-face och som framförallt är framarbetad av Paul Irish ser ut som följer:

1
2
3
4
5
6

@font-face {
  font-family: 'WpGuru Familjen';
  src: url('WpGuruFamiljen.eot?') format('eot'),
       url('WpGuruFamiljen.woff') format('woff'),
       url('WpGuruFamiljen.ttf') format('truetype');
}

Koden ovanför gör så att jag kan använda mig av font-familjen ‘WpGuru Familjen’ i min style.css, där konden ovan också för övrigt ska in. Anledning till att den är på så många rader är för att alla webbläsare ska förstå, framförallt IE. Genom koden ocan kan man lura de olika webbläsarna så att till och med ie6 kan förstå. Om du vill veta exakt varför läs gärna Paul Irish inlägg om saken

Första raden @font-face talar om att här börjar en definition om en ny font. Andra raden specificerar namnet på fonten. Det är detta namnet man ska skriva ifall man sedan vill använda fonten.

Tredje raden är till för Internet Explorer som bara förstår .eot filer, och detta är alltså platsen på hårddisken relativt till stylesheet filen där fint typsnittsfil ligger.

Rad 4-7 är till för alla andra webbläsare. Rad 4 säger att ifall besökaren redan har ett typsnitt installerat på datorn som heter samma sak som står mellan local, så ska man använda detta typsnitt, vilket kan vara bra, för att besökaren ska slippa ladda ner din fil, men ifall besökaren råkar ha fel typsnitt med samma namn installerat, så kommer alltsammans se fel ut, så därför testar man och ser ifall användaren har ett typsnitt som heter (smily), för att den alltid ska misslyckas. Varför då inte helt strunta i det, frågar du dig? För att IE inte förstår vad local betyder, och kommer att hoppa över den raden. Skulle man IE lasa vidare, skulle IE ladda ner även nästkommande typsnittsfiler trots att IE inte förstår sig på dessa typsnitt, vilket bara skapar massa jobbigheter. Så detta är den bästa lösningen (läs mer på Paul Irish sidan specificerad ovan).

Vidare på rad 5-7 sedan när IE är ur vägen, specificeras olika typer av din font, för olika typer av webbläsare. WOFF är ett litet och snabbt format som stödjs av FF3.6+, true-type stödjs av de flesta och är special designat för att visas bra på webben. Svg tillslut är xml format som södjs av ett fåtal webbläsare men framförallt av iPhone och iPad.

Tillslut på rad 8-10 tar vi bort några buggar i webkit läsare genom att specificera alla stil varianter till normala. Så får vi inga dumma kraschar på grund av detta. Läs gärna mer om detta här.

Förut var det The Bulletproof smily syntax som gällde, men skaparen till Font Squirrel har lyckats komma på en smart metod som ersätter den och genom de få raderna ovan lyckats göra så att till och med ie6 kan få special designade fonts. Genom att lägga till information om 3 stycken fonts, kan man erbjuda det bästa typsnittet för varje webbläsare. eot filen till Internet Explorer mindre än 9, woff filen till alla moderna webbläsare, och slutligen ttf-filen till Safari, Android, iOS.

Den här metoden heter ”The Fontspring @font-face syntax” och Font Spring har skrivit ett bra inlägg om precis vad som händer i syntaxen.

Generera dina typsnitt

-Men, tänker ni, så många filer av ett och samma typsnitt har inte jag!

Så hur får du tag i typsnitten i alla de där formaten som beskrevs ovan?

Lugn, som tur är finns det smidiga och bra verktyg på internet, där det bästa är skapat av Font Squirrel.

Här kan du ladda upp dina normala .ttf filer som du till exempel kan hitta i din dators font mapp eller lite varstans på internet. Och sedan ser generatorn till att skapa filerna du behöver. Tänk vad lätt det kan vara ibland.

Hur du sedan använder dina familjer

Ok, koden är redo, filerna är redo. Hur får du nu din text att formad som du vill ha den? Enkelt, precis som du skulle vilken annan font som helst.

p{

   font-family: WpGuru, 'WpGuru Familjen', verdana, helvetica, arial, sans-serif;

}

Nu kommer den att använda WpGuru fonten som allting går som det ska, och ifall den inte hittar typsnittet trots alla våra koder och filer (och under de få sekunder innan webbläsaren har hunnit ladda ner och installera typsnittet), så kommer den att falla tillbaka på verdana i första hand, helvetica i andra hand och så vidare.

Så nu kan du styla din hemsida precis så som du vill ha den, med de coolaste typsnitten du kan då tag i, få det att fungera i alla webbläsare och skulle det mot förmodan ändå gå åt pipan, så har du lösningen för det också.

Poängen är att din typografi är viktig. Tyvärr kan vi inte använda vilka fonts som helst på webben, då det gäller att alla webbläsare ska kunna förstå hur vi vill ha vår text. Så vad har vi för alternativ?

För det första kan vi göra bilder av alla text, så får vi allt att se ut precis som vi vill ha det, eller så använder vi den relativt nya css definitionen @font-face som du kan läsa mer om i artikeln Strunta i webbsäkra font-familjer och låt @font-face skapa typografisk magi, eller slutligen så använder du webbsäkra font-familjer som fungerar i alla webbläsare.

Special fonts som bilder

Alternativet att använda bilder för statiska texter (loggor, överskrifter, menyer) är i mitt tycke endast ett alternativ vid ett specifikt tillfälle, och det är till din logga, och då endast så länge du har ditt namn skrivet någon annanstans eller på något annat sätt med klar text. Varför? Anledning är att Google inte kan läsa bilder (än). För att Google och andra sökmotorer ska förstå vad som händer på din hemsida, kunna orientera sig och kunna sända relevant trafik åt ditt håll, så måste Google kunna läsa dina texter. Det kan de inte ifall du har valt att göra bilder av all text.

Jag rekommenderar därför emot att använda enbart bilder till menyer och överskrifter. En logga är som sagt okej eftersom detta är en logotyp som ska skilja sig från övrig text och ofta är något slags motiv, eller väldigt specifik text, som ska se ut på ett speciellt sätt.

För att Google ändå ska kunna läsa din hemsidas namn är då istället det bästa alternativet att skriva namnet i en div som du absolutpositionerar -9999px till vänster eller något liknande, så att en vanlig användare inte ser den dubbla texten.

.logo-text{
    position: absolute;

    left: -9999px;
}

Websafe font-families

Det andra alternativet är att välja fonts som du vet fungerar på de flesta webbläsarna och då försäkra dig om att din text är läsbar på samma sätt överallt. Detta gör du genom att specificera font-family i din css, och som värde anger du en komma separerad lista med typsnitt som du föredrar. Skulle din webbläsare trots allt inte kunna hitta ditt typsnitt först i listan, kommer den att använda den andra, och så vidare.

Här kommer en lista på alla webbsäkra typsnitt du kan använda dig av, med för det mesta en liknande fallback font och alltid en så kallad Generic font Family (serif, sans-serif, cursive, monospace) som definitivt existerar i varenda webbläsare där ute.

För en lista på alla fonts, säkra eller inte ta en titt på den här sidan: font Tester – All Fonts Preview

Vad vi vill åstadkomma

För att ge våra arkivbesökande besökare så bred valmöjlighet som möjligt vill vi erbjuda dem möjligheten att se en lista på inlägg i månadsordning, kategoriordning och sen bara en lista på alla inlägg rakt av, men uppdelade i månad och år för att göra det hela lite mer läsligt.

Detta gör vi lättast i tre olika steg, med tre olika funktioner en för varje visning, där WordPress själva erbjuder oss mer eller mindre färdiga funktioner för jobbet.

Arkiv månadsvis

För att få en lista per månad, så använder vi oss av funktionen wp_get_archives() som vi har möjlighet att skicka in lite parametrar till:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?php 
 
//Standardvärden
$args = array(
    'type'            => 'monthly',
    'limit'           => ,
    'format'          => 'html', 
    'before'          => ,
    'after'           => ,
    'show_post_count' => false,
    'echo'            => 1 );
 
wp_get_archives( $args );
 
 ?>

type är hur du vill att arkiv listan ska visas, yearly, monthly, daily, weekly, postbypost, alpha.
Postbypost listar inläggen en efter en i datumordning medan alpha gör samma sak, men listar dem i bokstavsordning efter titeln.
limit är antalet arkivrader du vill visa totalt. Som standard visas alla rader.
format är hur listan ska genereras. html för att visa den som en vanlig lista med <li>’s. option för att göra valen till en rullgardinslista eller selectbox. link för att omsluta raderna med <link>-taggar att ha i headern. Eller slutligen custom där du kan använda before och after för att skapa din egna lista.
before är således en stäng att placera före varje länk till arkivraderna och
after är en stäng att placera efter varje länk till arkivraderna.
show_post_count är en boolean som talar om ifall man vill att en siffra med antalet inlägg som visas efter varje länk eller inte.
echo, och slutligen echo som också är en boolean och talar om ifall man vill att listan ska skrivas ut direkt eller inte.

Så för genom att skriva följande kod så får vi resultatet som är på min arkiv sida:

1
2
3

<ul class="archives">
    <?php wp_get_archives('type=monthly&show_post_count=1'); ?>
</ul>

Arkiv per kategori

För att åstadkomma ett arkiv per kategori så kan vi använda oss av en mycket lik funktion som heter wp_list_categories() och listar just kategorier. Även den har en del parametrar:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?php 
 
//Standardvärden
$args = array(
    'show_option_all'    => ,
    'orderby'            => 'name',
    'order'              => 'ASC',
    'show_last_update'   => 0,
    'style'              => 'list',
    'show_count'         => 0,
    'hide_empty'         => 1,
    'use_desc_for_title' => 1,
    'child_of'           => 0,
    'feed'               => ,
    'feed_type'          => ,
    'feed_image'         => ,
    'exclude'            => ,
    'exclude_tree'       => ,
    'include'            => ,
    'hierarchical'       => true,
    'title_li'           => __( 'Categories' ),
    'number'             => NULL,
    'echo'               => 1,
    'depth'              => 0,
    'current_category'   => 0,
    'pad_counts'         => 0,
    'taxonomy'           => 'category',
    'walker'             => 'Walker_Category' );
 
wp_list_categories( $args );
 
 ?>

show_option_all, om detta värde sätts till en sträng, så kommer en länk att skapas till en ”visa alla kategorier”-sida, vilken vanligtvis är eran startsida.
orderby talar om hur listan ska sorteras: ID, name, slug, count eller term_group
order är ASC (stigande) eller DESC (fallande).
show_last_update är en boolean för ifall en datum stämpel med senaste inläggets datum ska visas vid varje kategori.
style kan ha värdena list eller none. List ringar in listan med <li>-taggar, medan none endast sätter <br /> efter varje kategori.
show_count är en boolean som talar om ifall antalet ska visas efter varje kategori.
hide_empty är en boolean som talar om ifall tomma kategorier ska dyka upp i listan eller inte.
use_desc_for_title är en boolean för att tala om ifall kategorins beskrivning ska dyka upp som titel på länken eller inte.
child_of genom att ange en kategori här, så kan man få endast kategorier som är barn till den kategorin att dyka upp i listan.
feed är en boolean för att slå på och visa en rss feed för varje kategori.
feed_type är typen av feed och
feed_image sätter en uri-address till en bild att använda som feed-ikon.
exclude är en lista på kategori-idn som ska uteslutas ut listan
exclude_tree kan exkludera hela kategoriträd.
include är en lista på kategorier som endast ska visas (och exkluderar alltså alla andra).
hierarchical huruvuda listan ska vara hierarkisk eller inte.
title_li är en sträng som blir listans titel.
number är ett nummer för hur många kategorier som ska visas i listan.
echo är huruvuda listan ska skrivas ut eller sättas till en variabel. Standard är alla.
depth sätts till hur många nivåer som ska visas i listan. Standard är alla.
current_category kan tvinga klassen ”current category” att bli satt på kategorin man är på, även om man inte befinner sig på en arkiv sida (tex om denna lista visas när man är inne på ett inlägg).
pad_counts talar om ifall man vill att parent kategoriers antal ska räknas ihop med alla inlägg som är i barnens kategorier.
taxonomy kan bli satt från version 3.0 och framåt och talar om vilken typ av kategorier man vill lista.
walker tillslut talar om vilken funktion man vill använda för att generera listan (avancerat).

Så, det var en lång lista. För att generera listan som är på min arkivsida så behöver vi således skriva följande kod:

1
2
3

<ul class="archives">
    <?php wp_list_categories('sort_column=name&show_count=1&title_li=') ?>
</ul>

Lista alla inlägg

För att lista alla inlägg blir det lite mer komplicerat om man vill ha det som jag har gjort det. Ska skriver hela koden först så kan vi gå igenom den efteråt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

<h2>Alla Artiklar:</h2>
<ul class="archives">
<?php
    $lastposts = get_posts('numberposts=-1');
    $year = '';
    $month = '';
    foreach($lastposts as $post) :
        setup_postdata($post);
 
        if(ucfirst(get_the_time('F')) != $month && $month != ''){
            echo '</ul></li>';
        }
        if(get_the_time('Y') != $year && $year != ''){
            echo '</ul></li>';
        }
        if(get_the_time('Y') != $year){
            $year = get_the_time('Y');
            echo '<li><h3>' . $year . '</h3><ul>';
        }
        if(ucfirst(get_the_time('F')) != $month){
            $month = ucfirst(get_the_time('F'));
            echo '<li><h4>' . $month . '</h4><ul>';
        }
?>
<li>
    <span class="pink"><?php the_time('d') ?>:</span>
    <a href="<?php the_permalink(); ?>">
<?php 
    if (  (function_exists('has_post_thumbnail')) && (has_post_thumbnail())  ) {
        the_post_thumbnail('rel_thumb', array('alt' => '', 'title' => ''));
    } 
    the_title();
?>
    </a>
</li>
<?php endforeach; ?>
</ul>

Rad 1 skriver ut titeln på vår lista, medan rad 2 startar listan.
På rad 4 hämtar vi alla inlägg med funktionen get_posts(‘numberposts=-1′); där värdet vi anger som -1 betyder att vi inte vill ha någon maxgräns på hur många inlägg vi hämtar. Vi kan sätta 100 tex för att begränsa oss till endast 100 inlägg. Inläggen placerar vi i variabeln $lastposts.
På rad 7 start vi en loop som kommer att gå igenom hela listan av inlägg och placera vart och ett i variabeln $post.
Rad 8 är viktig, då den kör funktionen setup_postdata($post); vilket gör att wordpress sätter inlägget som det aktiva inlägget, vilket gör att vi kan använda fuktioner som get_title() tex för att få titeln på inlägget.
Raderna 10-22 gör några villkorssatser för att undersöka ifall månaden och året är samma som inlägget innan, ifall det inte är det, vill vi avsluta en lista, och starta en ny, så att vi kan få alla inläggen uppdelade efter år och månad.
Rad 24-26 skriver ut själva inläggets <li>-tagg plus datumet inlägget var skrivet följt av starten av en länk till inlägget. Här används funktionen the_permalink() för att få länken till inlägget.
På rad 28-30 undersöker vi om inlägget har en visningsbild med funktionen has_post_thumbnail, och ifall den har det vill vi skriva ut tumnageln med storleken som jag har definierat i min funktion.php klass till ‘rel_thumb’. För mer information om bildernas tumnaglar läst gärna mitt inlägg Allt du behöver veta om WordPress tumnaglar.
Tillslut på rad 31 skriver vi ut titeln på inlägget och resterande rader avslutar bara vad vi tidigare har öppnat.

Så genom att skriva koden ovan så får ni en snygg lista med alla inlägg sorterade i datumordning och grupperade per år och månad. Sen är det bara att gå in style.css och fixa till visningen lite, så att allting visas på ett snyggt och harmoniskt vis.

Avslutning

Och där har ni det. Nu har ni allt ni behöver för att kunna göra en riktigt snygg arkivsida. Koden placerar ni i en fil som ni döper till archives.php och sedan placerar i er tema mapp. Filen kommer då sedan automatiskt att gå att hitta i rullgardinslistan för sidmallar nere till höger när ni sedan skapar en ny sida, och genom att välja den, kommer er sida att visas upp som en arkivsida. Lycka till, och skriv gärna en kommentar om ni får problem eller bara för att berätta hur er arkivsida blev.

Den här guiden kommer att gå igenom ett alternativ till ovan exempel, nämligen Child themes, eller barn teman, vilket möjliggör till redigering utan att egentligen redigera några av grundtemats filer, vilket gör att du säkert kan redigera, och uppdatera ditt tema, utan att vara rädd för att förlora någon information vid ett senare tillfälle.

Child Themes

Ett vanligt tema kräver som ett absolut minimum en stilmall som heter style.css, som innehåller minst en kommentar högst upp med namnet på temat, och en php-fil som är döpt till index.php för att kunna generera alla sidor med.

Ett Child tema, är ett barn till ett vanligt tema. Ett sådant tema behöver som minimum endast en stilmall som heter style.css och innehar minst en kommentar högst upp som definierar child temats namn och viket tema som är dess parent, alltså ”pappan”.

Genom att specificera en förälder i ett temas stilmall, använder WordPress förälder temat som en template, en grundstomme för hur temat ska genereras, så att ifall en specifik fil inte hittas i ditt nyskapade child tema, så låtar den istället efter filen i förälder mappen.

Detta betyder att om vi till exempel har temat TwentyTen och vill göra ett child tema till det så skapar vi en ny mapp i temamappen, skapar en fil, som vi döper till style.css och skriver en kommentar om att vi vill använda TwentyTen som parent theme.

Om vi nu kör vårat nyskapade tema kommer inte WordPress hitta några av filerna om hur den ska bygga upp våran hemsida i vårat eget thema, och kommer därför att plocka samtliga teman från TwentyTen, och vår hemsida kommer se likadan ut, som om vi hade valt att ha temat TwentyTen istället.

Nästan!

Om ni mins så kommer WordPress hitta en fil i vårat barn tema, nämligen style.css. Och kommer således att använda den för att generera färger, marginaler, textstorlekar och allt annat sådant. Men eftersom våran style.css är helt tom förutom en kommentar om TwentyTen och namnet på vårt tema, så kommer ingenting att stylas på något sätt, och hemsidan kommer att helt naken och tråkig.

Men frukta ej käre läsaer. Vidare i den här guiden ska jag gå igenom exakt hur du ska göra för kunna ändra bara precis på en liten text storlek och få allting annat att se exakt likadant ut som det gjorde innan.

Skapa ett eget Child Tema

Om du använder en ftp klient, till exempel FileZilla, och där i din grundmapp (den där du hittar filen wp-config.php) lokaliserar wp-content/themes/ så har du tagit dig till tema mappen i WordPress. Här hittar du mappar med namn som classic, default och tewntyten. Memorera exakt hur namnet är skrivit på det temat du vill ha som förälder tema, om det har stora eller små bokstäver och ifall det använder mellanrum eller understräck. I den här guiden kommer vi använda oss av temat TwentyTen där mappen heter exakt twentyten.

När du känner till den informationen skapar du sedan en ny mapp, antingen direkt i WordPress tema mapp (themes) eller lokalt på din dator för att sedan ladda upp med FileZilla eller liknande senare.

Mappen döper du till vad du vill, men för enkelhetens skull använd namnet du vill ha på ditt child tema, men ersätt mellanrum med understräck och skriv bara med små bokstäver (Detta är inget måste, men det blir snyggast på det viset, då alla gör detta som standard). I det här exemplet kommer vi utgå från att vi bygger ett barn tema till standard temat TwentyTen och vi kommer att döpa vårat tema till WpGuru TjugoTio. Så jag skapar först en mapp som jag döper till wpguru_tjugotio.

Gå sedan in i mappen och skapa en ny fil som du döper till style.css.

Öpnna din nyskapade style.css och skriv följande saker:

1
2
3
4
5
6
7
8
9

/*
Theme Name: WpGuru TjugoTio
Theme URI: http://www.wordpressguru.se/
Description: Barntema till TwentyTen 
Author: WordPressGuru
Author URI: http://www.wordpressguru.se/
Template: twentyten
Version: 1.0
*/

Du behöver inte ha alla de här raderna om du inte vill. Det ända du egentligen behöver är ”Theme Name” och ”Template” ifall du vill ha en barntema. Men det är alltid trevligare med mer information.
Theme Name är temats namn. Det som kommer att dyka upp som namn när man väljer ditt tema i Administrationpanelen.
Theme URI är temats hemaddress. Detta bör vara en länk till vart man kan ladda ner temat ifall du vill publicera det.
Description är en beskrivning till temat. Det som kommer att dyka upp under temats namn i Administrationpanelen.
Author är temats skapare.
Author URI är en adress till skaparens hemsida.
Template är viktigt och det är mappnamnet till det tema du vill använda som förälder tema. Mappnamnet måste skrivas exakt så som det är skrivet.
Version är temats version. Detta är bra att ha om du publicerar ditt tema och vill att folk ska kunna uppdatera det när du uppdaterar ditt tema.
Vidare finns det några till saker man kan skriva som Tags för att folk ska veta vad det är för typ av tema bland annat.

Om du nu sparar filen och laddar upp allting i din tema mapp så har du precis lyckats skapa ditt allra första barntema! Grattis!

Men så roligt ska vi inte ha det, exakt nu. Först ska vi göra en liten detalj till. Strax under ditt kommentarshuvud i style.css skriver du följande rad:

1

@import url("../twentyten/style.css");

Den här raden importerar alla stildeklarationer som finns i TwentyTen’s stilmall och placerar den överst i ditt barns temas stilmall, så att du nu kan skriva över bara de deklarationer du vill ha. Men vi går igenom vad vi har gjort:
@import betyder att vi vill hämta en fil och placera innehållet i den här stilmallen. Sedan deklarerar vi url(””); som ska innehålla adressen till filen vi vill importera. Länken är relativ från filen vi skriver i, vilket betyder att TwentyTen’s stil mall, relativt från våran stilmall ligger först ett mappsteg bakåt, sedan in i mappen twentyten, och sedan filen style.css. När man skriver en relativ länk så betyder en punkt samma mapp, och två punkter en mapp bakåt. Så våran address blir alltså ../twentyten/style.css.

Nu kan du spara. Ladda upp hela mappen. Gå in i Administrationpanelen > Utseende > Teman och hitta ditt nya tema. Aktivera det och du kommer att se att det är exakt likadant som ifall du hade aktiverat temat TwentyTen direkt.

Skriva över stil deklarationer

Nu kommer vi till de roliga bitarna. Nämligen till att skriva över och ändra på se stildeklarationer vi inte gillar, och förändra dem precis som vi själva vill ha dem.

Om två saker deklarerar samma sak i en stylesheet, så är det alltid den sista som tar effekt. Eftersom vi har skrivit @import raden högst upp i våran style.css så kommer allt vi deklarerar att kommer efter de gamla deklarationerna från TwentyTen, och på så sätt är det våra deklarationer som kommer att gälla.

Så hur vet du vad du ska deklarera och skriva över?

För det första krävs det en allmän förståelse av hur stilmallar fungerar. Att man först skriver vad deklarationen ska gälla för. Sedan mellan två måsvingar skriver man nycklar och de värden man vill ska gälla för nyckeln. För att ändra färgen på alla paragrafer till blått text, så kan vi till exempel skriva så här:

p{
    color: blue;
}

Men det lättaste är att öppna TwentyTen’s style.css, kopiera precis den deklaration du vill ändra på, klistra in den i din egen stilmall och sedan ändra värdena till dina egna.

Ändra länkarna

På rad 313 till 322 i wp-content/themes/twentyten/style.css hittar du följande:

a:link {
	color: #0066cc;
}
a:visited {
	color: #743399;
}
a:active,
a:hover {
	color: #ff4b33;
}

Detta beskriver färgerna som en länk ska ha, först om det bara är en vanlig länk, sen om länken är besökt och sist ifall du håller musen, eller precis har klickat på länken.

Kopiera raderna och klista in i din egen style.css och ändra lite på värden eller skriv dit nya deklarationer som du vill ska gälla länkar. Exempelvis så här:

a:link {
    color: #2243e6;
    text-decoration: none;
}
a:visited {
    color: #2243e6;
    text-decoration: none;
}
a:active,
a:hover {
    color: #e11717;
    background-color: #f8dada;
    text-decoration: underline;
}

Dessa länkar kommer att vara blå utan ett sträck under som normalt. Men om du håller musen över dem så kommer de bli röda, med en ljus ljus rosa färg som bakgrund och ett sträck under i samma röda färg som länktexten.

Så nu om du sparar och testar ditt tema igen, så kommer allt att se ut som vanligt, förutom att länkarna är annorlunda. Bra va?!

Ändra texten

Vilken typ av font som ska användas för text deklareras i TwentyTen’s style.css på raderna 109 till 151. Och ser ut så här:

/* =Fonts
-------------------------------------------------------------- */
body,
input,
textarea,
.page-title span,
.pingback a.url {
	font-family: Georgia, "Bitstream Charter", serif;
}
h3#comments-title,
h3#reply-title,
#access .menu,
#access div.menu ul,
#cancel-comment-reply-link,
.form-allowed-tags,
#site-info,
#site-title,
#wp-calendar,
.comment-meta,
.comment-body tr th,
.comment-body thead th,
.entry-content label,
.entry-content tr th,
.entry-content thead th,
.entry-meta,
.entry-title,
.entry-utility,
#respond label,
.navigation,
.page-title,
.pingback p,
.reply,
.widget-title,
.wp-caption-text,
input[type=submit] {
	font-family: "Helvetica Neue", Arial, Helvetica, "Nimbus Sans L", sans-serif;
}
pre {
	font-family: "Courier 10 Pitch", Courier, monospace;
}
code {
	font-family: Monaco, Consolas, "Andale Mono", "DejaVu Sans Mono", monospace;
}

Dessa är ganska klassiska och bra textval, titlar kommer i huvudsak att få typen ”Georgia” vilket är en font med ganska runda former och gör sig bra som överskrifter. I övrigt kommer det mesta andra att få typen ”Helvetica Neue” vilket är en ganska rak och lättläslig font som liknar Arial.

För att ändra någonting här, gör vi det lättast genom att kopiera hela alltihop till vår egen stilmall och lägger till vår egen lista av fonts som vi vill använda, på samma sätt som de har gjort.

Ju längre till vänster i den komma separerade listan en font är, ju högre prioriterad är den att användas. Om webbläsaren inte förstår eller har den angivna fonten så tar den nästa i listan.

Vi kan till exempel skriva.

Verdana, "Helvetica Neue", Arial, Helvetica, "Nimbus Sans L", sans-serif;

För att först och främst använda oss Verdana som font, men om det inte finns, så använder vi oss av samma saker som TwentyTen hade specificerat tidigare.

Functions.php

Filen functions.php är lite speciell, det är nämligen den ända filen som kommer att läsas in både från huvudtemat och barntemat automatiskt. Du behöver alltså inte använda några import funktioner eller liknande utan det räcker med att bara skapa functions.php i din egen tema mapp och sedan skriva de funktioner du vill använda. Tänk bara på att du inte deklarerar en funktion som redan finns, utan hitta på dina egna funktion namn. Det finns dock ett undantag; öppna TwentyTen’s egna function.php fil och leta efter en text som börjar med

Det är en funktion som gör så att TwentyTen bara definierar och skapar en funktion ifall du inte redan har gjort det i en barntema. Det gör att alla funktioner som börjar på det viset kan du skapa upp och skriva över i din egen funktions.php. Se bara till att de returnerar samma saker som orginal funktionen gör, så att ingenting går sönder.

Många andra av TwentyTen’s funktioner kan vi indirekt skriva över, även om det inte texten ovan står före. Vi letar då istället efter en text likt:

add_filter( 'wp_page_menu_args', 'twentyten_page_menu_args' );

Den säger att funktionen twentyten_page_menu_args ska sättas in som en filter funktion när wp_page_menu_args körs. Om vi vill skriva våran egen meny arguments fukntion, så kan vi ta bort TwentyTen’s fukntion från filtret och lägga till vår egen istället:

1
2
3
4
5
6

function min_egen_page_menu_args_funktion()
{
    ...
}
remove_filter( 'wp_page_menu_args', 'twentyten_page_menu_args' );
add_filter( 'wp_page_menu_args', 'min_egen_page_menu_args_funktion' );

Hur vet vi då när det här ska köras eller om det ens körs? Det lättaste och snyggaste är att skapa får egen setup funktion på liknande sätt, och sätta in all kod i den:

1
2
3
4

add_action( 'after_setup_theme', 'mitt_temas_setup' );
function mitt_temas_setup() {
    ...
}

Övriga Filer

Tyvärr finns det inget enkelt sätt att ändra bara en rad i till exempel index.php filen, för om vi skapar en index.php fil så kommer bara den att användas och inte TwentyTen’s alls. Och ifall vi inkluderar deras index.php i våran, så kommer antingen hela deras fil att köras först, och sedan hela våran, eller tvärt om beroende på vart vi inkluderar filen.

Så ifall vi vill ändra någonting i index.php så får vi lov att kopiera hela filen och ändra det vi vill ändra helt enkelt, och hoppas att de inte gör så mycket uppdateringar på den koden, för dem kommer vi inte få tag på.

Ett bättre sätt är dock att ändra sidorna bara för några specifika sidor. Säg att vi tex har en sida som heter länkar. Och vill ha special utseende på just den sidan. Då skapar vi en fil i vårat tema som heter page-lankar.php där biten lankar i filnamnet är det exakta permalänksnamnet på vår sida. Sedan skriver vi precis hur vi vill att sidan genereras i den här filen, och när vi är inne på vår Länkar sida så kommer WordPress att använda våran page-lankar.php sida för genereringen.

Stylesheet_directory och Template_directory

En sista sak som är bra att veta om Child Teman och Parent Teman är php vägen bloginfo(‘template_directory’); och bloginfo(‘stylesheet_directory’);. Om ditt tema är ett vanligt tema utan barn eller föräldrar så kommer båda de här funktionerna att peka på samma plats. Man kommer att få tillbaka en länkadress till temats mapp. Men i fallet av ett barn-förälder förhållande så kommer stylesheet_directory alltid att peka på barnets temamapp eftersom det är barnet som använder style.css filen, och template_directory kommer alltid att peka på förälderns temamapp eftersom det är den som är templeten, eller mallen för temat. Detta kan vara bra att känna till speciellt när man skapar ett tema som är tänkt att kunna användas som föräldertema, då man tex länkar till bilder och ikoner. Om man använder sig av stylesheet_directory och har lite bilder i förälder mappen så kommer allting att gå bra ända tills man skapar barntemat. Plötsligt pekar ju nu nämligen adressen till barnets mapp, och om det inte finns några bilder att hämta därifrån så kommer inga bilder att visas. Samtidigt om man länkar till till exempel en favicon, som är den lilla bilden som visas högst upp i webbläsaren bredvid din adress så kanske man specifikt vill att länken ska användas från barnets mapp och inte från föräldern.

Oavsett vad man vill göra, så är det viktigt att känna till skillnaden.

Sammanfattning och avslutning

Så! Det var allt för den här gången. Nu bör ni veta tillräckligt mycket om child teman för att kunna skapa era egna varianter. Och när en uppdatering kommer av ert förälder tema så är det bara att uppdatera och inte vara rätt att uppdateringen kommer att skriva över några av era ändringar, så dessa är gjorda i ett helt eget tema.

Här är exemple temat vi precis skapade:

Strukturen på en hemsida

Okej, vi börjar med att förklara konceptet ”hemsida”. Moderna hemsidor och framförallt stora ramverk som WordPress, försöker så långt det går att separera presentation från logik, och sedan vidare hålla allting så separat det går för att vi som användare enkelt ska kunna modifiera så mycket som möjligt utan att behöva leta så mycket.

Html

För enkelhetens skull, låt oss likna en hemsida vid en bil. Html koden beskriver hur bilen ska vara uppbyggd. Den säger att hela bilen är en bil, och i den ska det finnas 5 platser, 4 dörrar, en motor, 4 hjul. och så vidare. Allting delas in i element som ringar in andra element. Ett startelement kan se ut så här: <bil>. Alla element måste avslutas, och det görs dem genom att placera ett framåt snedstreck (front slash) i elementet: </bil>. Varje text snutt som är inringat med ”krokodilmunnar” kallas för en tagg och en starttagg och en sluttagg skapar ett element.

Exempel:

<bil>
    <dörr>
        <fönster>
        </fönster>
    </dörr>
    <säte>
    </säte>
    <dörr>
        <fönster>
        </fönster>
    </dörr>
</bil>

För att lättare kunna identifiera de olika elementen så kan vi sätta klasser (class) och id:n (id) på dem. Se klassen som bilmodellen, den kan delas av många bilar som ser likadana ut, och id:t är registreringsnumret, och pekar på precis en specifik bil, och inga fler.

<bil class="wp70" id="abc123">
    <dörr class="vänster">
        <fönster>
        </fönster>
    </dörr>
    <säte>
    </säte>
    <dörr class="höger">
        <fönster>
        </fönster>
    </dörr>
</bil>

CSS

Css:en eller stilmallen, talar om hur din bil ser ut. Allt från längd och bredd till färg och form. När man skriver i sin stil mall så filtrerar man ut vissa element som man vill ange attribut på och talar sedan om hur alla filtrerade element ska se ut. Om vi vill förändra en specifik elementtyp, behöver vi bara skriva namnet på det elementet, utan ”större än”, ”mindre än” tecknen, exempelvis bil. Vill vi filtrera ut element utefter deras klasser så skriver vi en punkt och sedan klass-namnet, exempelvis .vänster. På samma sätt gör vi för att filtrera efter ett visst id, men då använder vi fyrkant, stakettecken, så då blir det #abc123. Vi kan även kombinera flera av dessa med mellanrum ifall det ska vara element i ett annat element och komma ifall det ska inkludera även en ny filtrering av element. Om vi har en skada på sätet och en repa i vänster fönster på bil abc123 så skulle vi kunna skriva så här:

bil#abc123 .vänster fönster
{
    skada: stenskott;
    djup: 1 cm;
}
bil#abc123 säte
{
    skada: brännmärke;
}

Måsvingarna talar om att här slutar filtreringen av element och nu börjar deklarationen av hur elementet ska formateras. Först skriver du en nyckel med ett kolon efter och sedan ett värde, och avslutar raden med ett semikolon. När du är färdig med alla deklarationer avslutar du med en måsvinge igen.

Databas

Databasen tar hand om all information om bilden, den skulle tex kunna innehålla all information som registreringsverket har, alltså ägaren till bilen, adressen och så vidare. Den här informationen ska vara enkel att ändra då man ska kunna sälja bilen och byta ägare.

En databas är uppbyggd precis som ett excel dokument med rader och kolumner. Varje kolumn representerar en typ av information och varje rad motsvarar en post. Varje databas tabell måste också ha en primär nyckel som ska vara unik och göra det möjligt att hitta en specifik post. I vårat exempel skulle det vara helt perfekt att använda registreringsnumret som denna nyckel, då vi vet att det bara får finnas en bil för varje registreringsnummer. I många fall använder man bara en siffra som hela tiden räknar upp för varje ny post utan att vara direkt kopplad till någonting specifikt på bilen.

I tabellen finns det nu två bilar registrerade, båda är bundna till WordPressGuru, men så länge den primära nyckeln är olika så kan man ändå hitta en specifik bil.

Php

Php är ett serverspråk som talar ser till att informationen i databasen visas på hemsidan, och får saker och ting att hända. Om du vrider på nyckeln så är det php-språket som talar om att du ska ändra värdet på tändning från av till på. Det är php som placerar alla saker på rätt plats och får din bil att leva. Du kan se php som motorn i din bil. Med hjälp av villkorssatser kan du få saker att ske beroende på andra saker. Om vi tar exemplet med att vrida på nyckeln igen, så skulle du kunna skriva en sats som är
”Om du vrider på nyckeln och motorn är av -> starta motorn
annars -> stäng av motorn”

1
2
3
4
5
6
7
8
9
10

<?php
if( $vrida == true && $motorn != 'igång' )
{
    startaMotorn();
}
else
{
    stängAvMotorn();
}
?>

På rad 1 och 10 ser vi php taggarna. Dessa talar om att mellan dessa är det php-kod, så att vår hemsida vet hur den ska tolka det vi skriver.
Rad två är våran villkorssats som säger att ifall värdet på $vrida är lika med sant och värdet på $motor är ‘inte lika med’ igång så ska vi köra funktionen ”startaMotorn” annars ska vi köra funktionen ”stängAvMotorn”.

Sammanfattning

Där har vi de fyra huvudsakliga delarna i en hemsida. Html för att tala om strukturen, stilmallen för att visualisera, databasen för fakta och php för att sätta ihop allting och få det all leva.

Hur ser detta ut på riktigt?

Vi har hittills bara gått igenom detta genom ett låtsasexempel på en bil för att det ska vara lättare att förstå, men det är ny dags att börja med lite riktiga taggar så att ni ska kunna lära er att modifiera era egna hemsidor.

Det första elementet, och det som omringar alla hemsidor, är alltid taggen <html> den säger att ”här börjar en hemsida” och när webbläsaren hittar </html> så vet den att ”här slutar hemsidan”.
Inuti detta har vi först hemsidans huvud <head></head> och sedan kropp <body></body>. I huvudet skriver du saker som titel och länkar till stilmallar och lite sådant. I kroppen kommer själva hemsidan med alla dess element.

Här kommer en lista på lite bra element att känna till:

• div – Ett block, ett fyrkantigt område.
• span – Ett område som omsluter text för att kunna styla.
• p – En paragraf.
• h1 – Header 1 – brukar oftast ringa in titeln på din hemsida.
• h2, h3… h6 – Header 2-6 – h2 är ofta rubriker till inlägg, eller saker i sidopanelen. H3 är ofta underrubriker i ett inlägg och så vidare.
• strong – Gör text till fetstil, är tillsammans med em det ända element som får användas för att styla din text på andra ställen än i stilmallen.
• em – Gör text till kursiv, är tillsammans med strong det ända element som får användas för att styla din text på andra ställen än i stilmallen.
• ul – Ringar in en onumrerad lista
• li – Ett listobjekt
• a – Ett ankare – Länkar till antingen en annan hemsida, eller en annan sida på din egen hemsida.
• img – Bilder. Detta element behöver ingen avslutnings tagg utan avslutas i starttaggen: <img src=”adressen till en bild” />
• br – En radmatning i text. Detta element behöver ingen avslutnings tagg utan avslutas i starttaggen: <br />

En standard hemsida skulle kunna se ut som följer:

<html>
    <head>
        <title>
           Hello World - Min första hemsida
        </title>
    </head>
    <body>
        <h1>
            Hello World!
        </h1>
        <p>
            Det här är min första hemsida.
        </p>
        <ul>
            <li>
                En lista
            </li>
            <li>
                Ett element till
            </li>
        </ul>
        <div>
            Det här är en div
        </div>
        <span>
            Det här är en span
        </span>
    </body>
</html>

Spara koden i ett dokument som du döper till index.html och dubbelklicka på filen för att öppna den i en webbläsare.

Yes! Det fungerade, men det ser ju inte så roligt ut, så vi lägger till en stilmall också.

Skapa ett nytt dokument som du döper till style.css och placera det på samma ställe som index.html.

Ändra nu i headern (mellan <head> och </head>) så att den ser ut enligt följande:

    <head>
        <title>
           Hello World - Min första hemsida
        </title>
        <link rel="stylesheet" href="style.css" type="text/css" />
    </head>

Vi har nu lagt till en länk till vår stilmall, attributet rel talar om att det är en stilmall, href talar om vad filen heter och type talar återigen om att det är en stilmall.

Gå nu in i style.css och skriv följande:

h1
{
    color: blue;
    text-decoration: underline;
    font-size: 26px;
    font-family: Georgia, 'Times New Roman', times,serif;
}
 
p
{
    font-size: 12px;
    font-family: Verdana, Arial, Helvetica, sans-serif;
}
 
div,
span
{
    border: 1px solid green;
    color: red;
    background: yellow;
    margin-bottom: 10px;
}

Spara och ladda om din sida för att se ändringarna.

Våran header har nu bytt färg, blivit understruken och ändrat font. Vår paragraf har ändrat radhöjd och font och både våran span och div har fått bakgrund, border, text färg och en marginal i botten på 10px. Vi kan nu se hur enkelt det är ett modifiera våra element med stilmallen och få saker att se helt annorlunda ut. Vi kan också se skillnaden mellan ett div element och ett span element.

Applicera detta i WordPress

I WordPress hittar du alla filer som är värda att modifiera under ”Utseende > Redigera”. Här är saker och ting exakt likadana som jag precis har beskrivit bara lite mer avancerade. Om du kikar i din stilmall (style.css) så hittar du precis dessa definitioner, och vilka element de modifierar. Testa gärna att ändra på någonting, spara och se hur det förändrar din hemsida.

Om du använder en egen installation från WordPress.org, så hittar du även alla andra temafiler här, de som skriver ut inläggen på din sida, de som talar om hur ett inlägg ska se ut när det är ensamt och hur en sida ska formateras. Om du går in i en sådan fil och ändrar så kan du direkt se hur saker förändras på din blogg.

Det är nu kunskap och fantasi kommer med i spelet. Det gäller att veta vad man kan göra, och hitta på ett sätt att använda den informationen på. Vad beträffar databasen och php, så ignorerar jag det i denna grundläggande guide, då det kan bli relativt komplicerat och WordPress redan sköter det mesta av detta i bakgrunden åt oss i vilket fall, vilket gör att html och css är det första vi behöver lära oss.

Ett sista ord

Nu är det egentligen bara att börja testa och leka med de givna verktygen. Skapa gärna en ny blogg, och testa runt med att ta bort element, sätta in nya, och formatera dem i stilmallen.

Om du vill lära dig mer om html och css så skulle jag skarpt rekommendera att du kollar in W3Schools och deras guider och dokumentation. Annars är Google rent allmänt ett fantastiskt verktyg (jag rekommenderar inte längre W3Schools, ta istället en titt på tex Html Dog).

Viktigast av allt är dock att du vågar, och inte ger upp. Jag vet inte hur många år jag har hållit på med alla dessa språk och många fler, och jag lär mig nya saker hela tiden. Det finns alltid mer information där ute, och ingen blir någonsin fullärd, så börja på din nivå, läs och testa och våga göra fel, det gör jag också.

Registrera funktionaliteten i ditt tema

Relativt nytt för WordPress är att man måste aktivera nya funktioner i sin functions.php fil. Detta är som tur är väldigt lätt, och liknar i det här fallet en registrering av widgets. Funktionen vi ska använda heter register_nav_menus() och som parameter tar den en lista med nyckel och namn till de menyer du vill ska existera i ditt tema.

I den här guiden visar ju hur man gör två menyer, en topp meny, som vi vill kunna använda en drop down funktion på, och en meny att ha i sidfoten som ska kunna innehålla en drös med alla möjliga länkar till hela sidan. Så vi börjar med att registrera dessa två menyer genom att klistra in följande kod i functions.php:

1
2
3
4
5
6
7
8

/**
 * Två menyer, med nyckelnamnen 'main' och 'footer',
 * och visningsnamnen 'Huvudmeny' och 'Sidfotsmeny'
 **/
register_nav_menus( array(
        'main' => 'Huvudmeny',
        'footer' => 'Sidfotsmeny',
) );

Write it, cut it, paste it, save it, load it, check it, quick – rewrite it

Gå in i administraionpanelen och kika in under Utseende. Poff, så har det dykt upp ett nytt menyval där som heter Menyer. Grymt, navigera dig dit!

Du kommer nu att hitta en helt ny panel med en massa roligt att mixtra runt med, men först måste du skapa din första meny, som kommer att tjäna som en kanvas att placera länkarna på. Mitt på sidan skriver du in ett valfritt namn, och klickar sidan på Skapa Meny.

Fantastiskt! Du har nu lyckats skapa din första meny, men den innehåller inte några länkar än, och den visas ingenstans, så det måste vi genast göra någonting åt.

På vänster sida hittar du Temaposition. Där hittar du även de namn vi skrev in i functions.php i föregående stycke. Börja med att placera rätt meny, under rätt tema position, min meny som jag döpte till ”Huvudmeny” vill jag ska vara på temapositionen ”Huvudmeny” och så vidare. Glöm inte att spara!

Fortsätt sedan med att kryssa i lite sidor och kategorier, och varför inte hitta på några anpassade (egna) länkar också när du ändå håller på? Klicka sedan på Lägg till i meny för att se dina val dyka upp på menyytan i mitten av sidan.

Sist har du också möjligheten att gruppera dina menyval i annorlunda ordning, sätta ett nytt parent->child förhållande eller ta bort och redigera menyerna. Allt detta sker i mitten av skärmen med hjälp av DragOchSläpp teknik. Det kan vara lite trixigt att få menyvalen att hamna på rätt nivå ibland, men efter några försök brukar det alltid fungera.

På Huvudmenyn, försök skapa lite menyer i flera nivåer, så att vi kan gömma dessa för att sedan ta fram som en drop down meny. På Sidfotsmenyn skapa bara länkar i en nivå, då vi ändå kommer att begränsa visningen till toppnivån.

Placera dina menyer i temat

Okej, du har nu aktiverat funktionen wp_nav_menu, du har skapat dina menyer och positionerat dem på rätt ställe på administrations sidan, men de dyker fortfarande inte upp någonstans, och du ser dem fortfarande inte. Det är för att du inte har sagt till i ditt tema var någonstans dessa menyer ska skrivas ut.

Öppna därför filen header.php och leta upp en plats högt upp på sidan där du tycker att din meny ska få existera, förslagsvis strax nedanför loggan till din hemsida. Där klistrar du sedan in följande rader:

1
2
3

<?php
    wp_nav_menu( array( 'theme_location' => 'main' ) );
?>

Och det är allt som behövs. Theme_location talar om vilken meny som ska skrivas ut, och i det här fallet vill du ha huvudmenyn som vi döpte till main så tidigt som i det första stycket av den här guiden i functions.php

Öppna sedan footer.php, leta upp ett snyggt ställe att placera din sidfotsmeny på, förslagsvis precis innan en </div>-tag, och klistra in följande:

1
2
3
4

<?php
    wp_nav_menu( array( 'theme_location' => 'footer',
                        'depth'          => '1' ) );
?>

Det som är intressant här är att vi har lagt till depth och satt det till värdet 1, vilket gör att vi bara visar toppnivå länkar på den här menyn. Theme_location sätter vi till footer då detta var namnet angivet i functions.php.

And thats it folks, om du uppdaterar din sida så har du dina menyer som du precis har skapat placerade på dem ställen du placerade dem på. Nu gäller det bara att snygga till dem lite. För en guide på hur man skapar Drop Down menyer av huvudmenyn läs min guide: Bygg en Drop Down meny för sidor i WordPress men byt ut menyn som beskrivs där till den som du har här.

Godtagbara parametrar till wp_nav_menu()

Du har sett att man kan ändra temapositionen och nivådjupet på menyerna som ska visas med några enkla parametrar. Vad mer kan man ändra frågar ni? Jag har listan:

menu
Om du vill specificera en exakt meny, vid namn, som ska dyka upp, så kan du göra det med menu, parametern accepterar id, slug eller namn.

container
Elementet som ringar in hela menyn är som standard en div, det kan du ändra med den här parametern.
Default: div

container_class
Elementet som ringar in hela menyn kan få en klass som du kan specificera här.
Default: menu-{menu slug}-container

container_id
Samma som ovan, men id:t i det här fallet. Och inget standard värde.

menu_class
Ul elementet som är själva menyn har vanligt vis klassen menu, men du kan ändra det här.
Default: menu

menu_id
Samma som ovan men id:t. Standard är menyns slug med en ökande siffra efter.
Default: menu slug, incremented

echo
Huruvida menyn ska skrivas ut direkt eller returneras till en variabel att leka friskt med.
Default: true

fallback_cb
Om menyn du specificerar, eller meny positionen du har angett inte har en meny skapad åt sig, så kan du här specificera en funktion som ska kallas istället. Perfekt om du gör temat åt kunder eller för nedladdning. Eller för bakåtkompatibilitet för den delen. Som standard använder listar den alla sidor.
Default: wp_page_menu

before
Skriver ut en text före varje länktext (i länken)

after
Skriver ut en text efter varje länktext (i länken)

link_before
Skriver ut en text före varje länk (innan <a>)

link_after
Skriver ut en text efter varje länk (efter </a>)

depth
Talar om hur måna nivåer som ska få visas maximalt. 2 betyder alltså första och andra nivån, 0 betyder alla nivåer
Default: 0

walker
Avancerat! Detta är till för att göra en egen vandringsfunktion som ska användas när menyn ska skrivas ut.

theme_location
Placeringen i temat som ska användas. Namnet på positionen måste överensstämma med namnet som användes i register_nav_menu() för att användaren ska kunna välja positionen i adminpanelen.

Styla dina menyer

När menyn sedan skrivs ut loopas dina meny val genom och skrivs ut på följande sätt, så att du kan styla dem i style.css på rätt sätt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<div class="menu">
    <ul id="menu-main-menu" class="menu">
        <li id="menu-item-1" class="menu-item menu-item-type-post_type">
            <a href="http://www.wordpressguru.se/om/">About</a>
            <ul class="sub-menu">
	        <li id="menu-item-2" class="menu-item menu-item-type-post_type">
                    <a href="http://www.wordpressguru.se/om/och_om_igen/">Om igen</a>
	        </li>
	        <li id="menu-item-3" class="menu-item menu-item-type-post_type">
	            <a href="http://www.wordpressguru.se/om/lank/">Länk igen</a>
	        </li>
            </ul>
        </li>
        <li id="menu-item-4" class="menu-item menu-item-type-post_type">
            <a href="http://www.wordpressguru.se/fraga_gurun">Fråga Gurun</a>
        </li>
    </ul>
</div>

Avslutning

Det var allt för den här gången. Nu borde ni kunna skapa riktigt snygga navigationsmenyer för, och uppdatera alla era gamla. Den här funktionen går nästan inte att misslyckas med, men om ni ändå skulle få problem, lämna en kommentar, så ska jag göra mitt bästa för att hjälpa er.

Glöm inte heller bort att det krävs minst version 3.0 av WordPress för att kunna använda detta, så har du inte uppdaterat än, gör det nu!

År 2007 startades siten IconFinder som nu är en av världens populäraste hemsidor för att söka fram och ladda ner bloggikoner. Men en snygg design, enkel navigation och smarta funktioner gör IconFinder ikonsöknandet till en fröjd för utvecklaren och genom att kunna söka på en viss typ av ikon istället för ett set av ikoner, skiljer den ut sig från mängden ikonhemsidor och gör det roligt att hitta dina små bilder.

Om du hittar en ikon du tycker om, kan du självklart titta på hela settet för att hitta liknande ikoner som passar bra ihop.

Genom en användarvänlig meny kan du ställa in bakgrund till ikonerna, vilken storlek du önskar och huruvida du letar efter ikoner som går att använda till kommersiella ändamål eller inte.

De klassiska och populära ikonsamlingarna hittar du självklart också på hemsidan, likt silk2 till exempel. Genom att skriva iconset: före ditt sökord letar du enkelt upp det specifika iconset som du önskar, för just silk2 blir alltså adressen: iconset:silk2.

Som om detta inte var tillräckligt, IconFinder erbjuder dessutom ett eget API för dig att kunna programmera dina egna applikationer och funktioner emot. Kanske visa de senaste ikonpaketen på din egen hemsida?

Har du egna ikoner som du gjort hemma och känner att du också vill finnas med på IconFinder, då kan du enkelt ladda upp dina ikoner på siten och bli tillgänglig i sökmotorn för att nedladdas du med.

Detta är lite av vad IconFinder har att erbjuda, ta en titt själv för att se hur det fungerar. Har du någon annan bra ikonsida att rekommendera? Släng iväg en kommentar och berätta för mig i så fall. Tills WordPressGuru har hittat någonting bättre kommer jag i alla fall att använda IconFinder.