Språk: বাংলা • Engelska • Español • 日本語 한국어 • Português do Brasil • Русский • 中文 (简体) •中文 (繁體) • (Lägg till ditt språk)

Den här artikeln handlar om att utveckla WordPress-teman. Om du vill lära dig mer om hur du installerar och använder teman, gå igenom Använda teman. Detta ämne skiljer sig från att använda teman eftersom det diskuterar de tekniska aspekterna av att skriva kod för att skapa egna teman snarare än hur man aktiverar teman eller var man kan få nya teman.

Varför WordPress-teman

WordPress-teman är filer som fungerar tillsammans för att skapa design och funktionalitet på en WordPress-webbplats. Varje tema kan vara annorlunda och erbjuder många val för webbplatsägare att omedelbart ändra deras webbplatsutseende.

Du kanske vill utveckla WordPress-teman för eget bruk, för ett klientprojekt eller att skicka till WordPress Theme Directory. Varför ska du bygga ett WordPress-tema?

• Skapa ett unikt utseende för din WordPress-webbplats.
• Att utnyttja mallar, malltaggar och WordPress Loop för att generera olika webbplatsresultat och utseende.
• Att tillhandahålla alternativa mallar för specifika webbplatsfunktioner, t.ex. som kategorisidor och sökresultatsidor.
• För att snabbt växla mellan två webbplatslayouter, eller för att dra nytta av ett tema- eller stilomkopplare för att låta webbplatsägare ändra utseendet på din webbplats.

Ett WordPress-tema har också många fördelar.

• Det skiljer presentationsstilar och mallfiler från systemfilerna så att webbplatsen uppgraderas utan drastiska ändringar av den visuella presentationen av webbplatsen.
• Det möjliggör anpassning av webbplatsens funktionalitet som är unik för det temat.
• Det möjliggör snabba ändringar av den visuella designen och layouten för en WordPress-webbplats.
• Det tar bort behovet av att en typisk WordPress-webbplatsägare måste lära sig CSS, HTML och PHP för att ha en snygg webbplats.

Varför ska du bygga ditt eget WordPress-tema? Det är den verkliga frågan.

• Det är en möjlighet att lära sig mer om CSS, HTML och PHP.
• Det är en möjlighet att sätta din expertis med CSS, HTML och PHP fungerar.
• Det är kreativt.
• Det är roligt (för det mesta).
• Om du släpper det för allmänheten kan du må bra att du delade och gav tillbaka något till WordPress-communityn (okej, skrytande rättigheter)

Standarder för temautveckling

WordPress-teman bör vara kodad med följande standarder:

• Använd välstrukturerad, felfri PHP och giltig HTML. Se WordPress-kodningsstandarder.
• Använd ren, giltig CSS. Se CSS-kodning Standarder.
• Följ designriktlinjerna i webbdesign och layout.

Anatomi för ett tema

WordPress-teman finns i underkataloger till WordPress-temakatalogen (wp-innehåll / teman / som standard) som inte kan flyttas direkt med hjälp av filen wp-config.php. Underkatalogen för temat innehåller alla temastilar Eetfiler, mallfiler och tillvalsfunktionsfil (functions.php), JavaScript-filer och bilder. Till exempel, ett tema med namnet ”test” finns i katalogen wp-content / themes / test /. Undvik att använda siffror för temanamnet, eftersom detta förhindrar att det visas i listan över tillgängliga teman.

WordPress innehåller ett standardtema i varje ny installation. Undersök filerna i standardtemat noggrant för att få en bättre uppfattning om hur du skapar dina egna temafiler.

För en visuell guide, se denna infografik på WordPress Theme Anatomy.

WordPress Teman består vanligtvis av tre huvudtyper av filer, förutom bilder och JavaScript-filer.

1. Styleheet kallas style.css, som styr presentationen (visuell design och layout) på webbplatsens sidor.
2. WordPress-mallfiler som styr hur webbplatsens sidor genererar informationen från din WordPress-databas som ska visas på webbplatsen.
3. Den valfria funktionsfilen (functions.php) som en del av WordPress-temafilerna.

Låt oss titta på dessa individuellt.

Barnteman

Det enklaste temat som är möjligt är ett barntema som bara innehåller en style.css fil, plus eventuella bilder. Detta är möjligt eftersom det är ett barn av ett annat tema som fungerar som dess överordnade.

