Eftersom föreläsning 7 blivit inställd tänkte jag istället försöka räta ut några frågetecken skriftlig här och sedan länka till de föreläsningar som John höll för två år sedan.
(Jag ber om ursäkt att jag inte lyckats skapa någon tjusig meny, det är en lång post och mycket att leta igenom. Johns föreläsningar finns längst ner.)
Från förra veckans föreläsning och laboration
Jag har förstått att en del av er har haft problem med att komma igång. Ni har inte riktigt fått kläm på var ni ska lägga era filer och ni har laddat upp mina exempel-filer för att och sedan arbetat vidare från dessa. Även om inget av detta var tanken får vi nu göra det bästa av situationen och gå vidare från den punkt där vi befinner oss. Att kopiera min kod, med de fel och brister den innehåller (se nedan) kanske kostar mer än det smakar, men i grund och botten är enda skillnaden mellan det och att skriva av t.ex. boken mängden arbete man får lägga på att trycka ner tangenter – med reservation för att man, när man skriver av boken, får en chans att fundera på vad det är man skriver, något som man ju helt missar om man bara kopierar in mina filer. Jag hade kanske mer tänkt att mina filer skulle fungera som en utgångspunkt för den som vill gå tillbaka och i lugn och ro titta på det som hände på föreläsningen. Nog om detta.
För den som var förvirrad efter förra veckans föreläsning kan jag inte nog rekommendera boken och WordPress Codex som innehåller massor med information, från det mest grundläggande till mycket avancerade saker. Där finns allt från grundläggande instruktioner för hur man kommer igång med sin WordPress-sidan till hur man utvecklar egna teman och insticksprogram eller bidra till själva kärnan. Om första delen av kursen var väldigt centrerad runt “se-och-lär” är den här delen av kursen väldigt fokuserad runt “läs-fundera-testa-lär”.
Ett par grundläggande saker jag ändå vill lägga lite extra vikt vid:
- Du utvecklar ditt eget tema i en mapp som du placerar under
wp-content → themes
. Det är endast i den här mappen du behöver ändra något. - Filen
bas.html
är en fil jag vill att ni skapar för att ni (a) ska få en klar bild av vad det är ni vill skapa med hjälp av WordPress och (b) att ni ska förstå attheader.php
,index.php
,footer.php
och vilka andra filer ni nu väljer att skapa alla används för att sätta ihop olika delar till en (1) HTML-sida som sedan skickas till webbläsaren. Det är inte något man behöver göra för att utveckla ett WordPress-tema utan något jag ber er göra för att jag ser en pedagogisk funktion med det. Vissa förstår hur det fungerar utan filen, andra kanske lättare förstår med hjälp av den. Eftersom jag på förhand inte vet vem som kommer förstå eller ej ber jag alla göra det.
Några stil-relaterade funktioner
Jag tänkte börja med det som jag förstått skapat mycket förvirring, nämligen alla “magi” som WordPress tillhandahåller och det första exemplet är the_ID()
och post_class()
som vi hittar på rad 13 i exempelfilen index.php
. Vad gör raden egentligen? I sitt sammanhang, inne i loopen, ser den ut såhär:
<article id="post-<?php the_ID(); ?>" class="<?php post_class(); ?>">
<header>
<h2 class="entry-title">
När jag testkörde koden upptäckte jag att det finns ett fel på raden. Den ska egentligen se ut så här:
<article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
Om vi nu testar sidan och sedan tittar på den kod vi får tillbaka från servern ser raden (i webbläsaren) ut såhär:
<article id="post-9" class="post-9 post type-post status-publish format-standard hentry category-nyheter">
Vi har förstå fått ett unikt id
för posten (post-9
) tack vara the_ID()
som alltså ger oss siffran 9 i det här fallet. Vi har dessutom fått en hel serie klasser via post_class()
som låter oss hantera olika poster med hjälp av CSS. Hade det t.ex. varit en “klistrad” (eng. sticky) post hade postens class
innehållet en indikation på att det är en klistrad post och vi hade då, i vår CSS
kunnat hantera den på något speciellt sätt om det vore önskvärt.
På samma sätt är det med alla funktioner vi får via WordPress. De fungerar som genvägar och låter oss göra saker utan att förstå den djupare underliggande strukturen som WordPress tillhandahåller. Det kan verka förvirrande men det ligger som ett lager mellan oss som temautvecklare och systemets kärna för att underlätta utvecklingen av gränssnittet, vilket är det vi är intresserade av.
Det viktiga här är att förstå vad funktionerna ger oss så att vi inte gör de misstag som jag gjorde och lägger till saker (class=""
) som funktioner själv tillhandahåller. Vi hittar en liknande funktion på rad 25 i header.php
där vi öppnar body
-taggen på följande sätt:
<body <?php body_class(); ?>>
Här gör body_class()
samma sak för body
-taggen som post_class()
gjorde för den enskilda posten och slutresultatet i webbläsaren (om man tittar på den kod servern skickar) blir:
<body class="home blog logged-in admin-bar no-customize-support">
bloginfo()
bloginfo()
är en väldigt användbar funktion som “[d]isplays information about the current site
” (https://developer.wordpress.org/reference/functions/bloginfo/). bloginfo()
skriver ut den önskade informationen så att den blir tillgänglig i webbläsaren. Om vi tittar på koden som gör sidans titel till en länk på rad 32 i header.php
så ser den ut på följande sätt:
<a href="<?php echo home_url(); ?>"><h1 id="site-title"><?php bloginfo( 'name' ); ?></h1></a>
Här hittar vi två funktioner, dels echo home_url()
och dels bloginfo( 'name' )
. Den förra ger oss URL:en till startsidan, men presenterar den inte på ett sätt som är lämpligt för webbläsaren. Alltså måste vi lägga till echo
. Hade vi inte gjort det hade webbservern skickat följande till oss
<a href="">
istället för
<a href="https://examples-tivarsson.c9users.io">
.
bloginfo()
å andra sidan är gjort för att skicka ut information till webbläsaren och därför behöver vi inte (precis som vi inte behövde det med the_ID()
eller post_class()
använda echo
för att få fram informationen i webbläsaren. Det gäller alltså att hålla koll på vad funktionerna gör och hur det är tänkt att de ska användas. Bästa sättet att få det är att titta i WordPress Codex och att söka upp funktionerna i WordPress Code Reference.
Tillbaka till bloginfo()
. Funktionen tar en inparameter som berättar exakt vilken information vi vill ha. I det här fallet är det bloggens “namn”, d.v.s. det vi sagt i administrationsgränssnittet att vi vill att bloggen ska heta. WordPress letar upp namnet i databasen och returnerar det på ett sätt som gör det möjligt för servern att skicka det direkt till webbläsaren. Tittar man i exempelkoden hittar man flera tillfällen där bloginfo()
, bl.a. för att få reda på teckenkodning, URL:en till stilmallen och webbplatsens “slogan”. Informationen hämtas med hjälp av de fördefinierade begrepp som kan användas som inparametrar till funktionen (https://developer.wordpress.org/reference/functions/bloginfo/).
Lite saker som vi inte tog förra veckan
Det finns även den del saker som inte kom med förra veckan och jag hoppas få med dem här.
Navigering
Både header.php
och footer.php
innehåller, i mitt exempel, en meny. Den skapde vi med hjälp av följande code:
<nav>
<?php wp_nav_menu( array( 'theme_location' = 'top-navigation' )); ?>
</nav>
Här beskriver vi vilken meny det är vi vill ha men tittar vi i beskrivningen av funktionen hittar vi att vi följande beskrivning: “Theme location to be used. Must be registered with register_nav_menu() in order to be selectable by the user” (https://developer.wordpress.org/reference/functions/wp_nav_menu/). Och för att registrera den behöver vi ytterligare en fil, functions.php
. Den skapar vi i vår tema-mapp. Det vi egentligen behöver lägga till är:
<?php
register_nav_menu('top-navigation',__( 'Huvudmeny' ));
?>
Inparametrarna är för vår “location” (samma som vi angav i wp_nav_menu()
) och nästa är ett namn som dyker upp i administrationsgränssnittet. Vanligare är dock att man lägger funktionen i en egenhändigt definierad funktion
function register_my_menu() {
register_nav_menu('top-navigation',__( 'Huvudmeny' ));
}
och sedan aktiverar funktionen med hjälp av
add_action( 'init', 'register_my_menu' );
.
I vårt fall kan vi göra det allt direkt i fuctions.php
. Fördelen med att skapa en funktion istället för att lägga in det direkt i functions.php är att det ger oss möjlighet att välja när vi vill aktivera den. Nu kan vi i vilket fall gå in i vårt administrationsgränssnitt (har man inte fått fram den fina listen som visas när man är inloggad kan man alltid gå till förstasidan, i mitt fall https://examples-tivarsson.c9users.io/
, och sedan lägga till /wp-admin
, i mitt fall blir det alltså https://examples-tivarsson.c9users.io/wp-admin
). Där kan vi nu under utseende förhoppningsvis börja förändra vår meny så att det blir som vi vill ha den (fördelen med detta är givetvis att andra användare av vårt tema också kan få sina menyer som de vill ha dem).
Sidebar
Min bas.html
hade även en sidebar som vi lite fint gled förbi under föreläsningen. Detta måste givetvis åtgärdas. Vi börjar med att skapa den fil koden ska finnas i, sidebar.php
och sedan ser vi till att index.php
läs in denna på lämplig ställe. Koden för att hämta sidebar.php
är ungefär den samma som vi använder för att läsa in header.php
eller footer.php
, nämligen get_sidebar()
. Funktionen bearbetar den kod vi skrivit i sidebar.php
på det ställe vi placerat den i index.php
och levererar eventuella resultat som en del i den HTML-sida som skickas till webbläsaren.
I min plan hade jag bestämt att det skulle finnas gränssnittskomponenter i min “sidebar” och då måste jag skapa en ny funktion i min functions.php
som låter mig göra detta. Koden för det ser ut som följer:
function theme_register_sidebars() {
register_sidebar( array(
'name' => 'Right column',
'id' => 'right-column',
'before_widget' => '<li id="%1$s" class="widget-container %2$s">',
'after_widget' => '</li>',
'before_title' => '<h3 class="widget-title">',
'after_title' => '</h3>',
));
}
add_action( 'widgets_init', 'theme_register_sidebars' );
Grundstrukturen är mer eller mindre den samma som i exemplet med navigeringen men funktionen register_sidebar()
(slå gärna upp den i WordPress Code Reference) låter oss specificera en del saker som påverkar hur våra gränssnittskomponenter (widgets) visas. name
låter oss namnge vår sidebar så vi kan hitta den i administrationsgränssnittet. id
ger oss ett namn som vi kan använda oss av i sidebar.php
när vi vill att vår sidebar ska konstrueras (och skickas till webbläsaren). before_widget
är den HTML-kod vi vill ha innan vår gränssnittskomponent och after_widget
är då motsvarande fast på andra sidan. before_title
och dess motpart after_title
låter oss på motsvarande sätt specificera vad som ska placeras före och efter gränssnittskomponentens titel.
add_action()
slutligen är det som aktiverar det hela.
I sidebar.php
är det sedan dags att se till att det händer något som kan skickas vidare till den som råkar besöka vår sida. Gränssnittskomponenterna kommer att visa som en lista så det gäller att packa in dem på rätt sätt. Varje komponent kommer automatiskt att presenteras som en enhet i listan (innesluten i <li></li>
). Jag kopierar alltså bara “ramen” från min bas.html
till
sidebar.php
<aside id="sidebar-container">
<ul id="sidebar">
// Bortagen kod som ska ersättas av PHP-kod
</ul>
</aside> <!-- #sidebar-container ends -->
Kode för att sedan få in vår nyregisterarde sidebar skulle då kunna se ut såhär:
<?php
// Om vi inte har någon sidebar - lägga ut statiskt material
if ( ! dynamic_sidebar( 'right-column' )) : ?>
<li>Please add some widgets to the <em>Right column</em> widget area!</li>
<?php endif; ?>
Här är det dynamic_sidebar( 'right-column' )
gör magin. right-column
är det id
vi gav vår sidebar i functions.php
. I sidebar.php
försäker vi hämta den (dynamic_sidebar( 'right-column' )
) i en if
-sats för att, om det inte fungera, kunna meddela användaren (som förhoppningsvis är sidans administratör) att det är läga att lägga till lite gränssnittskomponenter (widgets) i den panelen med namn “Right column”. Panelen hittar man i administrationsgränssnittet under Utseende → Widgets
. Finns det inga gränssnittskomponenter som faller en i smaken går det alltid att ladda ner färdiggjorda från nätet genom att lägga till nya “Tillägg” som fokuserar på gränssnittskomponenter.
Kategorier
Ett sätt att organisera sina poster är att tilldela dem kategorier. De kategorier en post tilldelats sparas i en databas och det gör det möjligt att söka fram alla poster som tillhör en viss kategori (vilket är trevligt eftersom det då även blir möjligt att skapa menyalternativ som visar alla poster som tillhör en viss kategori). I administrationsgränssnittet finns det redan inbyggda funktioner för att lägga till kategorier som menyalternativ och dessutom finns det färdiga gränssnittskomponenter som gör det möjligt att presentera sina kategorier i t.ex. en sidebar av det slag vi skapade ovan.
Detta är bara en liten del av vad man kan göra med kategorier – den vetgirige kan söka mer information i boken och på nätet (och kanske i Johns föreläsningar).
Kommentarer
En viktig del bloggar och idag är e-handel där kunderna kan berätta om sin upplevelse av produkten är kommentarer. Precis som de de andra delarna av vår sida kan vi bryta ut kommentarerna till en egen fil, comments.php
och sedan kan vi hämta in innehållet i filen på lämpligt ställe med koden comments_template()
. Värt att observera är att det finns en “standard-fil” som comments_template()
läser in om man inte har skapat något comments.php
.
Hur får man då in kommentarerna? Utifrån de filer jag skapat skulle man i index.php
kunna lägga till lite kod precis innan raden endwhile;
som stänger loopen:
if ( is_single() ) {
comments_template();
}
if
-satsen kontrollerar om vi är på en sida där bara en post visas (vi vill kanske inte visa kommentarerna på förstasidan) och om så är fallet visas kommentarerna. Eftersom jag inte lagt till någon comments.php
används WordPress standard-template. Vill man istället strukturera om kommentarerna på något sätt får man själv gå skapa en comments.php
och sedan lägga till den kod som behövs för att de ska visas på önskat sätt.
Enskilda poster, statiska sidor …
Nu har jag inte pratat om det men man kan t.ex. skapa en fil som heter single.php
som används för att visa “singel”-sidor (t.ex. enskilda poster). Väljer man att visa en enskild post och det finns en single.php
kommer en användas istället för index.php
. Det betyder att man kan välja att visa enskilda poster på ett lite annorlunda sätt än vad man visar sammanställningen skapas med index.php
. På samma sätt kan m an frångå index.php
om man vill visa statiska sidor med hjälp av page.php
. Använder man en single.php
och vill visa kommentarerna på samma sätt som ovan behöver man inte testa om det är en singel-sida (if ( is_single() )
) eftersom vi redan kan anta att det är det (annars skulle inte single.php
ha använts. Smidigt.
Det finns fler tips och trick som gör det lättare att modifiera ett tema med så kallade “barnteman” (eng. child theme) som innebär att man tar ett redan existerande tema och bygger vidare på det utan att modifiera filerna från det ursprungliga temat. John beskriver detta närmare i föreläsningarna nedan och bokat har också utförliga beskrivningar av hur detta går till.
Sök-funktion
Precis som med kommentarerna ovan så finns det en inbyggd sökfunktion i WordPress som låter användaren leta efter specifik information på sajten. Koden för detta är get_search_form()
(vi har faktiskt redan använt den i index.php
). Funktionen kommer att leta efter filen searchform.php
och hittar den inte filen kommer den att använda WordPress inbyggda. I grund och botten tillhandahåller den ett formulär som tillåter att man söker. Resultatet presenteras antingen med hjälp av filen search.php
eller index.php
om den förra saknas. Värt att vara uppmärksam på är vad som händer om det inte finns några sökresultat. I exempel-koden på kurshemsidan får vi gå till index.php
och titta i koden. Loopen inleds med testet if ( have_posts() )
och sedan kör den vidare om det finns poster. Vid sökning är det möjligt att detta test ger ett falskt resultat, d.v.s. användaren har sökt på något som inte finns i databasen. Då kommer följande kod levereras tillbaka till användaren:
<article id="post-0" class="post no-results not-found">
<header>
<h2 class="entry-title">Nothing found</h2>
</header>
<p>We're sorry but we couldn't find anything for you. Please try and search for whatever
it was you were looking for.</p>
<?php get_search_form(); ?>
Det är ju ett helt OK felmeddelande. Jag kan dock tycka ett par saker:
- Om det är en svensk sida kanske felmeddelande ska vara på svenska?
- Om man kommer till sidan p.g.a. en sökning kanske man ska få se vad man sökt på? Varför? Tänk om man stavat fel – då har man chansen att upptäcka det. Alternativt om någon har länkat till sökresultatet och man kommer till sidan via den sökningen – då kan det vara trevligt att veta att det man ser är resultatet av en sökning och att dess innehåll kan ha förändrats sedan den som skapade länken sökte.
Child-teman, några kommentarer
Detta är något som är en del av kursen och därför kommer vi undersöka det närmare. John pratar om det i föreläsningen nedan så jag tänker inte säga så mycket om det men några kommentarer som är bra att ha med sig när man börjar arbeta med temat:
- Du måste ha det tema du vill modifiera installerat som ett valbart tema i WordPress.
- Du göra alla dina modifieringar i den katalog du skapat för ditt child-tema. Du gör inga ändringar i förälder-temat.
- I ditt child-tema skapar du endast de filer du ska modifiera. Alla andra filer läser WordPress automatiskt in från förälder-temat. Det betyder att om din plan endast är att modifiera sidans stilmallar skapar du endast
style.css
. Vill du dessutom göra ändringar i hur enskilda poster presenteras skapar du dessutomsingle.php
och så vidare.
UPPDATERING: Eventuellt behövs även vissa modifieringar av functions.php
. Mer information finns i WordPress Codex.
Inspelat material
Temat för föreläsningen är framför allt: template pages; att bygga vidare på färdiga teman (se även kommentarerna och framför allt uppdateringen i sektionen “Child-teman, några kommentarer” ovan); statiska sidor; custom post type.
Presentationen (WordPress, del 2): http://orion.lnu.se/pub/education/course/1IK424/VT14/sessions/F07.html
Demofilm om hur man skapar en dynamisk meny
Läshänvisningar i boken
I boken “Smashing WordPress – beyond the blog” läs kapitlen 5, 6 och 9.
Demonstrationsfilmer
Ytterligare filmer som John skapat för att visa specifika saker man kan göra med WordPress.
Cutsom post type:
- Att skapa en custom post type
- Att läsa ut ur en specifik custom post type via WP_Query
- Custom post type categories
- Visa Custom post type categories
Här kan du ladda ner det childtheme som används i filmerna ovan. Observera att det också finns ett extra exempel som listar ut poster under respektive kategori. Du hittar den i “template-boat-by-categories.php”
Shortcodes: