Talen: বাংলা • Engels • Español • 日本語 한국어 • Português do Brasil • Русский • 中文 (简体) •中文 (繁體) • (Voeg uw taal toe)

Dit artikel gaat over het ontwikkelen van WordPress-thema’s. Als u meer wilt weten over het installeren en gebruiken van thema’s, bekijk dan Thema’s gebruiken. Dit onderwerp verschilt van Thema’s gebruiken omdat het bespreekt de technische aspecten van het schrijven van code om uw eigen thema’s te bouwen in plaats van hoe u thema’s kunt activeren of waar u nieuwe thema’s kunt verkrijgen.

Waarom WordPress-thema’s

WordPress-thema’s zijn bestanden die samenwerken om het ontwerp en de functionaliteit van een WordPress-site te creëren. Elk thema kan anders zijn en biedt veel keuzes voor site-eigenaren om het uiterlijk van hun website onmiddellijk te veranderen.

Misschien wilt u WordPress-thema’s ontwikkelen voor uw eigen gebruik, voor een klantproject of om in te dienen bij de WordPress Theme Directory. Waarom zou u anders een WordPress-thema bouwen?

• Om een unieke look te creëren voor uw WordPress-site.
• Om te profiteren van sjablonen, sjabloontags en de WordPress Loop om verschillende websiteresultaten en uiterlijk te genereren.
• Om alternatieve sjablonen te bieden voor specifieke sitefuncties, zoals als categoriepagina’s en pagina’s met zoekresultaten.
• Om snel te schakelen tussen twee sitelay-outs of om te profiteren van een thema- of stijlwisselaar waarmee site-eigenaren het uiterlijk van uw site kunnen wijzigen.

Een WordPress-thema heeft ook veel voordelen.

• Het scheidt de presentatiestijlen en sjabloonbestanden van de systeembestanden, zodat de site zal upgraden zonder drastische wijzigingen in de visuele presentatie van de site.
• Het maakt aanpassing van de sitefunctie mogelijk die uniek is voor dat thema.
• Het maakt snelle veranderingen van het visuele ontwerp en de lay-out van een WordPress-site mogelijk.
• Het elimineert de noodzaak voor een typische WordPress-site-eigenaar om CSS, HTML en PHP te moeten leren om een goed uitziende website te hebben.

Waarom zou je je eigen WordPress-thema bouwen? Dat is de echte vraag.

• Het is een kans om meer te leren over CSS, HTML en PHP.
• Het is een kans om je expertise in te zetten CSS, HTML en PHP werken.
• Het is creatief.
• Het is leuk (meestal).
• Als je het vrijgeeft aan het publiek, kun je een goed gevoel hebben dat je iets hebt gedeeld en iets hebt teruggegeven aan de WordPress-gemeenschap (oké, opscheppen)

Standaarden voor thema-ontwikkeling

WordPress-thema’s zouden moeten zijn gecodeerd volgens de volgende standaarden:

• Gebruik goed gestructureerde, foutloze PHP en geldige HTML. Zie WordPress Coding Standards.
• Gebruik schone, geldige CSS. Zie CSS-codering Standaarden.
• Volg de ontwerprichtlijnen in het ontwerp en de lay-out van de site.

Anatomie van een thema

WordPress-thema’s leven in submappen van de map met WordPress-thema’s (standaard wp-content / themes /) die niet direct kan worden verplaatst met het bestand wp-config.php. De submap van het thema bevat alle stijlen van het thema eet-bestanden, sjabloonbestanden en optionele functiebestanden (functions.php), JavaScript-bestanden en afbeeldingen. Een thema met de naam “test” zou bijvoorbeeld in de directory wp-content / themes / test / staan. Gebruik geen cijfers voor de themanaam, omdat dit voorkomt dat deze wordt weergegeven in de lijst met beschikbare thema’s.

WordPress bevat een standaardthema in elke nieuwe installatie. Bekijk de bestanden in het standaardthema zorgvuldig om een beter idee te krijgen van hoe u uw eigen themabestanden kunt maken.

Zie deze infographic over WordPress Theme Anatomy voor een visuele gids.

WordPress Thema’s bestaan doorgaans uit drie hoofdtypen bestanden, naast afbeeldingen en JavaScript-bestanden.

1. De stylesheet genaamd style.css, die de presentatie (visueel ontwerp en lay-out) van de webpagina’s bestuurt.
2. WordPress-sjabloonbestanden die bepalen hoe de sitepagina’s de informatie uit uw WordPress-database genereren om op de site weer te geven.
3. Het optionele functiebestand (functions.php) als onderdeel van de WordPress-themabestanden.

