U hebt nu dus een WordPress-themakader. Gefeliciteerd! Het harde werk dat je hebt gedaan om het te ontwikkelen zal op de lange termijn vruchten afwerpen en je ontwikkelingsproces smoren, gestroomlijnder en efficiënter maken.
Maar je moet nog een laatste ding doen voordat je klaar bent, en dat is om je raamwerk te documenteren. Je moet op zijn minst zorgen dat goede opmerkingen overal in je code worden gebruikt, maar het is ook handig om wat andere documentatie te schrijven, zodat je de bestanden, functies en filters kunt bijhouden die deel uitmaken van de API van jouw framework..
De opties die ik zal behandelen zijn:
Hoewel ik een paar documentatiehulpmiddelen zal noemen, is deze tutorial geen aanbeveling, omdat ik ze niet heb gebruikt voor mijn eigen raamwerk, dus u moet uw eigen oordeel vellen over hun geschiktheid.
Opmerkingen zijn vooral belangrijk wanneer andere ontwikkelaars met uw code werken (bijvoorbeeld als u deel uitmaakt van een team of als u uw kader vrijgeeft). Maar ze zijn ook van onschatbare waarde als je alleen werkt, want het is heel gemakkelijk om te vergeten wat een stukje code precies doet als je het een jaar of langer later gaat bewerken.
Stel je voor dat je je framework hebt gebruikt om een client-site te bouwen. Over twee jaar ontwikkelt de site op vrijdagmiddag om 5:30 een probleem. Goede reacties kunnen het verschil maken tussen het snel repareren van de problemen en thuiskomen in het weekend, tegen het kloppen door honderden regels code en het missen van je vrijdagavond uit.
Hier zijn enkele tips voor goede opmerkingen:
@pakket
), en welke versie van het thema het sindsdien heeft ingevoerd (@sinds
). U zou een soortgelijk systeem voor plugin-bestanden moeten gebruiken./ ** * Sjabloonnaam: sidebar-products.php * * Het include-bestand dat wordt gebruikt voor de zijbalk op pagina's met de sjabloon single-product.php. Geeft een galerij met productafbeeldingen weer (waarbij de afgebeelde afbeelding wordt weggelaten die in de inhoud wordt weergegeven). * * @package wpptl-theme-framework * @since version 1.0 * /
EEN readme.txt
bestand is het volgende niveau na commentaar. Het is een enkel bestand dat u opneemt in uw thema, met informatie over het thema.
De codebundel bij deze serie bevat een eenvoudige readme.txt
het dossier:
Uw eigen WordPress-themakader maken Dit thema ondersteunt het zesde deel van deze serie voor wptutsplus. Het thema bevat de volgende sjabloonbestanden: archive.php index.php page.php - voor statische pagina's pagina-full-width.php archive.php - voor archiefpagina's header.php sidebar.php footer.php loop.php loop-single .php loop-page.php functions.php Het thema ondersteunt aanbevolen afbeeldingen, menu's en widgets en gebruikt ze als volgt: Uitgelichte afbeeldingen: deze worden weergegeven in het archief en de indexsjablonen als ze aanwezig zijn, met behulp van de gemiddelde grootte. Menu's: het standaardmenu bevindt zich in header.php en gebruikt de menu's admin. Styling Het thema maakt gebruik van Object Oriented CSS (OOCSS). De volgende klassen zijn voor lay-out en u kunt ze gebruiken in uw pagina's en berichten. Ze reageren, dus verkleinen op kleinere schermen (bijvoorbeeld de .half-klasse is de volledige breedte van telefoons). Volledige breedte. Drie kwart. Twee derde. Halve. Derde. Kwartshaken Er zijn 7 actiehaken: boven de header Binnen de header Voor de inhoud Na de inhoud In de zijbalk In de footer Na de footer Er zijn 3 filterhaken: 1 in de header 2 in de voettekst Widgetgebieden Er zijn zes widgetgebieden, allemaal toegevoegd via het widgets.php-bestand: - één in de kopregel - één in de zijbalk - vier in de voettekst
Als je je wilt maken Leesmij
bestand gebruiksvriendelijker, wilt u misschien overwegen om een te maken readme.html
bestand dat in de browser van een gebruiker wordt geopend. U kunt CSS gebruiken om uw merk te markeren Leesmij
bestand en maak het gemakkelijker om te lezen.
Als u uw thema openbaar wilt maken via de WordPress-themarepository, wordt van u verwacht dat u een readme.txt
bestand als een minimale vorm van documentatie. Ik zal dit in meer detail bespreken in de laatste tutorial in deze serie, over het vrijgeven van je themaraamwerk.
Als u van plan bent om door te gaan met het ontwikkelen van uw framework en niet veel tijd wilt besteden aan het handmatig schrijven van documentatie voor elke nieuwe functie, is een geautomatiseerde documentatietool wellicht het antwoord.
De meeste hiervan zijn het gebruik van specifieke tags of syntaxis om het systeem in staat te stellen te bepalen waar documentatie moet worden gegenereerd. Voorbeelden zijn:
Als u een van deze hulpprogramma's gaat gebruiken, is het de moeite waard om eerst de beste te vinden voordat u begint, omdat u uw documentatie niet van de ene naar de andere kunt overbrengen..
Maar als u eenmaal het systeem onder de knie hebt en het hebt ingesteld, kan een geautomatiseerd hulpmiddel als deze u veel tijd besparen en lacunes in uw documentatie langs de lijn voorkomen, omdat u zo druk bent met het schrijven van code heb geen tijd om uw documenten bij te werken.
Deze optie zal meer werk zijn en is alleen de moeite waard om te doen als u uw framework in de loop van de tijd ziet groeien en een aanzienlijke gebruikersbasis bereikt. Alle belangrijke themakaders hebben hun eigen websites met documentatie, die ofwel vrij toegankelijk is of alleen beschikbaar is voor leden.
De website ter ondersteuning van uw raamwerk kan deel uitmaken van uw strategie voor het genereren van inkomsten - het hybride themakader is bijvoorbeeld gratis, maar de documentatie en ondersteuning op de bijbehorende website zijn alleen beschikbaar voor betalende abonnees.
Als u uw framework als een premiumproduct wilt vrijgeven, kunt u mogelijk van abonnees eisen dat ze zich aanmelden bij de documenten, of u kunt ervoor kiezen uw documentatie openbaar te maken in de hoop dat dit meer mensen zal aanmoedigen om te kopen.
Als uw framework volledig gratis is, kunt u ervoor kiezen om een gratis website met documentatie te maken, zoals het geval is met het Wonderflux-framework:
Als alternatief kunt u besluiten om een wiki te maken, wat het voordeel heeft dat uw gebruikers bijdragen aan de documenten. In de meeste gevallen zal dit meer tijd kosten om op te zetten dan een website, maar het kan een waardevolle tool zijn voor de gemeenschap die uw framework gebruikt. U kunt een wiki maken met behulp van een plug-in voor de WordPress-site van uw framework.
Zelfstudies kunnen nieuwe gebruikers helpen, vooral degenen die geen code kunnen schrijven, kunnen sneller grip krijgen op uw raamwerk dan standaarddocumentatie. Video's gaan nog een stap verder en bieden een eenvoudig te gebruiken visuele handleiding en een geweldige marketingtool.
Het Genesis-framework heeft een reeks tutorials voor gebruikers die alleen beschikbaar zijn voor betaalde abonnees:
Mijn eigen Edupress-framework heeft een aantal zelfstudievideo's die ik heb gemaakt om gebruikers met een verschillende mate van computerervaring en weinig ervaring met het gebruik van WordPress te helpen:
Deze worden weergegeven op de openbare website en ook in dashboards van gebruikers, zodat ze eenvoudig toegang hebben tot deze terwijl ze met het framework werken. Als u documentatie, zelfstudies of video's voor uw kader maakt, kunt u een scherm in het dashboard opnemen met details van uw documenten.
Het maken van zelfstudies of video's kost echter veel tijd en heeft veel werk nodig om het goed te doen: slecht geschreven tutorials of slecht geproduceerde video's zullen slecht reflecteren op uw framework en kunnen u meer kwaad dan een eenvoudiger vorm van documentatie..
Degene die je themaraamwerk gaat gebruiken, een soort documentatie is essentieel. Of u nu alleen het kader voor u en uw team aan het ontwikkelen bent, of het voor een groter gebruik vrijgeeft, u moet informatie over de bestandsstructuur en de API vastleggen.
De opties die ik hierboven heb besproken, variëren van de eenvoudige opmerkingen tot de meer complexe video's, met alles ertussenin. Wat u besluit te doen, is afhankelijk van de behoeften van uw gebruikers en kan in de loop van de tijd veranderen naarmate u een groter gebruikersbestand krijgt.