För en detaljerad guide till underordnade teman, se Undertema.

Tema Stilark

Förutom CSS-stilinformation för ditt tema, erbjuder style.css information om temat i form av kommentarer. Stilarket måste innehålla information om temat i form av kommentarer. Inga två teman är får ha samma uppgifter listade i deras kommentarhuvuden, eftersom detta kommer att leda till problem i dialogrutan Temaval. Om du skapar ditt eget tema genom att kopiera ett befintligt, se till att du först ändrar denna information.

Följande är ett exempel på de första raderna i stilarket, kallat formatmallens rubrik, för temat ”Tjugo tretton”:

OBS: Namnet som används för författaren är föreslog att vara samma som Theme Author ”s wordpress.org användarnamn, även om det också kan vara författarens riktiga namn. Valet är temaförfattaren.

Lägg märke till listan över taggar som används för att beskriva temat. Dessa gör det möjligt för användare att hitta ditt tema med hjälp av taggfiltret. Du kan hitta en fullständig lista i Temagranskningshandboken .

Kommentarhuvudraderna i style.css krävs för att WordPress ska kunna identifiera temat och visa det i administrationspanelen under Design > Teman som ett tillgängligt temalternativ tillsammans med alla andra installerade teman.

Riktlinjer för stilark

• Följ CSS-kodningsstandarder när du skapar din CSS.
• Använd giltig CSS när som undantag, använd leverantörsspecifika prefix för att dra nytta av CSS3-funktioner.
• Minimera CSS-hack. Det uppenbara undantaget är webbläsarspecifikt stöd, vanligtvis versioner av IE. Om möjligt, separera CSS-hack i separata sektioner eller separata filer.
• Alla möjliga HTML-element ska utformas efter ditt tema (såvida det inte är ett underordnat tema), både i inlägg / sidinnehåll och i co Innehåll.
  • Tabeller, bildtexter, bilder, listor, block citat osv.
• Det rekommenderas starkt att lägga till utskriftsvänliga stilar.
  • Du kan inkludera ett utskriftsformat med media = ”print” eller lägga till ett utskriftsmediablock i ditt huvudformat.

Funktionsfil

Ett tema kan valfritt använda en funktionsfil, som finns i underkatalogen för temat och heter names.php. Den här filen fungerar i princip som ett plugin, och om den finns i temat du använder laddas den automatiskt under WordPress-initialiseringen (både för admin-sidor och externa sidor). Föreslagna användningsområden för den här filen:

• Enqueue style stylesheets and scripts. Se wp_enqueue_scripts.
• Aktivera temafunktioner som sidofält, navigeringsmenyer, inläggsminiatyrer, inläggsformat, anpassade rubriker, anpassade bakgrunder och andra.
• Definiera funktioner som används i flera mallfiler i din tema.
• Ställ in en alternativmeny som ger webbplatsägare alternativ för färger, stilar och andra aspekter av ditt tema.

WordPress-temat som standard innehåller funktioner. php-fil som definierar många av dessa funktioner, så du kanske vill använda den som en modell. Eftersom functions.php i princip fungerar som ett plugin, är listan Function_Reference det bästa stället att gå för mer information om vad du kan göra med den här filen.

Observera när du ska bestämma när du ska lägga till funktioner i functions.php eller till ett specifikt plugin: Du kanske upptäcker att du behöver samma funktion för att vara tillgänglig för mer än ett överordnat tema. Om så är fallet bör funktionen skapas i ett plugin istället för en functions.php för det specifika temat. Detta kan inkludera malltaggar och andra specifika funktioner. Funktionerna i plugins kommer att ses av alla teman.

Mallfiler

Mallar är PHP-källfiler som används för att generera de sidor som besökare begär och matas ut som HTML. Mallfiler består av HTML-, PHP- och WordPress-malltaggar.

Låt oss titta på de olika mallarna som kan definieras som en del av ett tema.

WordPress låter dig definiera separata mallar för de olika aspekterna av din webbplats. Det är inte viktigt att ha alla dessa olika mallfiler för att din webbplats ska fungera till fullo. Mallar väljs och genereras baserat på mallhierarkin, beroende på vilka mallar som finns tillgängliga i ett visst tema.

