Het perfecte WordPress-thema maken hoe goed coderen

In het vorige deel van deze serie; we hebben verschillende WordPress-API's doorgenomen waarover we meer te weten moeten komen, hebben gesproken over het belang van het vertalen van een thema (of nog beter, het vrijgeven ervan al vertaald in andere talen) en begrepen het concept van licentiethema's en het gebruik van gelicentieerde producten met de thema's.

In dit artikel gaan we ons concentreren op code: we zullen zien hoe code moet worden gecodeerd met WordPress-standaarden, hoe we onze code correct kunnen becommentariëren en hoe we het thema kunnen valideren en testen.


WordPress coderingsstandaarden

Ja, ik weet het, je hebt je eigen voorkeursstijl van coderen: je wilt graag een grote functie comprimeren met een enkele regel code, je houdt niet zo veel van witruimte - Ah, ik was ooit zo.

Maar als je je voor andere mensen gaat ontwikkelen en letterlijk verkoop je code, je moet je code begrijpelijk maken. En hoewel u misschien denkt dat uw code "duidelijk genoeg" is, zijn er universele coderingsnormen om iedereen met dezelfde stijl te coderen, en alle serieuze themamarkten en downloadcentra (van WordPress.org tot ThemeForest) vereisen je moet coderen met standaarden.

Er zijn vier programmeer- en markup-talen nodig om WordPress-thema's te ontwikkelen: HTML, CSS, JavaScript en natuurlijk PHP. Laten we ze eens bekijken:

HTML-standaarden

Er zijn relatief eenvoudige regels voor het schrijven van normen-conforme HTML-code:

  • Valideer uw code met W3C. Altijd. Daar komen we later op terug.
  • Wees voorzichtig met zelfsluitende elementen: je moet het element eindigen met een spatie, een schuine streep en het "groter dan" -teken.
  • Typ bij het typen van attribuutwaarden ze allemaal in kleine letters - tenzij het voor mensen is.
  • Verpak uw kenmerkwaarden altijd met aanhalingstekens. Zowel enkele als dubbele aanhalingstekens zijn acceptabel.
  • Inspringing moet logisch en leesbaar zijn. PHP-code gemengd in de HTML zou geen uitzondering mogen zijn.

Bekijk de WordPress HTML-standaardpagina van Make WordPress voor meer informatie.

CSS-normen

De lijst is wat langer, maar nogmaals, er zijn eenvoudige regels voor juiste CSS-codering:

  • Eigenschappen moeten worden ingesprongen met tabbladen.
  • Je kunt selectors groeperen, maar elke selector moet zijn eigen regel hebben voor leesbaarheid.
  • Noem al je klasse en ID kaart selectors met kleine letters en vergeet niet om woorden met koppeltekens te scheiden.
  • Gebruik leesbare selectors. .c6 is geen goede naam - noem maar op .kolom zesde!
  • Geen overkwalificatie. div.column is zinloos als je het gewoon kunt gebruiken .kolom.
  • Eigenschappen en hun waarden moeten ook in kleine letters voorkomen, behalve lettertypenamen en leverancierspecifieke eigenschappen.
  • Bestellen voor de eigenschappen moet "weergave, positionering, doosmodel, kleuren, typografie en andere" zijn.
  • U moet ook de voorvoegsels van leveranciers van langste (-webkit-) tot de kortste (geen voorvoegsel).
  • Houd uw mediaquery's onder aan uw stylesheet.
  • Reageer uw CSS-code terwijl u reageert in PHP. Daarover later meer.

Zie de WordPress CSS-standaardpagina op Make WordPress voor een meer gedetailleerde uitleg.

JavaScript-standaarden

Aangezien JavaScript tegenwoordig cruciaal wordt voor veel WordPress-thema's, hebben we ook normen en regels nodig:

  • Bretels kunnen niet openen en sluiten binnen dezelfde lijn.
  • Geef de voorkeur aan enkele aanhalingstekens boven dubbele aanhalingstekens, tenzij een reeks enkele aanhalingstekens bevat.
  • Je bent vrij om witruimte te gebruiken zoals je wilt in je code - gebruik echter geen witruimte op lege regels. En vergeet niet dat je witruimte gebruikt voor leesbaarheid - niet voor de lol.
  • Geef uw functies en variabelen een naam met camelCase, not_with_underscores. Constructors moeten in Hoofdzaak.
  • U kunt meerdere variabelen op één regel declareren; maar als je waarden gaat toewijzen, heb je aparte regels nodig.
  • De nieuwe matrix () en nieuw object () notaties zijn "nee-nee" s. Gebruik steno-equivalenten ([] en ) in plaats daarvan.
  • Behandel conditionals en loops heel subtiel - ze zijn meestal het gemakkelijkst om verkeerd te lezen. Het gebruik van accolades en witruimte zijn hierbij de sleutelwoorden.
  • Als je jQuery gaat gebruiken; definieer een anonieme functie en geef jQuery door als argument voordat u iets anders doet. Bekijk het voorbeeld om zeker te zijn.

De WordPress JavaScript-standaardpagina van Make WordPress heeft meer informatie, bladwijzer voor deze pagina en gebruik deze.

PHP-standaarden:

