Share
We praten veel op deze site over tips en trucs om te krijgen wat je wilt van WordPress ... maar vandaag gaan we een stapje terug doen van de technische dingen om te kijken naar sommige praktijken, slechte gewoonten en codering van faux pas die zouden zijn beter over in ons verleden. Dus, vergeef de hardhandige berichttitel (haha!), We praten over het brengen van 5 verrassend veel voorkomende praktijken die onvolkomenheden zijn op het platform.
Twee van de leukste dingen over werken aan WordPress Themes is dat we ons in een ongelooflijk flexibele omgeving (dat wil zeggen, het web) en we hebben solide documentatie om ons te helpen het proces te doorlopen (dat wil zeggen, de WordPress Codex).
Immers, als het thema werkt, is schone, onderhoudbare code van belang?
Maar er is ook een gevaar in de ontwikkeling van thema's: we kunnen de beste werkwijzen voor werken met internet volledig negeren en de documentatie volledig negeren. Concreet is er niets dat ons dwingt om schone, onderhoudbare code te schrijven. Immers, als het thema werkt, is schone, onderhoudbare code dan belangrijk? Bovendien, waarom zou je de moeite nemen om de best practices van WordPress te volgen als het thema goed lijkt te werken?
Zwakke argumenten, toch? Ik weet het niet - hoe meer ik in de WordPress-ruimte heb gewerkt, hoe meer ik erover verbaasd ben hoeveel slechte code er eigenlijk is. Als zodanig vond ik het leuk om vijf hoofdzonden van WordPress Theme Development te schetsen.
Zoals met de meeste programmeertalen, frameworks of bibliotheken, bevat WordPress een enorme hoeveelheid documentatie. De WordPress Codex is misschien wel de beste bron die ontwikkelaars hebben voor het werken met WordPress. Het biedt tenslotte documentatie voor de meerderheid van de applicatie.
Maar de WordPress Codex gaat vaak verder dan standaarddocumentatie - naast het leveren van functienamen en parameters, biedt de Codex rijke voorbeelden voor het gebruik van veel van de API-functies. Na het lezen van een bepaald artikel, zou het moeilijk zijn om geen duidelijk voorbeeld te vinden van hoe de functie in kwestie is.
Naast de API beschikt de Codex ook over een aantal andere artikelen met betrekking tot ontwikkeling:
Wanneer ik aan een thema of een plug-in bezig ben en ik een punt ophaal waarop ik denk dat ik een aangepaste functie moet schrijven om iets te bereiken, zal ik eerst de Codex doorzoeken. Het grootste deel van de tijd is er al een functie beschikbaar die helpt met wat ik nodig heb.
Elke serieuze WordPress-ontwikkelaar moet regelmatig de Codex gebruiken bij het werken aan een WordPress-gerelateerd ontwikkelingsproject. Het negeren ervan kan vaak leiden tot creatieve, maar niet geteste en onstabiele oplossingen die meer schade kunnen toebrengen dan goed.
Een paar jaar geleden, als je me mijn gedachten zou vragen over het lokaliseren van een WordPress-thema, had ik gezegd dat het afhing van de marketing die je target. Dat wil zeggen, als je denkt dat het publiek een andere taal gaat gebruiken dan je eigen taal, doe dat dan zeker; anders is er niets mis met het laten vertalen van het thema in uw eigen taal.
Een paar jaar snel vooruit en WordPress 'genereert miljoenen sites op internet. Sites over de hele wereld gebruiken de applicatie om de inhoud van hun site te genereren. Bovendien wordt het steeds gebruikelijker voor ontwikkelaars om hun inkomen aan te vullen of zelfs te leven van het werken met WordPress.
Omdat WordPress zo breed is toegepast en omdat internet de wereld zo plat heeft gemaakt, is de markt voor een bepaald thema niet beperkt tot één enkele taal. Bovendien maakt WordPress het zo ongelooflijk gemakkelijk om je thema te lokaliseren en het vereist zo weinig extra inspanning, dat ik nu beargumenteer dat het lokaliseren van je thema niet langer optioneel is.
Voor het grootste deel moet je drie dingen begrijpen:
Anders dan dat, is er heel weinig extra overhead die hoort bij het lokaliseren van een thema; ik raad echter aan om een kijkje te nemen in het artikel Translating WordPress in de Codex. Het schetst de drie dingen hierboven en gaat dieper in op elk.
Ontwikkelaars praten veel over code-organisatie en onderhoudbaarheid. Persoonlijk denk ik dat het veel gemakkelijker is om lippendienst te verlenen aan die principes dan ze daadwerkelijk te volgen, maar ze zijn belangrijk.
Het ding is, ze zien er anders uit voor elk projecttype. Sommige applicaties zijn geschreven in een enkele taal en worden op een desktop uitgevoerd, sommige applicaties gebruiken twee talen en worden op een mobiel apparaat uitgevoerd, andere projecten - zoals WordPress Themes - kunnen overal van drie (HTML, CSS en PHP) tot vier ( via JavaScript) talen. Bovendien werken bepaalde componenten van het thema op de client, sommige op de server, een community direct op WordPress, en anderen communiceren rechtstreeks met de database.
Zeggen dat er potentieel is om de onderhoudbaarheid op te offeren is een understatement.
Maar het hoeft geen probleem te zijn, want er zijn bepaalde standaarden die WordPress voorstelt voor het organiseren van uw themabestanden. Meer specifiek, de Codex beschrijft hoe u uw PHP-sjabloonbestanden, uw stijlbladen, JavaScript-bronnen en afbeeldingen moet ordenen.
Natuurlijk, het kost een beetje extra inspanning om je bestanden te ordenen in plaats van alleen genoeg te doen om het te laten werken, maar de dividenden worden na verloop van tijd uitbetaald wanneer je aan de volgende versie van je thema begint of omdat meerdere ontwikkelaars op hetzelfde beginnen te werken. codebase.
Natuurlijk is bestandsorganisatie slechts een deel van het ontwikkelingsproces dat van invloed is op de organisatie en onderhoudbaarheid. Vervolgens moeten we ons concentreren op hoe we de code schrijven die in onze bestanden zit.
We willen immers niet alleen goed georganiseerde bestanden bieden, maar ook eenvoudig te volgen, standaard-compliante code. Nogmaals, de WordPress Codex biedt een standaardset voor de belangrijkste talen die bijdragen aan de codebase van een thema:
Veel te verwerken, huh? Het ding is, tijd doorbrengen vertrouwd met al het bovenstaande betaalt dividenden in de tijd. Het toepassen van deze standaarden aan het begin van de ontwikkeling is exponentieel goedkoper dan het moeten refactoren van een bestaand thema of een plug-in.
Bovendien resulteert dit in het bijdragen van betere code aan de community.
Nadat een thema is ontwikkeld en klaar is voor uitgave, zou je - op zijn minst - een test moeten doen. Dat wil zeggen, u moet controleren of de verschillende stijlen van postgegevens correct zijn opgemaakt, dat uw thema geen verouderde functies gebruikt of dat het onjuiste functies gebruikt.
Gelukkig biedt de Codex een aantal suggesties en hulpmiddelen om dit proces veel gemakkelijker te maken.
Natuurlijk kunt u ook aanvullende tests uitvoeren, zoals testen voor meerdere browsers, naleving van HTML / CSS-normen, enzovoort. De Codex schetst nog meer testsuggesties in het artikel Thema Testproces.
Ze zeggen dat je vaak leert van je fouten en ik zal de eerste zijn om toe te geven dat ik tijdens mijn tijd met WordPress al deze dingen heb gebroken. Maar net als de rest van de ontwikkelingsgemeenschap leert u en begint u met het bouwen van betere projecten met ervaring.
Dit is de eerste van dit soort 'WordPress-cultuur'-artikelen die we op de site plaatsen ... dus deel je eigen ervaringen hieronder - of nog beter, schrijf er uitgebreid over en we publiceren het als het goed is!
Dat gezegd hebbende, dit is zeker niet de definitieve lijst en ik weet zeker dat er meer aan toe te voegen is (we hebben niet eens de kern van de hack aangeraakt, de database lastiggevallen of hard coderende elementen die opties zouden moeten hebben). Drop je eigen huisdier peeves in de comments!
Wat zijn enkele van de meest irritante, schadelijke of niet-duurzame praktijken die je bent tegengekomen?
Accentsconagua