Beslissen hoe u uw WordPress-themakader kunt ontwikkelen

In het eerste deel van deze serie heb ik geschetst hoe themakaders werken en welke verschillende soorten themakaders er zijn.

Voordat u kunt beginnen met het bouwen van uw eigen raamwerk, moet u overwegen hoe het moet werken en waarvoor het zal worden gebruikt, zodat u vanaf het begin de meest geschikte ontwikkelingsaanpak kunt gebruiken.

In deze zelfstudie doorloop ik de factoren die u in overweging moet nemen, inclusief of uw kader openbaar of privé is, of het wordt gebruikt door niet-programmeurs of ontwikkelaars en welke aanvullende functies u wilt opnemen.

Er zijn twee delen om te beslissen over uw aanpak: vaststellen hoe uw raamwerk zal worden gebruikt en op basis daarvan vaststellen wat u erin moet opnemen.

Hoe wordt uw themakader gebruikt??

De manier waarop uw themaraamwerk wordt gebruikt, zal van invloed zijn op wat u erin opneemt en hoe u het structureert. 

Stel je de volgende situatie voor:

• Is uw themakader alleen voor u of voor andere ontwikkelaars?
• Wordt uw framework gebruikt door ontwikkelaars of gebruikers zonder of met weinig codeerervaring?
• Zal uw themakader openbaar of privé zijn??

Alleen voor jou of voor anderen?

Als uw framework alleen voor uw persoonlijk gebruik is, dan hoeft u alleen maar na te denken over uw eigen behoeften wanneer u het ontwikkelt; het is echter zinvol om het in de toekomst te bewijzen en het zo robuust mogelijk te maken, dus u moet:

• gebruik de WordPress coderingsstandaarden
• accepteer het DRY-principe (niet jezelf herhalen)
• gebruik code die u kunt valideren met behulp van de validatiecontrole van de W3C. Je moet er ook voor zorgen dat je code toegankelijk is
• opmerkingen toevoegen - zelfs als iemand anders uw code niet bekijkt, zult u verrast zijn hoe gemakkelijk het is om te vergeten wat een stukje code doet wanneer u het vele maanden later gaat bewerken
• gebruik versiebeheer voor updates van uw framework

De W3C markup validator tool

Als uw framework wordt gebruikt door andere ontwikkelaars, misschien uw collega's, moet u alle bovenstaande procedures toepassen en moet u mogelijk ook:

• geef documentatie met een overzicht van de structuur, functies en haken van uw framework
• overweeg hoe u de code zult delen en eraan zult werken - een samenwerkingssysteem zoals GitHub maakt dit veel gemakkelijker
• documenteer je versies of koppel ze aan mijlpalen en / of releases op GitHub.

Voor ontwikkelaars of gebruikers?

Sommige themakaders zijn bedoeld voor niet-coderende gebruikers die het framework uitgebreid kunnen aanpassen zonder code te schrijven, terwijl andere gericht zijn op ontwikkelaars, die haken en functies bieden die ze kunnen gebruiken om het framework aan te passen en uit te breiden. Anderen zijn geschikt voor beide, met een uitgebreide gebruikersinterface en een API.

Alleen omdat uw raamwerk door niet-ontwikkelaars wordt gebruikt, hoeft u nog niet te zeggen dat u het voor het publiek vrijgeeft. Misschien heeft u designer-collega's die u toegang wilt geven, of laat u klanten het gebruiken voor aanpassingen om hun site.

Als uw framework voor niet-coderende gebruikers is, moet u het volgende opnemen:

• een of meer schermen met thema-opties waaruit uw gebruikers hun aanpassingen kunnen maken
• toegang tot de thema-aanpasser die u kunt gebruiken in plaats van thema-keuzeschermen, waardoor gebruikers het voordeel hebben dat ze hun wijzigingen kunnen zien terwijl ze ze maken, of u kunt ervoor kiezen om beide te gebruiken
• widgetgebieden waarmee gebruikers hun eigen inhoud op verschillende plaatsen op de pagina kunnen toevoegen
• menu's, zodat gebruikers op de site kunnen navigeren (misschien wilt u meer dan één gebied opnemen voor menu's)
• ondersteuning voor kinderenthema's zodat gebruikers kunnen installeren om snel een werkende site te maken
• bibliotheken voor alle functies die u wilt opnemen, zoals schuifregelaars of lichtbakjes
• documentatie en ondersteuning zodat gebruikers weten hoe ze uw werk moeten gebruiken (een deel hiervan is handig, maar pas op dat u het uw tijd laat overnemen)

Als uw doelgroep ontwikkelaars is die uw framework samen met hun eigen kindthema's en / of plug-ins zullen gebruiken, moet u wellicht enkele van de bovenstaande overwegingen overwegen, maar u moet ook functies uit de volgende lijst opnemen:

