Jag har ett återkommande problem i sajter jag bygger med WordPress, och det är hur man enklast och bäst löser integrationen av poster i sajter som är uppbyggda med sidor.

Jag tror att det bästa sättet att illustrera problematiken är att visa, så häng med och se om du kan komma på en smart lösning på det här problemet!

När vi byggde om iis.se med WordPress var det logiskt att bygga hela sajten med en hierarkisk struktur av sidor. Det betyder att nästan hela sajten är uppbyggd av sidor, med undersidor och undersidor till undersidor. Men det finns ju vissa typer av innehåll som inte enkelt låter sig göras som sidor. Till exempel har vi pressmeddelanden (http://www.iis.se/om-se/pressrum/pressmeddelanden).

/om-se/pressrum/pressmeddelanden är just en sida – en ”page” – i strukturen. Men under denna vill jag ju lista alla pressmeddelanden, som är poster – ”posts” – i en viss kategori (logiskt döpt till ”pressmeddelanden”). Därför har jag använt en plugin som låter mig lista alla poster i en viss kategori med hjälp av en shortcode. Inga problem – alla pressmeddelanden listas snyggt och prydligt på sidan ovan.

Men – var kommer jag om jag nu klickar på ett pressmeddelandes rubrik? Jo, eftersom ett pressmeddelande är en post och inte en sida kommer jag till postens permalänk, t.ex. http://www.iis.se/pressmeddelanden/mer-generos-begransning-mot-free. Som du ser har vi nu lämnat sajtstrukturen bakom oss och slängts ut i nån slags ingen-mans-land rent sajthierakiskt. Till exempel kan vi inte längre se var i sajten vi befinner oss eftersom både huvud- och undernavigationen satts ur spel.

Jag hade naturligtvis mycket hellre sett att permalänken till det pressmeddelandet varit ”/om-se/pressrum/pressmeddelanden/mer-generos-begransning-mot-free”. Även om det är en bisarrt lång permalänk är det också en semantiskt korrekt länk, och en tydlig fingervisning om var i strukturen man befinner sig. Men det låter sig inte göras!

Jag testade ett par plugin för att hacka om permalänkarna för poster så att de verkligen visades som om de låg på ”rätt” ställe – men förutom att det var en hackig lösning funkade det inte fullt ut. Posten laddas fortfarande med ”single.php” vilket gör att man helt tappar möjligheten att markera i navigationsträdet till vänster (som är en wp_list_pages) eftersom man inte längre befinner sig inom en sidstruktur!

Samma, eller liknande problem, har jag nu fått i de fall jag vill bygga sajter med Custom Post Type. Om jag vill låta en samling poster ligga på ett visst ställe i en sidstruktur verkar det helt enkelt inte vara möjligt att lösa – åtminstone inte på något sätt som jag hittat än.

Kan du förstå problematiken? Och ännu intressantare – har du något förslag på lösning?

/M;

Många WP-sajter drivs av flera användare. En del drivs faktiskt av väldigt många. I de fall en sajt redigeras av en hel redaktion kan det vara plågsamt att inte enkelt kunna hålla koll på vem som uppdaterat vad. Det är här pluginet ”Simple History” kommer in.

Detta plugin ger dig full koll på vad alla användare pysslar med när de är inloggade i WP-Admin. Du kan se vem som ändrar eller skapar sidor och inlägg, vem som installerar plugin, laddar upp filer, och så vidare. Det här är ovärderligt för oss som har många användare som får logga in på eget initiativ och göra ändringar i en webbplats.

Eller: Det är alltid bra att veta vem man ska peka finger åt. :)

Ladda ner Simple History från WordPress.org

När man letar lediga domäner är det ofta svårt att hitta rätt namn som är ledigt – om man inte köper en IDN-domän vill säga. IDN-domäner, det vill säga domännamn som innehåller fler tecken än de ”vanliga” är oftare lediga än klassiska domännamn. Kruxet är att en del applikationer inte riktigt fått stöd för IDN, och WordPress är en av dem.

Om du har en IDN-domän, till exempel ”räksmörgås.se” så låter WordPress dig inte ange ”räksmörgås.se” som URL i inställningarna utan konverterar glatt domännamnet till den klassiska motsvarigheten, den rent tekniska domänen som anges i det som kallas ”Punycode”. I fallet med ”räksmörgås.se” skulle WordPress istället leda alla besökare till ”xn--rksmrgs-5wao1o.se” – inte direkt lika catchy.