Som tema utvecklare kan du välja hur mycket anpassning du vill implementera med hjälp av mallar. Som ett extremt fall kan du till exempel bara använda en mallfil, kallad index.php som mall för alla sidor som genereras och visas av webbplatsen. vanligare är att olika mallfiler genererar olika resultat för att möjliggöra maximal anpassning.

Mallfiler Lista

Här är listan över de temafiler som erkänns av WordPress. Naturligtvis, ditt tema kan innehålla andra formatmallar, bilder eller filer. Tänk bara på att följande har särskild betydelse för WordPress – se mallhierarki för mer information.

style.css Huvudformatbladet. Detta måste ingå i ditt tema och det måste innehålla informationshuvudet för ditt tema. rtl.css rtl-formatmallen. Detta inkluderas automatiskt om webbplatsens textriktning är från vänster till vänster. Detta kan genereras med hjälp av RTLer-plugin. Index.php Huvudmallen. Om ditt tema tillhandahåller sina egna mallar måste index.php finnas. comments.php Kommentarmallen front-page.php Startsidemallen home.php Startsidemallen, som är förstasidan som standard.Om du använder en statisk förstasida är detta mallen för sidan med de senaste inläggen. single.php Mall för enstaka inlägg. Används när ett enskilt inlägg ifrågasätts. För detta och alla andra frågemallar används index.php om frågemallen inte finns. singel- {posttyp} .php Den enkla postmallen som används när ett enskilt inlägg från en anpassad posttyp frågas. Exempelvis skulle single-book.php användas för att visa enskilda inlägg från den anpassade inläggstypen ”bok”. index.php används om frågemallen för den anpassade inläggstypen inte finns. page.php Sidmallen. Används när en enskild sida frågas. category.php Kategorimallen. Används när en kategori ifrågasätts. tag.php Taggmallen. Används när en tagg ifrågasätts. taxonomy.php Termen mall. Används när en term i en anpassad taxonomi ifrågasätts. author.php Författarmallen. Används när en författare frågas. date.php Mallen för datum / tid. Används när ett datum eller en tid ifrågasätts. År, månad, dag, timme, minut, sekund. archive.php Arkivmallen. Används när en kategori, författare eller datum ifrågasätts. Observera att den här mallen åsidosätts av category.php, author.php och date.php för deras respektive frågetyper. search.php Sökresultatmallen. Används när en sökning utförs. attachment.php Bilaga mall. Används när du visar en enda bilaga. image.php Bilagmall för bild. Används när du visar en enstaka bildbilaga. Om det inte finns kommer attachment.php att användas. 404.php Mallen 404 hittades inte. Används när WordPress inte hittar ett inlägg eller en sida som matchar frågan.

Dessa filer har en speciell betydelse med avseende på WordPress eftersom de används som en ersättning för index.php, när de är tillgängliga, enligt mallhierarkin, och när motsvarande villkorliga tagg returnerar sant. Till exempel, om bara ett enda inlägg visas, returnerar funktionen is_single () ”true”, och om det finns en single.php-fil i det aktiva temat används den mallen för att generera sidan.

Grundläggande mallar

Ett WordPress-tema består åtminstone av två filer:

• style.css
• index.php

Båda dessa filer går in i temakatalogen. Mallfilen index.php är mycket flexibel. Den kan användas för att inkludera alla referenser till sidhuvudet, sidofältet, sidfoten, innehåll, kategorier, arkiv, sökning, fel och andra sidor som skapats i WordPress.

Eller det kan delas in i modulmall filer, var och en tar del av arbetsbelastningen. Om du inte tillhandahåller andra mallfiler kan WordPress ha standardfiler eller funktioner för att utföra sina jobb. Om du till exempel inte tillhandahåller en sökfil.php-mallfil har WordPress en standardfunktion för att visa sökformuläret.

Typiska mallfiler inkluderar:

• kommentarer. php
• comments-popup.php
• footer.php
• header.php
• sidebar.php

Med hjälp av dessa mallfiler kan du placera malltaggar i index.php-huvudfilen för att inkludera dessa andra filer där du vill att de ska visas på den slutliga genererade sidan.

Här är ett exempel på inkludera användning:

<?php get_sidebar(); ?><?php get_footer(); ?>

Standardfilerna för vissa mallfunktioner kan vara föråldrade eller inte, och du bör ange dessa filer i ditt tema. Från och med version 3.0 finns de föråldrade standardfilerna i wp-includes/theme-compat. Till exempel bör du tillhandahålla header.php för att funktionen get_header () ska fungera säkert, och comments.php för funktionen comments_template ().