Laten we deze afzonderlijk bekijken.

Kindthema’s

Het eenvoudigste thema is een kindthema dat alleen een style.css bevat bestand, plus eventuele afbeeldingen. Dit is mogelijk omdat het een kind is van een ander thema dat als ouder fungeert.

Voor een gedetailleerde gids over onderliggende thema’s, zie Onderliggende thema’s.

Thema Stylesheet

Naast CSS-stijlinformatie voor uw thema, biedt style.css details over het thema in de vorm van opmerkingen. De stylesheet moet details over het thema bevatten in de vorm van opmerkingen. Er zijn geen twee thema’s mogen dezelfde details in hun comment-headers hebben, omdat dit tot problemen zal leiden in het themaselectiedialoogvenster.Als u uw eigen thema maakt door een bestaand thema te kopiëren, moet u deze informatie eerst wijzigen.

Het volgende is een voorbeeld van de eerste paar regels van het stylesheet, de stylesheet-header genoemd, voor het thema “Twenty Thirteen”:

NB: De naam die wordt gebruikt voor de auteur is voorgesteld om hetzelfde te zijn als de wordpress.org gebruikersnaam van de Theme Author, hoewel het ook de echte naam van de auteur kan zijn. De keuze is de thema-auteur.

Let op de lijst met tags die worden gebruikt om het thema te beschrijven. Hiermee kan de gebruiker uw thema vinden met behulp van het tagfilter. U vindt een volledige lijst in het Theme Review Handbook .

De commentaarkopregels in style.css zijn vereist voor WordPress om het thema te kunnen identificeren en weer te geven in het beheerpaneel onder Design > Thema’s als een beschikbare thema-optie samen met andere geïnstalleerde thema’s.

Richtlijnen voor stylesheets

• Volg CSS-coderingsnormen bij het schrijven van uw CSS.
• Gebruik geldige CSS wanneer mogelijk. Gebruik als uitzondering leverancierspecifieke voorvoegsels om te profiteren van CSS3-functies.
• Minimaliseer CSS-hacks. De voor de hand liggende uitzondering is browserspecifieke ondersteuning, meestal versies van IE. Scheid indien mogelijk CSS-hacks in afzonderlijke secties of afzonderlijke bestanden.
• Alle mogelijke HTML-elementen moeten worden gestileerd door uw thema (tenzij het een child-thema is), zowel in post- / pagina-inhoud als in co inhoud.
  • Tabellen, bijschriften, afbeeldingen, lijsten, blokcitaten, enzovoort.
• Het toevoegen van afdrukvriendelijke stijlen wordt sterk aanbevolen.
  • U kunt een afdrukstijlblad met media = “print” toevoegen of een afdrukmediablok toevoegen aan uw hoofdstijlblad.

Functiebestand

Een thema kan optioneel een functiebestand gebruiken, dat zich in de subdirectory van het thema bevindt en de naam functions.php heeft. Dit bestand werkt in feite als een plug-in, en als het aanwezig is in het thema dat u gebruikt, wordt het automatisch geladen tijdens de initialisatie van WordPress (zowel voor admin-pagina’s als voor externe pagina’s). Aanbevolen toepassingen voor dit bestand:

• Zet thema-stylesheets en scripts in de wachtrij. Zie wp_enqueue_scripts.
• Schakel themafuncties in, zoals zijbalken, navigatiemenu’s, postminiaturen, postformaten, aangepaste kopteksten, aangepaste achtergronden en andere.
• Definieer functies die worden gebruikt in verschillende sjabloonbestanden van uw thema.
• Stel een optiemenu in, dat site-eigenaren opties geeft voor kleuren, stijlen en andere aspecten van uw thema.

Het standaard WordPress-thema bevat functies. php-bestand dat veel van deze functies definieert, dus misschien wilt u het als een model gebruiken. Aangezien functions.php in feite functioneert als een plug-in, is de lijst Function_Reference de beste plaats voor meer informatie over wat u met dit bestand kunt doen.

Opmerking om te beslissen wanneer functies moeten worden toegevoegd aan functions.php of naar een specifieke plug-in: het kan zijn dat je dezelfde functie nodig hebt om beschikbaar te zijn voor meer dan één hoofdthema. Als dat het geval is, moet de functie worden gemaakt in een plug-in in plaats van een functions.php voor het specifieke thema. Dit kunnen sjabloontags en andere specifieke functies zijn. Functies in plug-ins zullen door alle thema’s worden gezien.