Tack och lov finns det enkla pluginet IDNA som låter dig ange ”räksmörgås.se” som domännamn på din sajt, och som inte leder besökarna till Punycode-versionen av domännamnet.

Ladda ner IDNA från WordPress.org

Låter det här bekant?

”Du går in I ’Posts’ och så väljer du kategorin ’kampanj’ innan du klickar på ’Publish’, då hamnar inlägget rätt. Men bocka inte i någon annan kategori, då kan inlägget hamna någon annanstans. Och så får du inte fylla i något där det står ’Custom fields’ det använder du bara när du ska lägga in en ny …”

och så vidare. Skulle det inte kännas enklare att istället be kunden gå till ”kampanj” direkt, istället för att välja en speciell kategori när inlägget ska publiceras?

Säg hej till Custom Post Types i WordPress 3.0!

I det här inlägget tänkte jag visa hur vi kan göra en kampanj-yta med hjälp av Coda slider på startsidan av ett WordPress-tema som hämtar inlägg av en viss Custom Post Type.

Först ska vi ladda hem Coda slider. Coda slider är ett jQuery-script som kan bläddra mellan olika <div>-taggar på ett snyggt sätt och som är väldigt lättanvänt.

Du laddar hem filerna och bakar in dom i din header.php-fil någonstans innanför <head> och </head> på följande sätt:

<!-- Begin Stylesheets -->
	<link rel="stylesheet" href="<?php bloginfo('template_url'); ?>/coda-slider-2.0/stylesheets/coda-slider-2.0.css" type="text/css" media="screen" /> 
<!-- End Stylesheets --> 	 	
<!-- Begin JavaScript --> 
	<script type="text/javascript" src="<?php bloginfo('template_url'); ?>/coda-slider-2.0/javascripts/jquery-1.3.2.min.js"></script> 
	<script type="text/javascript" src="<?php bloginfo('template_url'); ?>/coda-slider-2.0/javascripts/jquery.easing.1.3.js"></script> 
	<script type="text/javascript" src="<?php bloginfo('template_url'); ?>/coda-slider-2.0/javascripts/jquery.coda-slider-2.0.js"></script> 
		 <script type="text/javascript">
			$().ready(function() {
				$('#kampanj').codaSlider();
			});
		 </script>
<!-- End JavaScript -->

Skapa ny post type

Nu när vi har Coda slider-filerna på plats ska vi se till att vi får in en ny post type i admingränssnittet så att vår kund kan uppdatera den här kampanj-ytan på ett enkelt och smidigt sätt. Det vi gör nu är absolut enklast möjliga och är endast att lägga till en ny typ av poster. Vi öppnar vår funktions.php-fil och lägger till följande kod-snutt:

<?php
 
function post_type_kampanj() {
	register_post_type( 'kampanj',
                array( 'label' => __('Kampanj'), 'public' => true, 'show_ui' => true ) );
	register_taxonomy_for_object_type('post_tag', 'kampanj');
}
add_action('init', 'post_type_kampanj');
 
?>

Dags att fylla på med inlägg

Klart så? Japp! Nu när vi tittar i vårt admingränssnitt har det dykt upp en ny ruta för vår kampanj-yta. Nu kan vi börja fylla på inlägg som är kampanjer.

Sen i din index.php-fil ska vi nu baka in loppen. Vi använder en query för att starta loppen och bara hämta inlägg med ”post type=kampanj”.

<div class="coda-slider-wrapper">
	<div class="coda-slider preload" id="kampanj">
 
<?php
	global $wp_query;
	$wp_query = new WP_Query("post_type=kampanj");
?>
 
<?php while (have_posts()) : the_post(); ?>
	<div class="panel">
    	<div class="panel-wrapper">
			<h2 class="title"><?php the_title() ?></h2>
			<?php the_content() ?>
		</div>
	</div>
<?php endwhile;?>
 
	</div><!-- slut .coda-slider -->
</div><!-- slut .coda-slider-wrapper -->

Se vad vi gjort

Här kan vi se vad vi gjort.