För mer om hur dessa olika mallar fungerar och hur man genererar olika information i dem, läs malldokumentationen.

Anpassade sidmallar

Filerna som definierar varje sidmall finns i din temakatalog. För att skapa en ny anpassad sidmall för en sida måste du skapa en fil. Låt oss kalla vår första sidmall för vår sida snarfer.php. Överst i snarfer.php-filen lägger du till följande:

<?php/*Template Name: Snarfer*/?>

Ovanstående kod definierar den här snarfer.php-filen som ”Snarfer” -mall. Naturligtvis kan ”Snarfer” ersättas med mest vilken text som helst för att ändra sidmallens namn. Detta mallnamn kommer att visas i temaredigeraren som länk för att redigera denna fil.

Filen kan namnges nästan vad som helst med ett .php-tillägg (se reserverade temafilnamn för filnamn du inte ska använda; dessa är speciella filnamn WordPress reserverar för specifika ändamål).

Vad som följer ovanstående fem rader med kod är upp till dig. Resten av koden du skriver kommer att styra hur sidor som använder Snarfer-sidmallen visas. Se Malltaggar för en beskrivning av de olika WordPress-mallfunktionerna du kan använda för detta ändamål. Det kan vara bekvämare att kopiera en annan mall (kanske page.php eller index.php) till snarfer.php och sedan lägg till ovanstående fem rader kod i början av filen.På så sätt behöver du bara ändra HTML- och PHP-koden istället för att skapa allt från grunden. Exempel visas nedan. När du har skapat en sidmall och placerat den i ditt temakatalog kommer den att vara tillgänglig när du skapar eller redigerar en sida. (Obs! När du skapar eller redigerar en sida visas alternativet Sidmall inte såvida inte det finns minst en mall definierad på ovanstående sätt.)

Frågebaserade mallfiler

WordPress kan ladda olika mallar för olika frågetyper. Det finns två sätt att göra detta: som en del av den inbyggda mallhierarkin och genom användning av villkorliga taggar i slingan för en mallfil.

För att använda mallhierarkin måste du i princip tillhandahålla mallfiler för specialformål, som kommer automatiskt att användas för att åsidosätta index.php. Till exempel, om ditt tema tillhandahåller en mall som heter category.php och en kategori efterfrågas, laddas category.php istället för index.php. Om category.php inte finns, index.php används som vanligt.

Du kan bli ännu mer specifik i mallhierarkin genom att tillhandahålla af ile kallas till exempel category-6.php – den här filen kommer att användas snarare än category.php när du genererar sidan för den kategori vars ID-nummer är 6. (Du hittar kategori-ID-nummer i Hantera > Kategorier om du är inloggad som webbplatsadministratör i WordPress version 2.3 och senare. I WordPress 2.5 togs ID-kolumnen bort från adminpanelerna. Du kan hitta kategori-id genom att klicka på ”Redigera kategori” och leta efter cat_ID-värdet i URL-adressfältet. Det ser ut ”… categories.php? Action = edit & cat_ID = 3” där ”3” är kategori-id). För en mer detaljerad titt på hur denna process fungerar, se Kategorimallar.

Om ditt tema behöver ha ännu mer kontroll över vilka mallfiler som används än vad som finns i mallhierarkin kan du använda villkorlig Taggar. Den villkorliga taggen kontrollerar i princip för att se om ett visst villkor är sant, i WordPress-slingan, och sedan kan du ladda en viss mall eller lägga till en viss text på skärmen baserat på det villkoret.

För exempel, för att skapa ett distinkt formatmall i ett inlägg som bara finns i en viss kategori kan koden se ut så här:

Eller med en fråga kan det se ut så här:

<?php$post = $wp_query->post;if ( in_category( "9" ) ) { get_template_part( "single2" );} else { get_template_part( "single1" );}?>

I båda fallen kommer denna exempelkod att orsaka att olika mallar används beroende på kategorin för det inlägg som visas. Fråga villkor är inte begränsade till kategorier, se dock artikeln Villkorliga taggar för att titta på alla alternativ.

Definiera anpassade mallar