Sjabloonbestanden

Sjablonen zijn PHP-bronbestanden die worden gebruikt om de pagina’s te genereren die door bezoekers worden opgevraagd, en worden uitgevoerd als HTML. Sjabloonbestanden bestaan uit HTML-, PHP- en WordPress-sjabloontags.

Laten we eens kijken naar de verschillende sjablonen die kunnen worden gedefinieerd als onderdeel van een thema.

Met WordPress kunt u afzonderlijke sjablonen definiëren voor de verschillende aspecten van uw site. Dat is niet zo echter essentieel om al deze verschillende sjabloonbestanden te hebben zodat uw site volledig functioneert. Sjablonen worden gekozen en gegenereerd op basis van de sjabloonhiërarchie, afhankelijk van welke sjablonen beschikbaar zijn in een bepaald thema.

Als een thema ontwikkelaar, kunt u de mate van aanpassing kiezen die u wilt implementeren met behulp van sjablonen. In het uiterste geval kunt u bijvoorbeeld slechts één sjabloonbestand, genaamd index.php, gebruiken als sjabloon voor alle pagina’s die door de site worden gegenereerd en weergegeven. gebruikelijker is om verschillende sjabloonbestanden verschillende resultaten te laten genereren, om maximale aanpassing mogelijk te maken.

Lijst met sjabloonbestanden

Hier is de lijst met de themabestanden die door WordPress worden herkend. uw thema kan andere stylesheets, afbeeldingen of bestanden bevatten. Houd er rekening mee dat de volgende hebben een speciale betekenis voor WordPress – zie sjabloonhiërarchie voor meer informatie.

style.css Het hoofdstijlblad. Dit moet bij uw thema zijn geleverd en het moet de informatiekop voor uw thema bevatten. rtl.css Het rtl-stylesheet. Dit wordt automatisch opgenomen als de tekstrichting van de website van rechts naar links is. Dit kan worden gegenereerd met behulp van de RTLer-plug-in. Index.php De hoofdsjabloon. Als uw thema zijn eigen sjablonen biedt, moet index.php aanwezig zijn. comments.php De sjabloon voor opmerkingen front-page.php De sjabloon voor de voorpagina home.php De sjabloon voor de startpagina, dit is standaard de voorpagina.Als u een statische voorpagina gebruikt, is dit de sjabloon voor de pagina met de laatste berichten. single.php De sjabloon voor één bericht. Wordt gebruikt wanneer een enkel bericht wordt opgevraagd. Voor deze en alle andere querysjablonen wordt index.php gebruikt als de querysjabloon niet aanwezig is. single- {post-type} .php Het sjabloon voor één bericht dat wordt gebruikt wanneer een enkel bericht van een aangepast berichttype wordt opgevraagd. Single-book.php zou bijvoorbeeld worden gebruikt voor het weergeven van enkele berichten van het aangepaste berichttype genaamd “boek”. index.php wordt gebruikt als het querysjabloon voor het aangepaste berichttype niet aanwezig is. page.php Het paginasjabloon. Wordt gebruikt wanneer een individuele pagina wordt opgevraagd. category.php Het categorie-sjabloon. Wordt gebruikt wanneer een categorie wordt opgevraagd. tag.php Het tag-sjabloon. Wordt gebruikt wanneer een tag wordt opgevraagd. taxonomy.php De term template. Wordt gebruikt wanneer een term in een aangepaste taxonomie wordt opgevraagd. author.php De auteurssjabloon. Wordt gebruikt wanneer een auteur wordt gevraagd. date.php De datum / tijd-sjabloon. Wordt gebruikt wanneer een datum of tijd wordt opgevraagd. Jaar, maand, dag, uur, minuut, seconde. archive.php Het archiefsjabloon. Wordt gebruikt wanneer een categorie, auteur of datum wordt opgevraagd. Merk op dat dit sjabloon zal worden overschreven door category.php, author.php en date.php voor hun respectievelijke typen zoekopdrachten. search.php Het sjabloon voor zoekresultaten. Wordt gebruikt wanneer een zoekopdracht wordt uitgevoerd. attachment.php Bijlage-sjabloon. Wordt gebruikt bij het bekijken van een enkele bijlage. image.php Sjabloon voor afbeeldingbijlagen. Wordt gebruikt bij het bekijken van een enkele afbeeldingsbijlage. Indien niet aanwezig, wordt attachment.php gebruikt. 404.php De sjabloon 404 Niet gevonden. Wordt gebruikt wanneer WordPress een bericht of pagina niet kan vinden die overeenkomt met de zoekopdracht.