Sådär ja! Nu är allting så klart väldigt ostylat, men grundtanken hur man kan använda sig av Custom Post Types finns här. Självklart går det att bli väldigt mycket mer avancerad än det här, du kan t ex välja precis vilka kolumner och info som ska finnas för just dina custom post types. Kanske är det en mäklarsida där vi behöver flera olika typer av inlägg. En för bostadsrätter, en för villor och en för land. Sen behöver vi veta info som kvadratmeter, pris och adress? Ni förstår själva att nu börjar WordPress verkligen att på riktigt kriga mot dom stora CMS-systemen… Men det ska vi inte göra nu. Inte idag i alla fall.

Glöm inte att filtrera bort inläggen ur din vanliga loop sen, annars hamnar våra kampanjinlägg bland dina vanliga blogginlägg! Glöm inte heller att följa mig på twitter, eller besöka min hemsida. Tack för den här gången!

Ikväll är det dags för den allra första #wpbar och WPLove sponsrar! För att få lite fart på den här sajten behöver vi vara fler som skriver om WordPress så ikväll kommer jag att gå runt och försöka rekrytera så många som möjligt av de som är på plats för att skriva för WPLove.

Vill du skriva om WordPress, främst ur ett utvecklarperspektiv? Kontakta mig!

Den 9 juni är det premiär för nya konceptet WPBar där alla vi som älskar WordPress får träffas, dricka en öl eller två och snacka WordPress precis hur mycket vi vill!

WPLove är stolt sponsor av den första WPBaren som anordnas av den eminente WordPress-gurun TDH i Carnabys lokaler. Läs mer på wpbar.se.

Tidigare skrev jag här på WPLove om att lista filer som är länkade till en sida eller post genom att använda det utmärkta pluginet List Child Attachments. Tyvärr upptäckte jag snart att pluginet inte alls gjorde det jag ville, nämligen att söka igenom the_content efter länkar till filer och lista dem separat. Pluginet använder istället funktionaliteten som finns inbyggd i WP där man kan ”koppla” filer till en post genom mediebiblioteket.

Jag behövde något som var smartare, eftersom jag inte kan räkna med att alla som skriver på en sajt ska komma ihåg att manuellt länka in filerna från mediebiblioteket. Dessutom kan pluginet inte visa vilka filer som eventuellt länkats externt, om man nu skulle vilja det.

Okej, så det blev alltså dags att hacka ihop egen funktionalitet. Jag valde att lägga koden direkt i temats sidebar, men det skulle förstås gå att ”pluginifiera” om man vill.

Först hade jag ett vanligt regexp för att leta igenom the_content men eftersom jag (högst beklagligen) inte är någon regexpfantom fick jag snabbt problem med funktionen. Jag hittade av en slump PHP-klassen ”simple_html_dom” som gör det enkelt att från PHP behandla en HTML-bibba enligt Document Object Model, likt jQuery gör. Den här funktionen var perfekt för det jag ville göra. Efter att ha inkluderat koden kunde jag enkelt hitta alla länkar till fördefinierade filer i min HTML:

// Funktion för right()
function right($value, $count){
    return substr($value, ($count*-1));
}
 
// Definiera "tillåtna" länkars filändelser
$docsAr = array(".txt", ".pdf", ".doc", ".xls", ".tif", ".ppt", "mp3");
 
// Läs in HTML-koden till simple_html_dom
$html = str_get_html(get_the_content());
 
// Hitta alla element "a" i koden och loopa igenom dem
foreach($html -> find('a') AS $link) {
	if (in_array(right($link->href, 4), $docsAr)) {
		$filesAr[] = $link->href;
	}
}

