Share
Vi snakker mye på dette nettstedet om tips og triks for å få det du vil ha ut av WordPress ... men i dag skal vi ta et skritt tilbake fra de tekniske tingene for å se på noen praksis, dårlige vaner og kodende faux pas som ville være bedre igjen i vår fortid. Så, tilgi den tyngdehente posttittelen (haha!). Vi snakker om å snakke opp 5 overraskende vanlige fremgangsmåter som er flekker på plattformen.
To av de fineste tingene om å jobbe på WordPress Temaer er det faktum at vi kommer til å målrette i en utrolig fleksibelt miljø (det vil si nettet) og vi har solid dokumentasjon for å hjelpe oss gjennom prosessen (det vil si WordPress Codex).
Tross alt, hvis temaet fungerer, betyr det rent, vedlikeholdsbar kode?
Men det er også en fare i temautvikling: Vi kan helt avstå fra beste praksis for å jobbe med nettet og ignorere dokumentasjonen helt. Spesielt er det ingenting som tvinger oss til å skrive ren, vedlikeholdbar kode. Tross alt, hvis temaet virker, betyr rent, vedlikeholdsbar kode? Videre, hvorfor gå gjennom arbeidet med å følge WordPress beste praksis hvis temaet ser ut til å fungere bra?
Svake argumenter, ikke sant? Jeg vet ikke - jo mer jeg har jobbet i WordPress-rommet, jo mer har jeg blitt overrasket over hvor mye dårlig kode faktisk eksisterer. Som sådan trodde jeg det ville vært morsomt å skissere fem kardinale synder av WordPress Theme Development.
Som med de fleste programmeringsspråk, rammer eller biblioteker inneholder WordPress en massiv mengde dokumentasjon. WordPress Codex er uten tvil den beste ressursen som utviklere har for å jobbe med WordPress. Tross alt gir det dokumentasjon for flertallet av søknaden.
Men WordPress Codex går ofte utover standard dokumentasjon - i tillegg til å levere funksjonsnavn og parametere, gir Codex rike eksempler på hvordan du bruker mange av API-funksjonene. Etter å ha lest en bestemt artikkel, vil du bli presset hardt for ikke å finne et klart eksempel på hvordan du skal fungere.
I tillegg til API-en inneholder Codex også en rekke andre artikler relatert til utvikling:
Når jeg jobber med et tema eller et plugin, og jeg treffer et punkt der jeg tror jeg må skrive en egendefinert funksjon for å oppnå noe, søker jeg først kodeksen. Mesteparten av tiden er en funksjon allerede tilgjengelig som hjelper med det jeg trenger.
Hver seriøs WordPress-utvikler bør regelmessig bruke Codex når han arbeider på et WordPress-relatert utviklingsprosjekt. Å ignorere det kan ofte føre til kreative, men uprøvde og ustabile løsninger som kan forårsake mer skade på linjen enn god.
For noen år siden, hvis du skulle spørre meg om tankene mine på å lokalisere et WordPress-tema, ville jeg ha sagt at det vil avhenge av markedsføringen du målretter mot. Det vil si hvis du tror at publikum skal bruke et annet språk enn ditt eget, gjør det definitivt, ellers er det ingenting galt med å forlate temaet oversatt på ditt eget språk.
Rask fremover noen få år, og WordPress 'driver millioner av nettsteder på Internett. Nettsteder over hele verden bruker programmet til å drive innholdet på nettstedet deres. På toppen av det blir det stadig vanligere for utviklere å supplere inntektene sine eller til og med gjøre seg av med å jobbe med WordPress.
Fordi WordPress har blitt så vidt vedtatt, og fordi Internett har gjort verden så flat, er markedet for et gitt tema ikke begrenset til et enkelt språk. På toppen av det gjør WordPress det så utrolig enkelt å lokalisere temaet ditt, og det krever så lite ekstra innsats, at jeg nå hevder at lokalisering av temaet ikke lenger er valgfritt.
For det meste må du forstå tre ting:
Annet enn det, er det svært lite ekstra kostnader som kommer med å lokalisere et tema; Jeg anbefaler imidlertid at du tar en titt på Oversetter WordPress-artikkelen i Codex. Det skisserer de tre tingene ovenfor og går mer grundig på hver.
Utviklere snakker mye om kodeorganisasjon og vedlikeholdsevne. Personlig tror jeg at det er mye lettere å gi leppe service til disse prinsippene enn å faktisk følge med med dem, men de er viktige.
Saken er, de ser annerledes ut for hver prosjekttype. Noen programmer er skrevet på et enkelt språk og kjører på et skrivebord, noen programmer bruker to språk og kjører på en mobil enhet. Andre prosjekter - for eksempel WordPress Themes - kan bruke alt fra tre (HTML, CSS og PHP) til fire ( gjennom JavaScript) språk. I tillegg kjører enkelte komponenter av temaet på klientsiden, noen kjører på server siden, noen fellesskap direkte med WordPress, og andre kommuniserer direkte med databasen.
Å si at det er potensial for å ofre vedlikehold er en underdrivelse.
Men det trenger ikke å være problematisk, da det er visse standarder som WordPress foreslår for å organisere temafilene dine. Nærmere bestemt beskriver Codex hvordan du organiserer PHP-malfiler, stilark, JavaScript-kilder og bilder.
Visst, det tar litt ekstra innsats å organisere filene dine i stedet for å gjøre nok for å "få det til å fungere", men utbyttet utbetales over tid mens du begynner å jobbe med neste versjon av temaet eller som flere utviklere begynner å jobbe på samme kodebase.
Selvfølgelig er filorganisasjon bare en del av utviklingsprosessen som påvirker organisasjon og vedlikehold. Deretter må vi fokusere på hvordan vi faktisk skriver koden som ligger i våre filer.
Tross alt, bør vi ikke bare gi velorganiserte filer, men også enkle å følge, standardkompatibel kode. Igjen gir WordPress Codex standardsett for de store språkene som bidrar til et temaes kodebase:
Mye å behandle, va? Saken er å bruke tid på å gjøre deg kjent med alle de ovennevnte utbyttene over tid. Bruk av disse standardene ved begynnelsen av utviklingen er eksponentielt billigere enn å måtte refactor et eksisterende tema eller plugin.
I tillegg resulterer det i å bidra til bedre kode tilbake til samfunnet.
Etter at et tema har blitt utviklet og klar for utgivelse, bør du i det minste gjøre en enkelt test. Det vil si at du bør bekrefte at de ulike stilene av postdata er formatert riktig, at temaet ditt ikke bruker noen avfallsfunksjoner, eller at det bruker feilfunksjoner feil.
Heldigvis gir Codex en rekke forslag og verktøy for å gjøre denne prosessen enklere.
Selvfølgelig er det også ytterligere testing du kan gjøre som tverrleser testing, HTML / CSS standarder samsvar, og så videre. Codex skisserer enda flere testforslag i Theme Testing Process artikkelen.
De sier at du ofte lærer av feilene dine, og jeg blir den første til å innrømme at jeg i løpet av min tid med WordPress har brutt alle disse. Men, som resten av utviklingssamfunnet, lærer du og du begynner å bygge bedre prosjekter med erfaring.
Dette er den første av denne typen "WordPress kultur" -artikler som vi legger ut på nettstedet ... så del dine egne erfaringer nedenfor - eller enda bedre, skriv om dem i lengden, og vi vil publisere det hvis det er flott!
Når det er sagt, dette er absolutt ikke den endelige listen, og jeg er sikker på at det er mer å legge til (vi har ikke engang berørt hacking kjernen, trakassere databasen eller hardkodende elementer som burde ha muligheter). Slipp dine egne kjærester i kommentarene!
Hva er noen av de mest irriterende, skadelige eller uholdbare praksisene som du har kommet over?
Accentsconagua