Deze bestanden hebben een speciale betekenis met betrekking tot WordPress omdat ze worden gebruikt als vervanging voor index.php, indien beschikbaar, volgens de sjabloonhiërarchie, en wanneer de bijbehorende voorwaardelijke tag true retourneert. Als er bijvoorbeeld slechts één bericht wordt weergegeven, retourneert de functie is_single () “true”, en als er een enkel.php-bestand in het actieve thema is, wordt dat sjabloon gebruikt om de pagina te genereren.

Basissjablonen

Op zijn minst bestaat een WordPress-thema uit twee bestanden:

• style.css
• index.php

Beide bestanden gaan naar de themamap. Het sjabloonbestand index.php is erg flexibel. Het kan worden gebruikt om alle verwijzingen naar de koptekst, zijbalk, voettekst, inhoud, categorieën, archieven, zoeken, fouten en elke andere pagina die in WordPress is gemaakt op te nemen.

Of het kan worden onderverdeeld in modulaire sjablonen bestanden, die elk een deel van de werklast op zich nemen. Als u geen andere sjabloonbestanden verstrekt, heeft WordPress mogelijk standaardbestanden of -functies om hun taken uit te voeren. Als u bijvoorbeeld geen searchform.php-sjabloonbestand opgeeft, heeft WordPress een standaardfunctie om het zoekformulier weer te geven.

Typische sjabloonbestanden zijn:

• commentaren. php
• comments-popup.php
• footer.php
• header.php
• zijbalk.php

Met behulp van deze sjabloonbestanden kunt u sjabloontags in het index.php-hoofdbestand plaatsen om deze andere bestanden op te nemen waar u ze wilt laten verschijnen op de uiteindelijk gegenereerde pagina.

Hier is een voorbeeld van de inclusief gebruik:

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

De standaardbestanden voor sommige sjabloonfuncties kunnen verouderd of niet aanwezig zijn, en u moet deze bestanden in uw thema opgeven. Vanaf versie 3.0 bevinden de verouderde standaardbestanden zich in wp-includes/theme-compat. U moet bijvoorbeeld header.php opgeven voor de functie get_header () om veilig te werken, en comments.php voor de functie comments_template ().

Voor meer informatie over hoe deze verschillende sjablonen werken en hoe u verschillende informatie daarin vindt u in de sjablonen-documentatie.

Aangepaste paginasjablonen

De bestanden die elk paginasjabloon definiëren, zijn te vinden in uw themamap. Om een nieuwe aangepaste paginasjabloon voor een pagina te maken, moet u een bestand maken. Laten we onze eerste paginasjabloon voor onze pagina snarfer.php noemen. Plaats bovenaan het snarfer.php-bestand het volgende:

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

Het bovenstaande code definieert dit snarfer.php-bestand als het “Snarfer” -sjabloon. Uiteraard kan “Snarfer” worden vervangen door vrijwel elke tekst om de naam van het paginasjabloon te wijzigen. Deze sjabloonnaam zal in de Theme Editor verschijnen als de link om dit te bewerken bestand.

Het bestand kan bijna alles heten met een .php-extensie (zie gereserveerde themabestandsnamen voor bestandsnamen die u niet zou moeten gebruiken; dit zijn speciale bestandsnamen die WordPress reserveert voor specifieke doeleinden).

Wat volgt op de bovenstaande vijf regels code is aan jou. De rest van de code die je schrijft, bepaalt hoe pagina’s die de Snarfer-paginasjabloon gebruiken, worden weergegeven. Zie Sjabloontags voor een beschrijving van de verschillende WordPress-sjabloonfuncties die u voor dit doel kunt gebruiken. Misschien vindt u het handiger om een andere sjabloon (bijvoorbeeld page.php of index.php) naar snarfer.php te kopiëren en vervolgens voeg de bovenstaande vijf regels code toe aan het begin van het bestand.Op die manier hoeft u alleen de HTML- en PHP-code te wijzigen, in plaats van alles helemaal opnieuw te maken. Hieronder vindt u voorbeelden. Nadat u een paginasjabloon heeft gemaakt en deze in de directory van uw thema heeft geplaatst, is deze beschikbaar als keuze wanneer u een pagina maakt of bewerkt. (Opmerking: bij het maken of bewerken van een pagina wordt de optie Paginasjabloon niet weergegeven tenzij er is ten minste één sjabloon gedefinieerd op de bovenstaande manier.)