Det är möjligt att använda WordPress-plugin-systemet för att definiera ytterligare mallar som visas baserat på dina egna anpassade kriterier. Denna avancerade funktion kan åstadkommas med hjälp av åtgärdskroken ”template_include”. Mer information om hur du skapar insticksprogram finns i Plugin API-referensen.

Inkluderar mallfiler

För att ladda in en annan mall (annan än sidhuvud, sidofält, sidfot, som har fördefinierade inkluderade kommandon som get_header ()) i en mall kan du använda get_template_part (). Detta gör det enkelt för ett tema att återanvända delar av koden.

Referera till filer från en mall

När du refererar till andra filer inom samma tema, undvik hårdkodade URI-filer och filvägar. Referera istället URI: erna och filvägarna med bloginfo (): se Hänvisa till filer från en mall.

Observera att URI: er som används i formatmallen är relativt formatmallen, inte den sida som refererar till formatmallen. Om du till exempel tar med en bild / katalog i ditt tema behöver du bara ange den här relativa katalogen i CSS, som så:

h1 { background-image: url(images/my-background.jpg);}

Plugin API-krokar

När du utvecklar teman är det bra att komma ihåg att ditt tema ska ställas in så att det kan fungera bra med alla WordPress-plugins som användare kan välja att installera. Plugins lägger till funktioner till WordPress via ”Action Hooks ”(se Plugin API för mer information).

De flesta Action Hooks finns inom WordPress-kärnan för WordPress, så ditt tema behöver inte ha några speciella taggar för att de ska fungera. Men några Action Krokar måste finnas i ditt tema, för att plugins ska kunna visa information direkt i sidhuvudet, sidfoten, sidofältet eller i sidans text. Här är en lista över de speciella taggar för actionkroksmallar du behöver inkludera:

wp_enqueue_scripts Används i temafunktionsfilen. Används för att ladda externa skript och formatmallar. wp_head () Går i < huvud > element i ett tema, i header.php. Exempel på plugin-användning: lägg till JavaScript-kod. wp_footer () Går i footer.php, strax före den avslutande taggen < / body >. Exempel på plugin-användning: infoga PHP-kod som måste köras efter allt annat längst ner i sidfoten.Mycket vanligt för att infoga webbstatistik-kod, till exempel Google Analytics. wp_meta () Går vanligtvis i < li > Meta < / li > avsnitt i ett temas meny eller sidofält; sidebar.php-mall. Exempel på plugin-användning: inkludera en roterande annons eller ett taggmoln. Comment_form () Går i comments.php direkt före filen ” s stängningstagg (< / div >). Exempel på plugin-användning: visa en förhandsgranskning av kommentarer.

För ett exempel på verklig användning kommer du att hitta de här plugin-krokarna som ingår i standardtemaens mallar.

Theme Customization API

Från och med WordPress 3.4, en ny Temainpassningsfunktionen är tillgänglig som standard för nästan alla WordPress-teman. Administratörssidan för temananpassning fylls automatiskt med alternativ som ett tema förklarar stöd för med add_theme_support () eller med hjälp av inställnings-API: et, och tillåter administratörer att se icke-permanenta förhandsgranskningar av ändringar de gör i realtid.

Tema- och pluginutvecklare som är intresserade av att lägga till nya alternativ till temas temat anpassningssida bör se dokumentationen på Theme Customization API. Ytterligare tutorials om Theme Customization API finns på Ottopress.com webbplats.

Otillförlitliga data

Du bör fly dynamiskt genererat innehåll i ditt tema, särskilt innehåll som skickas till HTML-attribut. Som noteras i WordPress-kodningsstandarder ska text som går in i attribut köras genom esc_attr () så att enstaka eller dubbla citat slutar inte attributvärdet och ogiltigförklarar XHTML och orsakar ett säkerhetsproblem. Vanliga platser att kontrollera är attribut för titel, alt och värde.

Det finns få speciella malltaggar för vanliga fall där en säker utgång behövs. Ett sådant fall innebär att man lägger ut en inläggstitel till ett titelattribut med_title_attribute () istället för_title () för att undvika en säkerhetsproblem. Här är ett exempel på korrekt flykt för titelattributet för en posttitelänk när du använder översättbar text:

<a href="<?php the_permalink(); ?>" title="<?php sprintf( __( "Permanent Link to %s", "theme-name" ), the_title_attribute( "echo=0" ) ); ?>"><?php the_title(); ?></a>