Efter att ha kört denna funktion har jag nu en fin array med länkar till alla filer i the_content. Det kan vara en bra idé att massera resultatet lite genom att kolla om länken är lokal eller inte, om länken är absolut (http://url.till.sajten/uploads/fil.pdf) eller relativ (/uploads/fil.pdf) och se till att alla länkar följer samma format innan man gör en array_unique() på resultatet för att se till att samma fil inte listas två gånger ifall den är länkad två gånger.

Ganska ofta behöver jag få in funktionalitet från en extern källa i en WordPress-sida. Det kan vara något så enkelt som innehållet i en textfil som ska läsas in, sorteras och visas som tabell, eller något mer avancerat som en helt egen webbapplikation som behöver komma in och bo någonstans i en WP-sajt. Hittills har jag använt mig av specifika sidmallar med extra PHP-kod för att bygga in den här typen av funktioner, men jag börjar tveka. På en av mina installationer har jag nära tjugo olika sidmallar, och de allra flesta används bara en gång, på en specifik sida. Det känns inte så smart eller flexibelt.

Ett sätt att komma runt detta skulle vara att installera ett av de många plugin som låter mig köra PHP-kod i en post eller sida, men det känns som en riktigt läskig metod. Om någon mot förmodan skulle lyckas få tillgång till att ändra innehållet i mina sidor skulle det gå att köra valfritt PHP-kommando med ett sånt plugin, för att inte tala om möjligheten att pluginet i sig har säkerhetshål som gör det möjligt.

Det jag nu funderar på är att använda shortcodes och functions.php för att komma runt det hela istället. WordPress Codex berättar väldigt enkelt om shortcode API och det är rekommenderad läsning för den som inte pysslat med shortcodes tidigare. Shortcodes används vanligen av plugins för att skapa genvägar till pluginfunktionalitet som kan användas inne i poster eller sidor, men det finns inget som hindrar att vi definierar en shortcode inne i ett temas functions.php istället.

Exempel

Codex eget exempel för att definiera en shortcode ser ut såhär:

// [bartag foo="foo-value"]
function bartag_func($atts) {
	extract(shortcode_atts(array(
		'foo' => 'no foo',
		'bar' => 'default bar',
	), $atts));
 
	return "foo = {$foo}";
}
add_shortcode('bartag', 'bartag_func');

Exemplet ovan skulle skapa en shortcode med namn ”bartag” som tar två argument, ”foo” och ”bar”. I det här exemplet görs ju ingenting med innehållet, men genom att modifiera koden något skulle vi kunna skapa en bra shortcode för att anropa egna PHP-funktioner och göra det så säkert som möjligt:

// [myfunction funcname="name"]
 
function myfunction_func($atts) {
	extract(shortcode_atts(array(
		'funcname' => ''
	), $atts));
 
	if ($funcname == 'display_log') {
		display_log();
	}
	elseif($funcname == 'statistics') {
		run_statistics();
	}
	return true;
}
add_shortcode('myfunction', 'myfunction_func');

Vi har nu skapat en shortcode som heter ”myfunction” och som tar ett argument, ”funcname”. Inne i shortcode-definitionen har vi världens enklaste if-sats för att se om man skickat in något av två fördefinierade funktionsnamn som kan användas för att köra PHP-funktioner. Det finns snyggare sätt att lösa det här på, men för att illustrera mitt exempel duger detta gott.

Vad tycker du?

Vad tycker du – är det här ett bra sätt att lösa det hela på, eller finns det bättre sätt? Finns det uppenbara brister i det här sättet att köra PHP-kod inifrån en sida/post? Kommentera gärna!

Uppdatering: Det här pluginet gjorde inte exakt som jag ville. Läs om hur jag gjorde en alternativ lösning.

I ett sajtprojekt jag för tillfället är inblandad i kräver webbdesignen att alla filer som länkas i en sida även ska listas separat i spalten. Det är en mycket bra idé, eftersom det då snabbt går att se t.ex. nedladdningsbara PDF:er för en sida eller en lista över alla länkade högupplösta bilder i ett pressrum, och så vidare.

Självklart vill man slippa att den som skapar sidan måste hålla koll på länkade filer och lista dem separat i extrafält eller liknande, så jag hade precis börjat fundera på hur jag skulle kunna parsa the_content för att hitta länkar till filer som ligger lokalt när jag kom på att någon redan borde ha löst det här åt mig. En snabb Googling senare har jag hittat ”List child attachments” som av någon anledning inte ligger på WordPress.org utan endast på Google Code.

Nåväl, det här pluginet gör exakt det jag vill, och gör det dessutom bra, med ett antal konfigureringsalternativ. Jag kan välja i vilken ordning filerna ska listas, vilka typer av filer som ska listas och jag kan implementera det hela med en PHP-snutt i mitt tema eller bara lägga in det på vissa sidor med en shortcode. Dessutom genereras väldigt prydlig HTML med tydliga klasser för filtyp vilket gör det lätt att skapa väldigt snygg formattering med filikoner eller vad man nu vill.

Användning

Efter att pluginet är installerat är det en smal sak att lägga in koden i sitt tema, men jag tänkte här titta på shortcoden för att använda pluginet på vissa sidor.

[attachments filetype=WORD]

Den här shortcoden listar länkade filer, men endast om de är Wordfiler. På det här sättet kan du begränsa vilka filer som listas genom att ange filtyp (ALL, FILE, IMAGE, WORD, PDF, XLS, PPT).

[attachments order=DESC orderby=post_modified]

Den här koden listar länkade filer sorterade efter ändringsdatum och i fallande skala, så de filer som laddats upp senast kommer att listas först.

Läs mer och ladda ner

• List child attachments på Google Code

Bild- och filhanteringen i WordPress är ett av de områden som jag önskar mig många förbättringar inom. Det kommer visserligen nyheter hela tiden, som möjligheten till enklare bildredigering i WordPress 2.9, och mycket går att lösa med plugins, men ännu saknas ett antal grundläggande funktioner för att WordPress ska kunna bli ett fullfjädrat CMS direkt efter installation.

Från och med WordPress 2.9 finns åtminstone äntligen stöd för ”post-thumbnails”, en funktion som är tänkt att användas för att visa ”tumnaglar” till dina inlägg, som namnet antyder. Trots sitt namn är det smidigt att använda den här funktionen för att koppla även stora bilder till inlägg, och sedan automatiskt skapa tumnaglar av dem, i en eller flera storlekar. Det här är en teknik som jag använder på t.ex. internetdagarna.se där varje post har en bild kopplad till sig för att visas över inlägget, och samtidigt en omskalad version av bilden som visas vid listningar, arkivsidor, etc.

Det här tycker jag tyvärr är ett typiskt exempel på hur WordPress fungerar – man tar fram en funktion som är väldigt användbar som en mer traditionell CMS-liknande lösning, men väljer att döpa och informera om funktionen så att dess tänkta användning blir mycket smalare än vad som faktiskt går att göra med den. Men vi kan ju självklart bortse från det och titta på hur vi kan använda post-thumbnails för att skapa en helt dynamisk bildlösning oavsett användningsområde.

Innan version 2.9 fanns det inget smidigt sätt att knyta en bild till en post eller sida. Man kunde självklart lägga in en eller flera bilder i själva inlägget, men för att använda bilden separat var man tvungen att använda något av de plugin som tagits fram för att hämta första bilden ur ett inlägg eller liknande. Det finns också flera plugins som gör samma sak som post-thumbnails i 2.9, dvs låter användaren välja en bild från mediabiblioteket och knyta den till en post för att sedan använda den i temafilen på olika sätt.

Att koppla bilder till inlägg och sidor

Med post-thumbnails kan man nu göra det direkt i WP, utan plugins, men först måste man ange att temat har stöd för funktionen genom att ange följande i sin functions.php:

// Lägg till support för post-thumbnails i detta tema
add_theme_support( 'post-thumbnails' );

Den lilla raden talar om för WordPress att det aktiva temat har stöd för post-thumbnails och ger automatiskt ett nytt val i redigeringsvyerna för inlägg och sidor:

I bilden ovan har jag redan valt en bild att använda som tumnagel för inlägget jag redigerar. När tumnageln är sparad kan vi i temat enkelt plocka ut den valda bilden till varje inlägg och visa den. Det här är praktiskt för att skapa en sajt där den som postar inlägg inte behöver veta hur man lägger in bilder i den visuella textredigeraren, särskilt om vi har speciella regler för hur de ska visas på sajten, men hur gör vi nu om vi vill visa bilden i en annan storlek än den som laddades upp? Vi kanske vill att de bilder vi valt ska visas på förstasidan som miniatyrer istället för full storlek.

Det går enkelt att skapa en hel uppsättning med fördefinierade tumnagelsstorlekar för WordPress att använda sig av, och vi gör det med fördel på samma ställe som vi initierade funktionen, i functions.php:

// Definiera standardstorlek på bilder: 660 pixlars bredd och fri höjd
set_post_thumbnail_size(660, 9999);
 
// Definiera ett tumnagelsformat på 322 pixlars bredd och fri höjd
add_image_size('index-thumb', 322, 9999);

Vad gjorde vi egentligen i exemplen ovan? Den första raden, ”set_post_thumbnail_size”, skapar ett standardformat för bilder som hämtas via post-thumnails. I det här fallet har jag berättat för WordPress att mina bilder i standardstorlek ska vara 660 pixlar breda och max 9999 pixlar höga, vilket i princip ger mig fri höjd. WordPress kommer nu att skala om uppladdade bilder till det formatet, och jag kan använda bilderna i mitt tema och veta att de kommer att vara max 660 pixlar breda.

Den andra raden, ”add_image_size” lägger till ytterligare ett bildformat, och här har jag valt att bilden ska vara max 322 pixlar bred och 9999 pixlar hög. Det första argumentet här, ”index-thumb” ett namn jag själv anger, för att enkelt kunna anropa bilder i det här formatet senare.

Det går nu att ange hur många olika bildformat man vill, och att ge alla ett eget namn. WordPress kommer nu att automatiskt skapa omskalade tumnaglar i rätt format varje gång en bild laddas upp till mediabiblioteket.

När du väl kopplat en bild till ett inlägg kan du se i inläggslistningen vilken bild som är kopplat till vilket inlägg:

Att använda bilderna

Okej, vi har skapat ett eller flera tumnagelsformat och fått WordPress att visa val för tumnagel i anslutning till post- och sidredigeringsvyerna. Hur gör vi nu för att visa de bilder som kopplas till inläggen? Hela poängen med den här övningen är ju att visa bilderna i rätt storlek på sajten.

Det finns ett par enkla metoder att använda inne i ”the loop” för att visa bilden i sitt tema. Först den allra enklaste:

// Skriv ut komplett img-tagg med bilden i standardformatet
the_post_thumbnail();

Kodsnutten ovan skriver helt enkelt ut den bild som angetts i standardformatet, det format som vi angav med ”set_post_thumbnail_size” ovan.

//Skriv ut komplett img-tagg med bilden i formatet "index-thumb"
the_post_thumbnail("index-thumb");

Här lägger vi istället in bilden i formatet ”index-thumb” som vi skapade med ”add_image_size” ovan.

Ditt tema kanske behöver veta om ett inlägg har en bild kopplad eller inte? Här kommer ”has_post_thumbnail” till användning:

// Kolla om ett inlägg har en bild kopplad eller inte
if (has_post_thumbnail()) {
   the_post_thumbnail();
}
else {
   echo "Här fanns det ingen bild!";
}

Avancerat

Det här är egentligen allt som behövs för att använda post-thumbnails, men det finns ett par saker till som kan vara bra att kunna. Först och främst, precis som med de flesta WP-funktioner finns en variant för att returnera värdet istället för att skriva ut det:

// Hämta komplett sökväg till bild kopplad till inlägget
$thumbnail = get_the_post_thumbnail();

Du kan också strunta i ”the loop” och hämta bild kopplad till ett visst inlägg eller en viss sida bara du har dess ID:

// Hämta komplett sökväg till bild kopplad till inlägg/sida med ID 424
$postID = 424;
$thumbnail = get_the_post_thumbnail($postID);

Även ”has_post_thumbnail” kan ta ett ID som argument så du kan kolla status för en post utanför loopen:

// Kolla om post med ID 424 har en bild kopplad eller inte
$postID = 424;
if (has_post_thumbnail($postID)) {
   echo the_post_thumbnail($postID);
}
else {
   echo "Posten har ingen bild.";
}

Vad saknas?

• Det känns märkligt att det bara går att koppla en bild till ett inlägg på det här sättet. Jag kanske vill ha två eller flera bilder kopplade? Det går inte att göra med dagens post-thumbnails.
• WordPress klarar inte av att skala om bilder direkt, utan de format du vill använda måste finnas definierade med ”add_image_size” innan du laddar upp bilden. Det här är en enorm brist den dagen du byter design på din sida och behöver ha alla tumnaglar ett annat format än du skapat dem! Tack och lov finns det plugin som löser det här, t.ex. det utmärkta regenerate thumbnails men självklart borde WP lösa det här på egen hand, dynamiskt.

Nästa gång

I del två av den här serien kommer jag att titta närmare på hur du kan skapa en helt dynamisk lösning för att skala om bilder i WordPress med hjälp av PHP och GD. Mer om det senare.

Läs mer

• the_post_thumbnail() i Codex
• get_the_post_thumbnail() i Codex
• has_post_thumbnail() i Codex
• WordPressguru.se om post-thumbnails