Op zoekopdrachten gebaseerde sjabloonbestanden

WordPress kan verschillende sjablonen laden voor verschillende soorten zoekopdrachten. Er zijn twee manieren om dit te doen: als onderdeel van de ingebouwde sjabloonhiërarchie, en door het gebruik van voorwaardelijke tags binnen The Loop van een sjabloonbestand.

Om de sjabloonhiërarchie te gebruiken, moet u in principe sjabloonbestanden voor speciale doeleinden wordt automatisch gebruikt om index.php te overschrijven. Als uw thema bijvoorbeeld een sjabloon biedt met de naam category.php en een categorie wordt opgevraagd, wordt category.php geladen in plaats van index.php. Als category.php niet aanwezig is, index.php wordt zoals gewoonlijk gebruikt.

U kunt nog specifieker worden in de sjabloonhiërarchie door af ile genaamd, bijvoorbeeld categorie-6.php – dit bestand wordt gebruikt in plaats van category.php bij het genereren van de pagina voor de categorie waarvan het ID-nummer 6 is. (U kunt categorie-ID-nummers vinden in Beheren > Categorieën als u bent ingelogd als sitebeheerder in WordPress versie 2.3 en lager. In WordPress 2.5 is de ID-kolom verwijderd uit de Admin-panelen. U kunt het categorie-ID vinden door op “Categorie bewerken” te klikken en in de URL-adresbalk naar de cat_ID-waarde te zoeken. Het ziet eruit als “… categories.php? Action = edit & cat_ID = 3” waarbij “3” de categorie-id is). Voor een meer gedetailleerde kijk op hoe dit proces werkt, zie Categorie-sjablonen.

Als je thema nog meer controle moet hebben over welke sjabloonbestanden worden gebruikt dan wat wordt geboden in de sjabloonhiërarchie, kun je voorwaardelijk gebruiken Tags. De voorwaardelijke tag controleert in feite of een bepaalde voorwaarde waar is, binnen de WordPress Loop, en dan kun je een bepaalde sjabloon laden of een bepaalde tekst op het scherm plaatsen, op basis van die voorwaarde.

Voor Om bijvoorbeeld een onderscheidend stylesheet te genereren in een bericht dat alleen in een specifieke categorie wordt gevonden, kan de code er als volgt uitzien:

Of, met behulp van een zoekopdracht, kan het er zo uitzien:

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

In beide gevallen zorgt deze voorbeeldcode ervoor dat verschillende sjablonen worden gebruikt, afhankelijk van de categorie van het specifieke bericht dat wordt weergegeven. Queryvoorwaarden zijn niet beperkt tot categorieën, maar zie het artikel voorwaardelijke tags om alle opties te bekijken.

Aangepaste sjablonen definiëren

Het is mogelijk om het WordPress-plug-insysteem te gebruiken om aanvullende sjablonen die worden weergegeven op basis van uw eigen aangepaste criteria. Deze geavanceerde functie kan worden bereikt met behulp van de actiehaak “template_include”. Meer informatie over het maken van plug-ins is te vinden in de Plugin API-referentie.

Inclusief sjabloonbestanden

Om een andere sjabloon te laden (anders dan koptekst, zijbalk, voettekst, die vooraf gedefinieerde inbegrepen commando’s hebben zoals get_header ()) in een sjabloon, kunt u get_template_part () gebruiken. Dit maakt het gemakkelijk voor een thema om secties van code opnieuw te gebruiken.

Verwijzen naar bestanden vanuit een sjabloon

Wanneer u naar andere bestanden binnen hetzelfde thema verwijst, vermijd dan hardgecodeerde URI’s en bestandspaden. Verwijs in plaats daarvan naar de URI’s en bestandspaden met bloginfo (): zie Verwijzen naar bestanden vanuit een sjabloon.

Merk op dat URI’s die in de stylesheet worden gebruikt, relatief zijn ten opzichte van de stylesheet, niet de pagina die naar de stylesheet verwijst. Als u bijvoorbeeld een afbeeldingen / map in uw thema opneemt, hoeft u alleen deze relatieve map in de CSS op te geven, zoals:

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

Plugin API Hooks

Bij het ontwikkelen van thema’s is het goed om in gedachten te houden dat uw thema zo moet worden ingesteld dat het goed kan werken met alle WordPress-plug-ins die gebruikers willen installeren. Plug-ins voegen functionaliteit toe aan WordPress via “Action Hooks “(zie Plugin API voor meer informatie).