Översättningsstöd / I18n

För att säkerställa en smidig övergång för språklokalisering, använd de WordPress gettextbaserade i18n-funktionerna för att slå in all översättbar text i mallfilerna. Detta gör det lättare för översättningsfilerna att koppla in och översätta etiketter, titlar och annan malltext till webbplatsens aktuella språk. Se mer på WordPress Localization och I18n för WordPress-utvecklare.

Temakurser

Implementera följande malltaggar för att lägga till WordPress-genererade klassattribut till kropps-, inläggs- och kommentarelement. För postklasser gäller endast element inom The Loop.

• body_class ()
• post_class ()
• comment_class ()

Mallfilchecklista

När du utvecklar ett tema, kontrollera dina mallfiler mot följande mallfilstandarder.

Dokumenthuvud (header.php)

• Använd rätt DOCTYPE.
• Den inledande < html > -taggen bör innehålla språkattribut (
• < meta > charset-elementet bör placeras före allt annat, inklusive < title > element.
• Använd bloginfo () för att ställa in < meta > teckenuppsättning och beskrivningselement.
• Använd wp_title () för att ställa in < titel > -element. Se varför.
• Använd automatiska feedlänkar för att lägga till feedlänkar.
• Lägg till ett samtal till wp_head () innan den avslutande < / head > -tagg. Plugins använder den här åtgärdskroken för att lägga till egna skript, formatmallar och annan funktionalitet.
• Länka inte temastilbladen i rubrikmallen. Använd actionkroken wp_enqueue_scripts i en temafunktion istället.

Här är ett exempel på ett korrekt formaterat HTML5-kompatibelt huvudområde:

Navigationsmenyer (header.php )

• Temans huvudnavigering bör stödja en anpassad meny med wp_nav_menu ().
  • Menyer bör stödja långa länktitlar och en stor mängd listobjekt. Dessa objekt ska inte bryta mot design eller layout.
  • Undermenyobjekt ska visas korrekt. Stöd om möjligt rullgardinsmenyformat för undermenyalternativ. Nedrullningar som visar menydjup i stället för att bara visa toppnivån.

• Temat bör widgetiseras så fullt som möjligt. Varje område i layouten som fungerar som en widget (taggmoln, blogg, kategorilista) eller som kan acceptera widgets (sidofält) bör tillåta widgets.
• Innehåll som visas i widgetiserade områden som standard (hårdkodat) i sidofältet, till exempel) bör försvinna när widgets är aktiverade från Utseende > Widgets.

Sidfot (sidfot.php)

• Använd wp_footer () -samtalet för att visas precis innan du stänger body-taggen.

<?php wp_footer(); ?></body></html>

Index (index.php)

• Visa en lista med inlägg i utdrag eller i fullformat. Välj den ena eller den andra efter behov.
• Inkludera wp_link_pages () för att stödja navigeringslänkar i inlägg.

Arkiv (archive.php)

• Visa arkivnamn (tagg, kategori, datumbaserat eller författararkiv).
• Visa en lista med inlägg i utdrag eller i full längd. Välj en eller annan efter behov.
• Inkludera wp_link_pages () för att stödja navigeringslänkar i inlägg.

Sidor (page.php)

• Visa sidtitel och sidinnehåll.
• Visa kommentarlista och kommentarformulär (såvida inte kommentarer är avstängda).
• Inkludera wp_link_pages () för att stödja navigeringslänkar på en sida.
• Metadata som taggar, kategorier, datum och författare ska inte visas.
• Visa en ”Redigera” -länk för inloggade användare med redigeringsbehörigheter.

Enkelt inlägg (single.php)

• Inkludera wp_link_pages () för att stödja navigeringslänkar i ett inlägg.
• Visa inläggstitel och inläggsinnehåll.
  • Titeln ska vara ren text istället för en länk som pekar på sig själv.
• Visa postdatum.
  • Respektera inställningarna för datum och tidsformat såvida det inte är viktigt för designen. (Användarinställningar för datum- och tidsformat finns i administrationspaneler > Inställningar Allmänt).
  • För utdata baserat på användarinställningen, använd_tid (get_option (”date_format”)).
• Visa författarens namn (om tillämpligt).
• Visa inläggskategorier och inläggstaggar.
• Visa en ”Redigera” -länk för inloggade användare med redigeringsbehörigheter.
• Visa kommentarlista och kommentarformulär.
• Visa navigeringslänkar till nästa och föregående inlägg med föregående_post_link () och next_post_link ().