Dit is het moeilijkere deel. Er zijn veel regels om te overwegen:

  • Naamconventies
  • Enkele en dubbele aanhalingstekens
  • Whitespace gebruik
  • Normale uitdrukkingen
  • "Yoda-voorwaarden"
  • Speciale gastster SQL en opmaak van databasequery's

Als je niet weet wat ze zijn, dan is je beste gang misschien om licht te bewandelen.

Er zijn echter twee geweldige hulpmiddelen om het te leren:

  1. WordPress PHP Standards-pagina bij Make WordPress
  2. De Wptuts + -serie "The WordPress Coding Standards" door Tom McFarlin

Een juiste reactie op uw code

Om andere ontwikkelaars inzicht te geven in de manier waarop u uw thema hebt gemaakt, moet u uw themacode duidelijk en leesbaar maken - en dit vereist commentaar op uw code.

De beste methode voor PHP is om PHPDoc te gebruiken, de documentatiestijl van phpDocumentor. Het wordt veel gebruikt door WordPress-ontwikkelaars en aanbevolen op de pagina PHP Documentation Standards van Make WordPress. Het biedt een schone documentatiestijl voor uw PHP-code.

Wat betreft CSS beveelt de WordPress CSS-standaardpagina van Make WordPress u aan om het te doen zoals PHPDoc, samen met een paar andere suggesties.

Wat betreft uw HTML- en JavaScript-code, lijkt het erop dat er geen aanbevolen of vereiste manier is om uw code te becommentariëren, maar dit betekent niet dat u niets hoeft te doen: probeer zo duidelijk mogelijk te zijn met uw code en geef kleine stukjes informatie door commentaar te geven waar je maar nodig vindt.


Valideren en testen van het thema

Het thema werkt misschien als een leuke website in je hoofd, maar hopelijk zullen er honderden (misschien duizenden) mensen zijn die je thema zullen gebruiken en er zeker van zijn dat ze zullen proberen websites te maken die je onmogelijk kunt bedenken van. Bovendien zijn er vereisten voor themamarkten en themadirectory's om je thema samen te stellen.

Daarom moet u uw thema testen en uw code valideren. Ik heb daar drie ideeën voor:

Valideer uw HTML & CSS met de W3C-validators

Het eerste dat u hoeft te doen, is uw code valideren met de validatieservices van de W3C. Zowel de HTML Markup Validator- als de CSS Validator-services worden al jaren gebruikt en ontwikkeld en zijn de beste validatieservices die beschikbaar zijn.

Nadat u de twee onderstaande dingen hebt gedaan, controleert u eenvoudigweg de demopagina's met deze twee services om te controleren of er geen fouten of waarschuwingen zijn.

Gebruik de plug-in "Ontwikkelaar" om uw thema te corrigeren

Ontwikkelaar is een gratis plugin ontwikkeld door Automattic die in hun woorden, help WordPress-ontwikkelaars ontwikkelen. Het is eigenlijk gewoon een plug-in installatieprogramma: het belangrijkste doel van de plug-in is om de essentiële plug-ins voor uw ontwikkelomgeving te bieden.

Ontwikkelaar suggereert 16 verschillende plug-ins. Sommige maken uw ontwikkelproces een stuk eenvoudiger (zoals User Switching en Theme Test Drive), maar sommige helpen u bij het debuggen van uw thema (zoals Verouderde meldingen en Themacontrole).

Degene die ik het handigst vind zijn Themacontrole, Thema-proefrit en Foutopsporingsbalk, maar alle 16 plug-ins bieden geweldige functies. Ik stel voor dat u ze allemaal installeert om het thema van uw thema te testen.

Test uw thema met testgegevens

Je kunt niet alleen het thema coderen en zeggen dat het voltooid is - je moet het testen met wat inhoud. U kunt uw eigen inhoud maken, maar u zou moeten overwegen om te testen met enkele "testgegevens":

  • Gebruik de voorbeeldgegevens van WordPress. Deze voorbeeldgegevens bevatten enkele van de meest gebruikte inhoudstypen en helpen u de tekortkomingen van uw thema te identificeren tegen inhoud die u bent vergeten in overweging te nemen.
  • Gebruik meer grondig testgegevens. WPTest.io is een kleine website met een eng verzameling van voorbeeld WordPress-inhoud. Ik maak geen grapje: van menu-items die diep gaan in 10 niveaus en ingesloten door Amazon Store zijn dit de meest uitgebreide testgegevens die ik ooit heb gezien. Ik heb nog nooit een thema getest met deze voorbeeldinhoud, maar als het je lukt om je thema met deze gegevens te laten werken, hoef je je waarschijnlijk geen zorgen te maken dat je thema saai is in elk scenario.

Het enige nadeel van deze twee tests is dat je je inhoud niet kunt testen met shortcodes of het type specifieke inhoud dat je in gedachten had tijdens het ontwikkelen van het thema. Ik stel voor dat u het thema test met ten minste de voorbeeldgegevens van WordPress en vervolgens uw eigen inhoud maakt. Je hebt immers degelijke inhoud nodig wanneer je de demowebsite voor je thema maakt.


Afsluiten

In dit artikel; we hebben de processen voor het correct coderen en reageren met enkele standaarden doorlopen, daarna hebben we gezien hoe onze code te valideren en ons thema te testen. In het volgende deel van de serie zullen we een aantal bekijken slechte praktijken.

Blijf op de hoogte en vergeet niet om het artikel te delen, als je het leuk vond!