De meeste Action Hooks bevinden zich in de PHP-kerncode van WordPress, dus je Theme hoeft geen speciale tags te hebben om ze te laten werken. Maar een paar Action Hooks moeten aanwezig zijn in uw thema, zodat plug-ins informatie rechtstreeks in uw koptekst, voettekst, zijbalk of in de hoofdtekst van de pagina kunnen weergeven. Hier is een lijst met de speciale Action Hook-sjabloontags die u moet opnemen:

wp_enqueue_scripts Gebruikt in het themafunctiesbestand. Wordt gebruikt om externe scripts en stylesheets te laden. wp_head () Gaat in de < head > element van een thema, in header.php. Voorbeeld plugin gebruik: JavaScript-code toevoegen. wp_footer () Gaat in footer.php, net voor de afsluitende < / body > tag. Voorbeeld van gebruik van plug-ins: voeg PHP-code in die na al het andere moet worden uitgevoerd, onder aan de voettekst.Wordt vaak gebruikt om code voor webstatistieken in te voegen, zoals Google Analytics. wp_meta () Gaat meestal in de < li > Meta < / li > sectie van het menu of de zijbalk van een thema; sidebar.php-sjabloon. Voorbeeld van gebruik van plug-ins: voeg een roterende advertentie of een tagwolk toe. Comment_form () Gaat in comments.php direct voor het bestand ” s afsluitende tag (< / div >). Voorbeeld van gebruik van plug-ins: toon een commentaarvoorbeeld.

Voor een echt gebruiksvoorbeeld, vindt u deze plug-in-hooks in de standaard sjablonen van Theme.

Theme Customization API

Vanaf WordPress 3.4 is er een nieuwe De thema-aanpassingsfunctie is standaard beschikbaar voor bijna alle WordPress-thema’s. De Beheerpagina voor Thema-aanpassing wordt automatisch gevuld met opties waarvoor een thema ondersteuning verklaart met add_theme_support () of met behulp van de Instellingen API, en stelt beheerders in staat om niet-permanente voorbeelden te zien van wijzigingen die ze in realtime hebben aangebracht.

Thema- en plug-in-ontwikkelaars die nieuwe opties willen toevoegen aan de Theme Customization-pagina van een thema, moeten de documentatie over de Theme Customization API raadplegen. Aanvullende tutorials over de Theme Customization API zijn beschikbaar op de website van Ottopress.com.

Niet-vertrouwde gegevens

U moet dynamisch gegenereerde inhoud in uw thema ontsnappen, vooral inhoud die wordt uitgevoerd naar HTML-attributen. Zoals opgemerkt in WordPress Coding Standards, moet tekst die in attributen gaat, door esc_attr () worden doorlopen, zodat enkele of dubbele aanhalingstekens eindigen de attribuutwaarde niet en maken de XHTML ongeldig en veroorzaken een beveiligingsprobleem. Veelvoorkomende plaatsen om te controleren zijn title-, alt- en value-attributen.

Er zijn enkele speciale sjabloontags voor veelvoorkomende gevallen waarin De veilige output is nodig. Een voorbeeld van zo’n geval is het uitvoeren van een posttitel naar een titelattribuut met behulp van the_title_attribute () in plaats van the_title () om een beveiligingsprobleem te vermijden. Hier is een voorbeeld van correct escapen voor het title-attribuut van een posttitellink bij gebruik van vertaalbare tekst:

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

Vertaalondersteuning / I18n

Om een soepele overgang voor taallokalisatie te garanderen, gebruikt u de WordPress gettext-gebaseerde i18n-functies om alle vertaalbare tekst in de sjabloonbestanden te laten omhullen. Dit maakt het gemakkelijker voor de vertaalbestanden om de labels, titels en andere sjabloontekst te vertalen naar de huidige taal van de site. Zie meer op WordPress-lokalisatie en I18n voor WordPress-ontwikkelaars.

Themaklassen

Implementeer de volgende sjabloontags om door WordPress gegenereerde klassenattributen toe te voegen aan hoofd-, post- en commentaarelementen. Pas voor postklassen alleen toe op elementen in The Loop.

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

Checklist sjabloonbestanden

Controleer bij het ontwikkelen van een thema uw sjabloonbestanden aan de hand van de volgende sjabloonbestandsstandaarden.

Documentkop (header.php)