• Författarkommentar bör markeras annorlunda.
• Visa gravatarer (användaravatarer) om så är lämpligt.
• Stöd gängade kommentarer.
• Visa trackbacks / pingbacks.
• Den här filen bör inte innehålla funktionsdefinitioner såvida inte i funktion_exist () kryss för att undvika redeklarationsfel. Helst bör alla funktioner vara i funktioner.php.

Sökresultat (search.php)

JavaScript

• JavaScript-kod bör vara placeras i externa filer när det är möjligt.
• Använd wp_enqueue_script () för att ladda dina skript.
• JavaScript som laddats direkt i HTML-dokument (mallfiler) ska vara CDATA-kodad för att förhindra fel i äldre webbläsare. .

<script type="text/javascript">/* <!]> */</script>

Skärmdump

Skapa en skärmdump för ditt tema. Skärmdumpen ska ha namnet screenshot.png och ska placeras i katalogen på översta nivån. Skärmdumpen bör visa temat design exakt och sparas i PNG-format. Medan .jpg, .jpeg och .gif också är giltiga tillägg och filformat för skärmdumpen rekommenderas de inte.

Den rekommenderade bildstorleken är 1200px bred och 900px hög. Skärmdumpen visas vanligtvis mindre men den överdimensionerade bilden möjliggör högupplöst visning på HiDPI-skärmar. Observera att eftersom skärmen Hantera teman är lyhörd kan den övre och nedre delen av skärmdumpbilden inte visas, så håll grafik nära mitten.

Temalternativ

Teman kan valfritt stödja Tema Anpassa skärmen. För en exempelkod, se En Exempelsida för WordPress-temalternativ.

När du aktiverar tillgängligheten för teman Anpassningsskärm för en användarroll, använd användarfunktionen ”edit_theme_options” istället för ”switch_themes” om inte användarrollen borde faktiskt också kunna byta tema. Se mer på Roller och funktioner och lägga till administrationsmenyer.

Om du använder ”edit_themes” -funktionen var som helst i ditt tema för att få administratörsrollen tillgång till teman Anpassa skärmen (eller kanske vissa anpassade skärmar), var medveten om att sedan version 3.0 har denna funktion inte tilldelats administratörsrollen som standard när det gäller WordPress Multisite-installation. Se förklaringen. I sådana fall använder du istället funktionen ”edit_theme_options” om du vill att administratören ska se menyn ”Theme Options”. Se ytterligare funktioner för administratörsrollen när du använder WordPress Multisite.

Tematestningsprocess

1. Åtgärda PHP- och WordPress-fel. Lägg till följande felsökningsinställning i din wp-config.php-fil för att se föråldrade funktionsanrop och andra WordPress-relaterade fel: definiera (”WP_DEBUG”, sant) ;. Se Föråldrade funktionshake för mer information.
2. Kontrollera mallfiler mot mallfilchecklistan (se ovan).
3. Gör en genomkörning med tematenhetstestet.
4. Validera HTML och CSS. Se Validera en webbplats.
5. Sök efter JavaScript-fel.
6. Testa i alla dina målwebbläsare. Till exempel IE9, Safari, Chrome, Opera, Firefox och Microsoft Edge.
7. Rensa upp eventuella yttre kommentarer, felsökningsinställningar eller TODO-objekt.
8. Se Temagranskning om du är offentligt släppa temat genom att skicka det till temakatalogen.

Resurser och referenser

Kodstandarder

• Känn dina källor
• WordPress-kodningsstandarder
• CSS-kodningsstandarder

Temadesign

• Webbplatsdesign och layout

CSS

• CSS
• CSS Shorthand
• WordPress-genererade klasser

Mallar

• Stega in i mallar
• Mallar
• Mallhierarki
• Malltaggar
• The Loop
• Villkorliga taggar
• Funktionsreferens
• I18n för WordPress-utvecklare
• Datavalidering

Funktionslista

• Funktionsreferens

Testning och QA

• Temainhet Te st
• Validera en webbplats
• CSS Fixing Browser Bugs
• CSS Felsökning
• modern.IE: för testning av IE på olika plattformar med öppen -källverktyg

Släpp & Kampanj

• Temagranskningsprocess