Share
Werken in de WordPress-gemeenschap is zowel een zegen als een vloek. Vanwege zijn open source karakter hebben we een fantastisch platform waarop we websites, thema's, plug-ins en zelfs applicaties kunnen bouwen. Het heeft een slimme gemeenschap eromheen, rijke documentatie en normen die gericht zijn op het bieden de weg om er code voor te schrijven en de weg om er gereedschap omheen te bouwen.
Tegelijkertijd stelt het open source karakter van WordPress en de talen waarmee het is gebouwd iedereen in staat om hun werk te verzenden, ongeacht of het aan eender welke norm voldoet of een best practice gebruikt. Voor veel gebruikers zijn ze geen wijzer over wat er onder de motorkap gebeurt. Als het product werkt, zijn ze gelukkig.
Als mensen die serieus bezig zijn met hun vak, kunnen we absoluut niet genoegen nemen met "het gewoon aan het werk krijgen". Wij hebben om te geven om wat er onder de motorkap zit.
Als je een serieuze WordPress-ontwikkelaar bent, dan heb je waarschijnlijk al een methode om te werken, maar als je net begint of jezelf wilt definiëren als een professionele WordPress-ontwikkelaar, dan zijn er strategieën, omgevingen en hulpmiddelen dat u kunt gebruiken dat kan helpen.
In deze drie artikelseries gaan we precies kijken wat die zijn en hoe ze van toepassing zijn in ons projectwerk. Eerst zullen we beginnen met strategieën.
Een aanzienlijk deel van het bouwen van software is eigenlijk het onderhouden na de eerste lancering. De waarheid is dat er meer tijd wordt besteed aan het onderhouden van projecten dan aan het bouwen ervan. Het is logisch, toch? Een product bestaat veel langer dan nodig is om het te maken, en ervan uitgaande dat het van hoge kwaliteit is, zullen gebruikers fouten opsporen en nieuwe functies aanvragen.
Helaas wordt een aanzienlijke hoeveelheid onderhoudstijd besteed aan het oplossen van een fout of het snel toevoegen van een nieuwe functie en wordt dit vaak gedaan op een manier die er meer op gericht is om het voor elkaar te krijgen dan om het goed te doen. Dit is ook niet helemaal verkeerd - wanneer een product direct is gekoppeld aan de bedrijfsresultaten, is tijd een prioriteit.
Maar er zijn dingen die tijdens de eerste ontwikkeling gedaan kunnen worden, die een lange weg kunnen afleggen om het gemakkelijker te maken om een product te behouden na de lancering.
De WordPress Codex biedt een uitgebreide handleiding voor het maken van thema's. Het behandelt stylesheethandleidingen, sjabloonbestanden, JavaScript-informatie, testrichtlijnen, checklists en verschillende referenties. Zelfs als u bezig bent met het bouwen van thema's, raad ik u ten zeerste aan deze lijst van tijd tot tijd te bekijken.
Naast het volgen van de basisset van richtlijnen zijn er nog andere dingen die kunnen worden gedaan om het onderhoud te verbeteren. Ervan uitgaande dat u de Codex-richtlijnen voor het bouwen van thema's volgt, overweeg dan het volgende met betrekking tot enkele van uw activa en afhankelijkheden.
Een van de dingen die ik voor elk van mijn projecten doe, is ervoor zorgen dat ik specifieke mappen heb voor items buiten de normale bestanden die nodig zijn voor thema-ontwikkeling. Hiermee bedoel ik dat ik specifieke mappen heb voor:
Toegegeven, elk thema vereist minstens één enkel stylesheet, maar stel dat u speciaal voor het administratieve dashboard stylesheets gaat aanbieden. Voor onderhoud is het beter om ze gescheiden te houden dan in een enkel stylesheet en een tool toe te staan om ze te combineren voordat ze worden vrijgegeven.
We zullen een kijkje nemen op tooling voor precies dit in het laatste artikel in de serie.
Waar je ook terechtkomt, een klein beetje plannen vooraf kan een hele goede set aan bezittingen opleveren.
Wanneer we bedenken hoe we onze verschillende middelen het best kunnen organiseren, kunnen naamgevingsconventies helpen om een niveau van duidelijkheid te bieden en een standaard te bieden waarmee alle gerelateerde bestanden moeten volgen. In elk van mijn projecten bijvoorbeeld, doe ik meestal het volgende:
Natuurlijk zijn er enkele universele JavaScript- en stylesheets die overal in het thema worden toegepast. In dit geval onderhoud ik eenvoudig een set admin.css en style.css bestanden.
De meeste WordPress-ontwikkelaars weten dat plug-ins thema-agnostisch moeten zijn. Dat wil zeggen, ze zouden niet afhankelijk moeten zijn van een functie van een bepaald thema, noch zouden ze een van hun stylesheets of JavaScripts moeten opleggen aan het bestaande thema, behalve hun eigen specifieke functie.
Daarbovenop zijn er twee manieren om plug-ins te ontwikkelen:
Daartoe zijn er een paar strategieën die kunnen worden gebruikt bij het schrijven van uw plug-ins om ervoor te zorgen dat de stylesheets, JavaScript, afbeeldingen en andere items niet in strijd zijn met het bestaande thema.
Als het gaat om het schrijven van plug-ins, maken de verschillende API's het meestal gemakkelijk om de talen die u gebruikt om uw plug-in te bouwen, te mixen en matchen. Daarmee bedoel ik dat het volledig mogelijk is om alle stijlen, JavaScripts, HTML en PHP in één bestand op te nemen en het vervolgens te verzenden.
Maar ik ben hier geen fan van.
Typisch, elke taal dient een specifiek doel, en daarom probeer ik elke taal zoveel mogelijk in zijn eigen bestand te houden. Overweeg dit:
Als zodanig denk ik dat het logischer is om de bestanden gescheiden te houden, zodat je weet waar je moet focussen wanneer een probleem zich voordoet of het tijd is om een nieuwe functie te introduceren.
Dit betekent niet dat je niet af en toe PHP hebt geschreven in je opmaak of dat je niet dynamisch HTML-elementen aan de serverkant zult maken, maar het is bedoeld om een basis te bieden van waaruit je je werk organiseert.
Naast dat elke set stylesheets en JavaScript-bestanden duidelijk worden genoemd, heb ik de neiging dezelfde structuur te volgen die ik voor thema's hanteer en dat is om de administratiespecifieke code met de prefix te noemen beheerder en thema of publiek-specifieke code met tonen.
Het is een eenvoudige strategie, maar het helpt je bij het optimaliseren van waar je je bestanden plaatst en bij het onderhouden van problemen zoals ze zich voordoen wanneer je werk in de vrije natuur is.
Het punt dat dit beslaat, is niet opleggen mijn manier om bestanden in uw systeem te organiseren of zelfs te zeggen dat dit een standaard manier is om het te doen. Het is bedoeld als een startpunt voor het onderhoud van uw projecten.
Uiteindelijk gaat het erom onderhoud zoveel mogelijk te beperken. Met duidelijk gedefinieerde naamconventies en een standaard voor de organisatie, weet u precies hoe en waar u uw bestanden kunt plaatsen zonder giswerk te doen en uw bijdragers en / of teamleden weten waar ze zich moeten concentreren om problemen op te sporen zodra ze aankomen.
Een van de uitdagingen waarmee ontwikkelaars worden geconfronteerd, is ervoor zorgen dat ze bekend zijn met de juiste manieren om gebruik te maken van het platform waarop ze werken.
Voor het grootste deel omvat elke taal, elk raamwerk en elke bibliotheek een vorm van documentatie en WordPress is niet anders. Het ding is, WordPress is samengesteld uit verschillende stukken - niet alleen is de applicatie gebouwd met behulp van PHP, maar er zijn toepassingsspecifieke API's, evenals bibliotheken zoals jQuery die nodig zijn om te hebben als referenties.
Omdat het erg lang duurt om intiem vertrouwd te raken met de ins en outs van elke taal, applicatie en bibliotheek, hebben professionele WordPress-ontwikkelaars meestal referenties direct beschikbaar. Voor WordPress-ontwikkelaars zijn de volgende referenties uiterst waardevol.
Voor het grootste deel is dat het - maak een bladwijzer voor die of laat ze direct beschikbaar zijn in uw IDE (als het dit ondersteunt), breng tijd door in elk van hen en u zult goed op weg zijn naar meer professionele ontwikkelingspraktijken.
Voor zover strategieën gaan, dekt dit het. Stel eenvoudigweg een gedefinieerde manier in om uw bestanden te ordenen en een naam te geven, zorg ervoor dat u de best practices van de kern WordPress API volgt, en zorg ervoor dat u de API-documenten van de verschillende talen raadpleegt wanneer u uw werk bouwt, en u zult er zijn een veel betere positie dan simpelweg uw werk van de manchet af te maken.
.
Accentsconagua