• actiehaken waarmee ontwikkelaars hun eigen code in uw sjabloonbestanden kunnen invoegen zonder een duplicaat sjabloonbestand te maken
• filterhaken waarmee ontwikkelaars kunnen wijzigen wat door uw sjabloonbestanden wordt uitgevoerd
• aangepaste functies die ontwikkelaars kunnen gebruiken in hun kindthema's
• sjabloondelen en bevatten bestanden om codeduplicatie te verminderen. Dit is iets waarvan je voordeel zult halen uit jezelf terwijl je met het framework werkt, en dat andere ontwikkelaars nuttig zullen vinden als de theorie sjabloonbestanden in hun kindthema's moet maken. Zorg ervoor dat uw bestanden een logische naam hebben en gestructureerd zijn en voeg opmerkingen toe aan de bestanden van waaruit ze worden gebeld, zodat mensen ze gemakkelijk kunnen vinden.

Openbaar of privé?

Als u van plan bent om uw raamwerk openbaar te maken, dan zijn er nog een hele reeks aanvullende overwegingen:

• Als u uw framework als thema via de WordPress-themarepository indient, moet u zich houden aan de richtlijnen voor themarevisies
• omdat gebruikers voor een aantal scenario's en sitetypen gebruik zullen maken van uw framework, moet u testen of uw framework werkt zoals het zou moeten in een breed scala aan contexten, en misschien de hulp inroepen van andere gebruikers en ontwikkelaars om te helpen je test het
• enige vorm van documentatie is essentieel, zowel voor ontwikkelaars als gebruikers, afhankelijk van uw doelgroep

De WordPress-themarepository

Je zult ook moeten overwegen hoe je je framework gaat promoten: zelfs als het gratis is, wil je dat mensen het gebruiken, dus je moet het publiceren via een website, sociale media, SEO, themagewinkels van derden, mond-tot-mondreclame, lokale meetups, WordCamps en / of andere methoden.

Wat moet uw thema-kader opnemen??

Een groot deel van de functies van uw thema wordt bepaald door de behoeften van de gebruikers die u zojuist hebt geïdentificeerd. Hebben besloten wie uw themakader is gericht en, indien mogelijk, gevraagd wat ze nodig hebben, schrijf een lijst op van de functies die uw thema zal omvatten. 

Deze lijst bevat (maar hoeft niet beperkt te zijn tot) een selectie van het volgende:

• sjabloonbestanden (inclusief sjabloondelen en bestanden)
• functies
• actiehaken en filterhaken
• widget gebieden
• menus
• opties en instellingenschermen
• ondersteuning voor themafouters
• documentatie
• kind thema's

Hiertoe identificeren:

• wat de functie is
• wat het zal doen
• waar de code zal verschijnen

Naast functies die worden bepaald door de behoeften van verschillende gebruikersgroepen, wilt u misschien ook andere functies toevoegen, zoals:

• Heeft uw raamwerk een ingebouwde lay-out, kan de lay-out worden geconfigureerd of wordt het gecodeerd via kindthema's?
• Hoeveel hiervan neem je mee in je bovenliggende thema? Sommige frameworks hebben een uiterst minimale styling, terwijl andere (zoals mijn eigen) zijn gebouwd met behulp van Object Oriented CSS (OOCSS) om het stylen gemakkelijker te maken in kindthema's.
• Zal uw framework responsief zijn of wordt dit gecodeerd via kindthema's? Als uw ouderthema responsief is, moet u ervoor zorgen dat dit niet wordt overschreven door een lay-outstijl in uw kindthema's, een gebied waar OOCSS goed van pas komt.
• Voegt u SEO-functies toe aan uw framework bovenop wat wordt aangeboden door WordPress, of voegen gebruikers dit toe via een standalone plug-in?
• Zul je dingen zoals sliders, galerijen, achtergrondafbeeldingen en meer in je raamwerk opnemen of ze toevoegen via kindthema's als dat nodig is?

Deze lijst kan in de loop van de tijd groeien naarmate uw behoeften en die van uw gebruikers evolueren. Zorg ervoor dat uw framework gemakkelijk vanaf het begin kan worden uitgebreid en u kunt nieuwe functies toevoegen wanneer dat nodig is.

Samenvatting

Het ontwikkelen van een eigen themakader is een grote onderneming. Het is iets dat u op de lange termijn vele uren ontwikkelingstijd bespaart, maar dat een behoorlijke hoeveelheid werk vergt om het goed te doen. 

Door de tijd te nemen om vast te stellen wie uw framework gaat gebruiken en welke functies zij nodig hebben, maakt u het nuttiger voor uzelf en andere gebruikers en maakt u het eenvoudiger om het framework in de toekomst uit te breiden en aan te passen..