• Gebruik de juiste DOCTYPE.
• De openingstag < html > moet taalattributen ( ).
• Het < meta > charset-element moet voor al het andere worden geplaatst, inclusief het < title > element.
• Gebruik bloginfo () om de < meta in te stellen > tekenset en beschrijvingselementen.
• Gebruik wp_title () om de < titel -element. Kijk waarom.
• Gebruik automatische feedlinks om feedlinks toe te voegen.
• Voeg een aanroep toe aan wp_head () vóór de afsluitende < / head > -tag. Plug-ins gebruiken deze actiehaak om hun eigen scripts, stylesheets en andere functionaliteit toe te voegen.
• Koppel de themastijlbladen niet in de header-sjabloon. Gebruik in plaats daarvan de actie-hook wp_enqueue_scripts in een themafunctie.

Hier is een voorbeeld van een correct opgemaakt HTML5-compatibel kopgebied:

Navigatiemenu’s (header.php )

• De hoofdnavigatie van het thema zou een aangepast menu moeten ondersteunen met wp_nav_menu ().
  • Menu’s zouden lange linktitels en een groot aantal lijstitems moeten ondersteunen. Deze items mogen het ontwerp of de lay-out niet verstoren.
  • Submenu-items moeten correct worden weergegeven. Ondersteun indien mogelijk vervolgkeuzemenu-stijlen voor submenu-items. Vervolgkeuzelijsten maken het mogelijk de menudiepte weer te geven in plaats van alleen het hoogste niveau weer te geven.

• Het thema moet zo volledig mogelijk in widgets worden weergegeven. Elk gebied in de lay-out dat werkt als een widget (tagwolk, blogroll, lijst met categorieën) of widgets kan accepteren (zijbalk), moet widgets toestaan.
• Inhoud die standaard in widgetgebieden wordt weergegeven (hard-coded in de zijbalk, bijvoorbeeld) zou moeten verdwijnen wanneer widgets zijn ingeschakeld via Uiterlijk > Widgets.

Voettekst (footer.php)

• Gebruik de oproep wp_footer () om te verschijnen net voordat de body-tag wordt gesloten.

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

Index (index.php)

• Toon een lijst met berichten in uittreksel of volledige vorm. Kies de een of de ander naargelang het geval.
• Voeg wp_link_pages () toe om navigatielinks in berichten te ondersteunen.

Archief (archive.php)

• Archieftitel weergeven (tag, categorie, op datum gebaseerd of auteurarchieven).
• Een lijst met berichten weergeven in uittreksel of volledige vorm. Kies de een of de ander naargelang het geval.
• Voeg wp_link_pages () toe om navigatielinks in berichten te ondersteunen.

Pagina’s (page.php)

• Toon paginatitel en pagina-inhoud.
• Toon commentaarlijst en commentaarformulier (tenzij commentaar is uitgeschakeld).
• Voeg wp_link_pages () toe om navigatielinks binnen een pagina te ondersteunen.
• Metadata zoals tags, categorieën, datum en auteur mogen niet worden weergegeven.
• Geef een link “Bewerken” weer voor ingelogde gebruikers met bewerkingsrechten.

Eén bericht (single.php)

• Voeg wp_link_pages () toe om navigatielinks binnen een bericht te ondersteunen.
• Geef de titel van het bericht en de inhoud van het bericht weer.
  • De titel moet platte tekst zijn in plaats van een link die naar zichzelf verwijst.
• Geef de postdatum weer.
  • Respecteer de instellingen voor datum- en tijdnotatie tenzij het belangrijk is voor het ontwerp. (Gebruikersinstellingen voor datum- en tijdnotatie zijn in Beheerpanelen > Instellingen Algemeen).
  • Gebruik voor uitvoer op basis van de gebruikersinstelling the_time (get_option (“date_format”)).
• Geef de naam van de auteur weer (indien van toepassing).
• Geef berichtcategorieën en berichttags weer.
• Geef een link “Bewerken” weer voor ingelogde gebruikers met bewerkingsrechten.
• Geef commentaarlijst en commentaarformulier weer.
• Toon navigatielinks naar het volgende en vorige bericht met previous_post_link () en next_post_link ().

• Auteurcommentaar moet anders worden gemarkeerd.
• Gravatars (gebruikersavatars) weergeven indien van toepassing.
• Ondersteuning van discussielijnen.
• Trackbacks / pingbacks weergeven.
• Dit bestand mag geen functiedefinities bevatten, tenzij in de functie function_exist () check om herdeclaratiefouten te voorkomen. Idealiter zouden alle functies in functions.php moeten staan.

