Share
In deze reeks hebben we het gehad over een aantal praktijken die we kunnen toepassen in onze WordPress-thema-ontwikkeling die niet alleen een consistente basis zal bieden voor de bouw van onze bestaande en toekomstige projecten, maar die ons ook zal helpen behoud ze nadat ze zijn vrijgegeven.
Tot nu toe hebben we het volgende behandeld:
Voordat ik in dit artikel duik, raad ik aan de eerste twee te lezen, zodat je een idee krijgt van het perspectief dat we gebruiken bij het ontwikkelen van thema's. Naast deze punten zijn er ook een aantal tools waarvan ik denk dat ze moeten worden geïnstalleerd om ervoor te zorgen dat we de best mogelijke code schrijven.
Dit is natuurlijk niet alleen een aanvulling op de eerder genoemde tips, maar ook op het toepassen van de WordPress coderingsstandaarden.
In dit laatste artikel zal ik het hebben over verschillende instellingen en plug-ins die volgens mij moeten worden gedefinieerd en / of geïnstalleerd elk WordPress-ontwikkelomgeving om ervoor te zorgen dat u de meest up-to-date API's gebruikt, dat u geen negatieve invloed heeft op de prestaties en dat u geen meldingen, waarschuwingen of fouten veroorzaakt die via PHP worden gegenereerd.
Voordat we beginnen met praten over verschillende beschikbare plug-ins, zijn er een aantal instellingen die ik ten zeerste aanbeveel op uw webserver en in uw WordPress-omgeving aan te passen.
Sommige van deze instellingen zullen bijdragen aan de functionaliteit van plug-ins die we verderop in dit artikel zullen bekijken, andere zullen functionaliteit bieden die ons zal waarschuwen als we fouten maken in PHP en / of in onze WordPress specifieke code.
Hoewel niet iedereen met Apache, PHP en MySQL werkt, is het nog steeds de meest voorkomende configuratie die wordt gebruikt bij het werken met WordPress. Een van de dingen die ik altijd ontwikkelaars aanbeveel in deze omgeving is om ervoor te zorgen dat ze PHP hebben geconfigureerd om te loggen alles naar een logbestand op hun computer.
Dat wil zeggen, wanneer de opties om te loggen gegeven:
Zorg ervoor dat je dat controleert alles. Als u een hulpmiddel zoals MAMP, XAMPP of WAMP gebruikt, is dit meestal heel gemakkelijk via de gebruikersinterface; Als u echter niet zeker weet waar u deze opties kunt configureren, kunt u deze altijd instellen php.ini met behulp van de notities die worden beschreven in de PHP-handleiding.
Het bijhouden van fouten die zijn vastgelegd en die mogelijk niet op het scherm worden weergegeven (hoewel we gaan doen wat we kunnen om ervoor te zorgen dat we do zie ze later in dit artikel op het scherm) is essentieel om ervoor te zorgen dat je code schrijft die mogelijke problemen met de code oplost.
Toegegeven, dit zou moeten kunnen worden gedaan bij het gebruik van andere webservers - tenslotte is dit eigenlijk slechts een PHP-configuratie-instelling - maar ik gebruik momenteel niet veel van de andere beschikbare opties, dus wilde ik expliciet zijn over de omgeving waarin ik mijn instellingen configureer.
WP_DEBUG is een constante die u kunt instellen in uw WordPress wp-config.php het dossier. Bij de meeste installaties is deze standaard ingesteld op false. Als de jouwe al is ingesteld op waar, dan betekent dit dat iemand het al heeft gedaan of dat je een kopie van WordPress hebt met instellingen die dat wel zijn niet standaard verzonden vanuit WordPress.org.
Hoe dan ook, zoek in het configuratiebestand naar de constante en of deze is ingesteld op vals, stel het dan in op waar. Als het niet wordt gevonden, voegt u de regel toe. Uiteindelijk is dit wat uw functions.php bestand moet bevatten (naast de andere code die er al was):
Accentsconagua
define ('WP_DEBUG', true);In het kort, deze specifieke constante zorgt ervoor dat PHP-berichten worden uitgeschreven in het display en WordPress-specifieke foutopsporingsberichten. Dit is echt handig wanneer u aan een thema werkt en u probeert een lege index van een array te controleren of u gebruikt uiteindelijk een functie die niet langer wordt ondersteund door de huidige versie van WordPress.
Er is ook een fantastische plug-in gerelateerd aan deze techniek die we verderop in dit artikel bespreken.
Er zijn ook nog twee constanten die u kunt definiëren en die zelfs nog meer informatie geven over wat deze wil. U kunt het bijbehorende Codex-artikel lezen voor meer informatie, maar kort samengevat zijn de constanten en hun definities als volgt:
WP_DEBUG_DISPLAY is een andere aanvulling op WP_DEBUG die bepaalt of foutopsporingsberichten worden weergegeven in de HTML van pagina's of niet. De standaardinstelling is 'true', waarbij fouten en waarschuwingen worden weergegeven wanneer ze worden gegenereerd. Als u dit op false instelt, worden alle fouten verborgen. Dit moet in combinatie met WP_DEBUG_LOG worden gebruikt, zodat fouten later kunnen worden beoordeeld.
Uit de doos zal WordPress alle fouten, waarschuwingen en mededelingen binnen de context van een pagina weergeven. Als u wilt blijven debuggen met WordPress maar wilt voorkomen dat de informatie wordt weergegeven op de pagina en alleen naar een logbestand wordt geschreven, kunt u deze constant instellen op vals.
Persoonlijk ben ik geen fan van dingen verborgen te houden omdat ik graag problemen zie zodra ze opduiken (lees: zodra ik ze heb gegenereerd), maar iedereen heeft andere workflows. Daartoe, als het zien van de berichten op de pagina's conflicteert met uw ontwikkelstijl, definieer dan deze constante op de juiste manier WP_DEBUG_LOG.
WP_DEBUG_LOG is een aanvulling op WP_DEBUG die ervoor zorgt dat alle fouten ook worden opgeslagen in een debug.log-logboekbestand in de map / wp-content /. Dit is handig als u alle kennisgevingen later wilt bekijken of als u kennisgevingen wilt bekijken die buiten het scherm zijn gegenereerd (bijvoorbeeld tijdens een AJAX-aanvraag of wp-cron-run).
Dit is een nuttige constante om te bepalen of u groot bent in het controleren van uw foutenlogboeken (die de meeste ontwikkelaars hebben moeten worden). Naast het logbestand dat door PHP wordt gegenereerd, is dit nog een ander bestand dat inzicht kan geven in wat een bepaald probleem kan zijn en waar het zich voordoet wanneer u aan een thema werkt.
Deze constante is een andere die van pas zal komen met enkele van de plug-ins waar we later in dit artikel naar zullen kijken; het is echter de moeite waard om in te stellen functions.php zelfs als je geen extra plug-ins hebt geïnstalleerd.
Ten eerste, net als de WP_DEBUG constant hierboven, kunt u dit toevoegen aan functions.php. Het zou er zo uit moeten zien:
define ('SAVEQUERIES', true);Ziet er goed uit, zeker, maar wat doet het eigenlijk?? SAVEQUERIES instrueert WordPress om twee dingen bij te houden:
Dit sluit direct aan op $ wpdb welke is de WordPress-databaseklasse. Zoals eerder vermeld, is er een andere plug-in die direct met deze bepaalde constante werkt, zodat u alle vragen vanuit WordPress kunt bekijken; Als u echter liever af wilt zien van het gebruik van een plug-in om de informatie weer te geven, definieert u eenvoudig deze constante en drukt u vervolgens het resultaat af $ Wpdb-> queries naar uw uitvoerformaat naar keuze.
Naast het instellen van constanten, zijn er een aantal krachtige plug-ins waarvan ik denk dat ze in de WordPress-installatie van elke ontwikkelaar moeten worden geïnstalleerd, die nog meer hulp kunnen bieden bij gebruik met de bovenstaande instellingen.
Hoewel velen van jullie plug-ins hebben om aan deze lijst toe te voegen en anderen meningen hebben over elk van deze plug-ins, zijn dit degenen die ik het nuttigst vond in mijn ontwikkelingsinspanningen..
Foutopsporingsbalk introduceert een optie in de beheerbalk van uw WordPress-installatie die informatie geeft over vragen, de cache en andere informatie.
Deze plug-in kan het beste worden gebruikt met WP_DEBUG en SAVEQUERIES ingeschakeld. Merk op dat deze plug-in ook vereist is voor een aantal van de plug-ins die ik hierna opslaat. Dat wil zeggen, het heeft een aantal extensies die het nog krachtiger maken.
Deze plugin introduceert nog twee tabbladen in de Debug Bar waarmee u alle acties en de filters (dat zijn alle haken) kunt zien die worden uitgevoerd op het huidige paginaverzoek.
Dit is buitengewoon handig als u een complex thema aan het bouwen bent of als u een codebase van iemand anders hebt geërfd en probeert te vinden waarom bepaalde dingen gebeuren die misschien niet gemakkelijk te vinden zijn vanwege de manier waarop het thema is opgebouwd.
Helaas is deze specifieke plug-in niet over een paar jaar bijgewerkt, dus ik weet niet hoe lang hij blijft werken met WordPress (tenzij iemand het voor ontwikkeling adopteert), maar het werkt samen met Debug Bar om u te helpen de mogelijkheid om PHP en MySQL direct vanuit WordPress uit te voeren.
Dit is erg handig wanneer u probeert uit te zoeken waarom een functie in uw thema bijvoorbeeld niet presteert zoals het zou moeten zijn. Dat wil zeggen, je kunt een functie rechtstreeks in de console schrijven, uitvoeren en het resultaat zien zonder constant terug te moeten springen in je IDE, de functie te wijzigen, het resultaat te vernieuwen en het resultaat te controleren.
Als u werkt met een thema dat veel stijlen en veel JavaScript-bestanden gebruikt, met name die welke afhankelijk zijn van andere stylesheets en andere JavaScript-bestanden, dan is het handig om te weten in welke volgorde deze worden geladen en hoe ze moeten worden loaded.
Dat is waar deze Debug Bar-add-on in het spel komt.
Hiermee kunnen we de volgorde visualiseren waarin scripts en stijlen worden geladen en uitgevoerd, zodat we de nodige wijzigingen kunnen aanbrengen om ervoor te zorgen dat alle afhankelijkheden worden geladen zoals ze zouden moeten zijn om ons thema correct te laten werken.
Als uw thema aangepaste berichttypen introduceert in het dashboard, dan is de kans groot dat u hebt moeten werken met een verscheidenheid aan verschillende eigenschappen, regels herschrijven en meer.
Het kan erg snel ingewikkeld worden, afhankelijk van hoeveel je beslist om de kenmerken van het aangepaste berichttype aan te passen.
Deze plug-in voegt nog een ander deel toe aan de foutopsporingsbalk, zodat u gemakkelijk de eigenschappen voor elk berichttype kunt zien. Het staat niet toe dat je dit direct aanpast of bewerkt (zoals dat kan in de Debug Bar Console of door simpelweg je aangepaste berichttype-definitie te bewerken), maar het biedt wel een veel schoner formaat dan een gigantische array in het scherm van een IDE.
Dit is een eenvoudige plug-in die het gebruik van oude bestanden, functies, argumenten, enzovoort bij een bestand registreert. Met name wanneer u een thema schrijft, geeft deze plug-in een melding wanneer u iets uitvoert dat niet 100% compatibel is met de huidige versie van WordPress.
Voor degenen die willen controleren of ze hun werk in de toekomst willen testen en die op de hoogte blijven van de nieuwste API's, raad ik deze plug-in ten zeerste aan.
Een van de grootste misvattingen over WordPress is dat het draaien van een groot aantal plug-ins ervoor zorgt dat uw site langzaam laadt of dat veel plug-ins een bloat veroorzaken. Dat is niet waar. Het zijn slecht geschreven plug-ins die dat doen. Degenen die de best practices van WordPress en de coderingsstandaarden volgen, zouden een minimale impact op de laadtijd moeten hebben.
Met dat gezegd, zal deze plug-in exact aangeven welke plug-ins de meeste invloed hebben op de prestaties. Natuurlijk kan dit handig zijn als u probeert te achterhalen waarom een site langzaam presteert, maar het is ook handig om uit te voeren met uw eigen code om ervoor te zorgen dat je bent geen nadelige invloed op de prestaties van de site.
Voor iedereen die uitgebreid heeft gewerkt met aangepaste berichttypen, aangepaste routes of URL's of die zich hebben moeten wagen aan de Rewrite API, kent u de uitdagingen die er zijn.
Deze plug-in helpt bij het geven van een visuele weergave van de herschrijfregels voor uw installatie. Het is handig voor het inspecteren van regels die binnen het huidige thema bestaan, maar het is ook handig om te helpen bij het debuggen wanneer u een aangepast schema probeert te definiëren en het moeilijk vindt om de reguliere expressie te gebruiken om dit te doen.
Als u uw plug-in op de markt wilt brengen voor een zo groot mogelijk publiek, dan wilt u testen hoe het eruitziet in talen die van links naar rechts en van rechts naar links lezen..
Dat wil zeggen, als u zeker wilt weten dat u uw thema goed hebt geïnternationaliseerd, laat deze plug-in u zien hoe uw werk eruit ziet voor geïnternationaliseerde talen.
Als u uw thema bijvoorbeeld op WordPress.com wilt verkopen, dan is dit een must-have.
Als u ervoor wilt zorgen dat uw thema up-to-date is met de huidige WordPress Theme Review-richtlijnen, dan is Theme Check een niet-onderhandelbare.
Het voert een automatische audit uit van uw thema en zorgt ervoor dat al uw code voldoet aan de huidige richtlijnen. Zo niet, dan toont het u een duidelijk overzicht van de problemen en links naar de richtlijn die u niet volgt. Het bevat ook suggesties voor dingen die u had moeten implementeren.
Merk op dat de meeste (zo niet alle) vrij beschikbaar zijn vanuit de WordPress Plugin Repository, zodat ze rechtstreeks vanuit WordPress zelf kunnen worden geïnstalleerd.
Zoals ik in eerdere artikelen heb aangegeven, zijn veel van de dingen die ik in deze serie heb gedeeld een beetje subjectief of werken ze misschien niet in je huidige omgeving. Hoewel de werkwijzen en hulpmiddelen die ik heb gedeeld al vele jaren zijn beproefd en bewezen door mijn eigen persoonlijke ervaring in het werken met WordPress, zie ik ook in dat we niet allemaal dezelfde toolset gebruiken.
Als zodanig betekent dit dat een deel van de configuratie, organisatie en instellingen voor u kan variëren. Dat is goed. Uiteindelijk gaat het erom dat we, als thema-ontwikkelaars, een beter werk moeten doen in het schrijven van onderhoudbare thema's omdat we er zo veel tijd aan besteden na hun eerste release.
Misschien zullen enkele van de dingen die in deze serie worden gesuggereerd je helpen precies dat te doen. Misschien moet u een aantal suggesties aanpassen aan de tools die u gebruikt. Hoe het ook zij, ik hoop dat het niet alleen een nuttige serie is geweest met een aantal praktische tips om je te helpen bij je voortdurende thema-ontwikkeling, maar dat het ook interesse wekt voor het leggen van een basis voor hoe je je projecten organiseert en structureert.
Zoals gewoonlijk, aarzel dan niet om de discussie gaande te houden met opmerkingen, vragen en andere algemene feedback in de commentaarthread hieronder.