Zoekresultaten (search.php)

JavaScript

• JavaScript-code moet indien mogelijk in externe bestanden geplaatst.
• Gebruik wp_enqueue_script () om uw scripts te laden.
• JavaScript dat rechtstreeks in HTML-documenten (sjabloonbestanden) wordt geladen, moet CDATA-gecodeerd zijn om fouten in oudere browsers te voorkomen .

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

Screenshot

Maak een screenshot voor je thema. De schermafbeelding moet screenshot.png heten en in de map op het hoogste niveau worden geplaatst. De schermafbeelding moet het themaontwerp nauwkeurig weergeven en worden opgeslagen in PNG-indeling. Hoewel .jpg, .jpeg en .gif ook geldige extensies en bestandsindelingen zijn voor de schermafbeelding, worden ze niet aanbevolen.

De aanbevolen afbeeldingsgrootte is 1200 px breed bij 900 px hoog. De schermafbeelding wordt meestal kleiner weergegeven, maar de extra grote afbeelding maakt weergave met hoge resolutie op HiDPI-schermen mogelijk. Merk op dat omdat het scherm Thema’s beheren responsief is, de boven- en onderkant van de schermafbeelding mogelijk niet zichtbaar zijn, dus houd de afbeeldingen in het midden.

Thema-opties

Thema’s kunnen optioneel de Thema aanpassen scherm. Voor een voorbeeldcode, zie Een voorbeeldpagina voor WordPress-thema-opties.

Wanneer u de beschikbaarheid van het thema-aanpassingsscherm voor een gebruikersrol inschakelt, gebruikt u de gebruikersfunctie “edit_theme_options” in plaats van de functie “switch_themes”, tenzij de gebruikersrol zou eigenlijk ook in staat moeten zijn om van thema te wisselen. Zie voor meer informatie Rollen en Mogelijkheden en Beheermenu’s toevoegen.

Als u de functie “edit_themes” ergens in uw thema gebruikt om de beheerdersrol toegang te krijgen tot het scherm voor het aanpassen van thema’s (of misschien enkele aangepaste schermen), Houd er rekening mee dat sinds versie 3.0 deze mogelijkheid niet standaard is toegewezen aan de beheerdersrol in het geval van WordPress Multisite-installatie. Zie uitleg. Gebruik in dat geval de “edit_theme_options” mogelijkheid als je wilt dat de Administrator het “Theme Options” menu ziet. Zie de aanvullende mogelijkheden van de beheerdersrol bij het gebruik van WordPress Multisite.

Theme Testing Process

1. PHP- en WordPress-fouten oplossen. Voeg de volgende debug-instelling toe aan uw wp-config.php-bestand om verouderde functieaanroepen en andere WordPress-gerelateerde fouten te zien: define (“WP_DEBUG”, true) ;. Zie Verouderde functie-hook voor meer informatie.
2. Controleer sjabloonbestanden aan de hand van de checklist voor sjabloonbestanden (zie hierboven).
3. Voer een doorloop uit met behulp van de Theme Unit Test.
4. Valideer HTML en CSS. Zie Een website valideren.
5. Controleer op JavaScript-fouten.
6. Test in al uw doelbrowsers. Bijvoorbeeld IE9, Safari, Chrome, Opera, Firefox en Microsoft Edge.
7. Ruim eventuele externe opmerkingen, foutopsporingsinstellingen of TODO-items op.
8. Zie Themabeoordeling als je openbaar bent het thema vrijgeven door het in de themadirectory te plaatsen.

Bronnen en verwijzingen

Codestandaarden

• Ken uw bronnen
• WordPress-coderingsnormen
• CSS-coderingsnormen

Thema-ontwerp

• Site-ontwerp en lay-out

CSS

• CSS
• CSS steno
• Door WordPress gegenereerde klassen

Sjablonen

• In sjablonen stappen
• Sjablonen
• Sjabloonhiërarchie
• Sjabloontags
• The Loop
• Voorwaardelijke tags
• Functieverwijzing
• I18n voor WordPress-ontwikkelaars
• Gegevensvalidatie

Functielijst

• Functiereferentie

Testen en QA

• Thema-eenheid Te st
• Een website valideren
• CSS Browser-bugs verhelpen
• CSS-probleemoplossing
• modern.IE: voor het testen van IE op verschillende platforms met open -bronhulpmiddelen

Release & Promotie

• Proces voor themabeoordeling