Share
Gjennom hele denne serien har vi snakket om en rekke praksiser som vi kan benytte i WordPress-temautviklingen, som vil hjelpe ikke bare å gi et konsistent fundament som vi kan bygge våre eksisterende og fremtidige prosjekter på, men det vil også hjelpe oss opprettholde dem etter at de er utgitt.
Inntil dette punktet har vi dekket:
Før du går inn i denne artikkelen, anbefaler jeg at du leser de to første, slik at du kan få en følelse for det perspektivet vi tar når vi ser på temautvikling. I tillegg til disse punktene er det også en rekke verktøy som jeg tror skal installeres for å sikre at vi skriver den beste koden mulig.
Selvfølgelig er dette ikke bare i tillegg til de tidligere nevnte tipsene, men også anvendelsen av WordPress Coding Standards.
I denne siste artikkelen snakker jeg om flere forskjellige innstillinger og plugins som jeg tror bør defineres og / eller installeres i hver WordPress utviklingsmiljø for å sikre at du bruker de nyeste APIene, at du ikke påvirker ytelsen negativt, og at du ikke forårsaker noen varsler, advarsler eller feil som skal kastes via PHP.
Før vi hopper inn i å snakke om ulike plugins som er tilgjengelige, er det en rekke innstillinger som jeg anbefaler på det sterkeste å sette inn på din webserver og i ditt WordPress-miljø.
Noen av disse innstillingene vil bidra til funksjonaliteten til programtillegg som vi tar en titt på senere i denne artikkelen. Andre skal gi funksjonalitet som vil bidra til å varsle oss når vi gjør feil i PHP og / eller i vår WordPress -specifik kode.
Selv om ikke alle arbeider med Apache, PHP og MySQL, er det fortsatt uten tvil den vanligste konfigurasjonen som brukes når du arbeider med WordPress. En av de tingene jeg alltid anbefaler utviklere gjør i dette miljøet, er å sørge for at de har konfigurert PHP for å logge alt til en loggfil på maskinen sin.
Det er da gitt alternativene for å logge:
Pass på at du sjekker alt. Hvis du bruker et verktøy som MAMP, XAMPP eller WAMP, er dette vanligvis veldig enkelt å gjøre via brukergrensesnittet; Men hvis du ikke er sikker på hvor du skal konfigurere disse alternativene, kan du alltid sette dem inn php.ini ved hjelp av notatene som er skissert i PHP-håndboken.
Holder oversikt over feil som er logget som kanskje ikke vises på skjermen (selv om vi skal gjøre det vi kan for å sikre at vi gjøre se dem på skjermen senere i denne artikkelen) er viktig for å sikre at du skriver kode som fanger eventuelle potensielle problemer med koden.
Gitt dette, dette bør kunne gjøres ved bruk av andre webservere. Dette er egentlig egentlig bare en PHP-konfigurasjonsinnstilling - men jeg bruker for øyeblikket ikke mange av de andre alternativene som er tilgjengelige, så jeg ønsket å være eksplisitt om miljø der jeg konfigurerer innstillingene mine.
WP_DEBUG er en konstant som du kan sette inn i WordPress wp-config.php fil. De fleste installasjoner vil som standard ha dette settet til falsk. Hvis din er allerede satt til ekte, da betyr det at noen allerede har gjort det eller at du har en kopi av WordPress med innstillinger som er ikke sendt som standard fra WordPress.org.
Uansett, i konfigurasjonsfilen ser etter konstanten og hvis den er satt til falsk, så sett den til ekte. Hvis den ikke er funnet, legger du til linjen. Til syvende og sist er dette ditt functions.php filen skal inneholde (i tillegg til den andre koden som allerede var der):
Accentsconagua
define ('WP_DEBUG', true);Kort sagt, denne spesielle konstanten vil sørge for at PHP-merknader skrives ut på skjermen, så vel som WordPress-spesifikke feilsøkingsmeldinger. Dette er veldig nyttig når du jobber med et tema, og du prøver å sjekke, si, en tom indeks for en matrise eller du ender med å bruke en funksjon som ikke lenger støttes av den gjeldende versjonen av WordPress.
Det er også et fantastisk plugin knyttet til denne teknikken som vi dekker senere i denne artikkelen.
Også, det er også to flere konstanter som du kan definere som vil gi enda mer informasjon om hva dette vil. Du kan lese den tilsvarende Codex-artikkelen for mer informasjon, men kort sagt er konstantene og deres definisjoner som følger:
WP_DEBUG_DISPLAY er en annen følgesvenn til WP_DEBUG som kontrollerer om feilsøkingsmeldinger vises i HTML-siden eller ikke. Standard er "sant" som viser feil og advarsler når de genereres. Setter dette til falsk vil gjemme alle feilene. Dette bør brukes sammen med WP_DEBUG_LOG, slik at feilene kan vurderes senere.
Ut av boksen vil WordPress vise alle feil, advarsler og merknader i sammenheng med en side. Hvis du vil fortsette å feilsøke WordPress, men vil forhindre at informasjonen blir gjengitt til siden og bare skrevet til en loggfil, kan du sette dette konstant til falsk.
Personlig er jeg ikke en fan av å holde ting skjult som jeg liker å se problemer så snart de avles (les: så snart jeg har generert dem), men alle har forskjellige arbeidsflyter. Hvis du ser meldingene på sidene i konflikt med utviklingsstilen din, må du definere denne konstanten på riktig måte sammen med WP_DEBUG_LOG.
WP_DEBUG_LOG er en følgesvenn til WP_DEBUG som forårsaker at alle feil også lagres i en debug.log-loggfil inne i / wp-innholdet / katalogen. Dette er nyttig hvis du vil se gjennom alle meldinger senere, eller trenger å se meldinger som er generert på skjermen (for eksempel under en AJAX-forespørsel eller wp-cron-kjøring).
Dette er en nyttig konstant for å definere om du er stor på å overvåke feilloggene dine (som de fleste utviklere bør være). I tillegg til loggen generert av PHP, er dette enda en fil som kan gi innsikt om hva et gitt problem kan være og hvor det skjer når du jobber med et tema.
Denne konstanten er en annen som kommer til nytte med noen av pluginene som vi skal se på senere i denne artikkelen; Det er imidlertid verdt å sette inn functions.php selv om du ikke har flere plugins installert.
Først, som WP_DEBUG konstant over, kan du legge til dette til functions.php. Det skal se slik ut:
define ('SAVEQUERIES', true);Ser bra ut, men hva gjør det egentlig? SAVEQUERIES instruerer WordPress å holde styr på to ting:
Dette grensesnitt direkte med $ wpdb som er WordPress database klassen. Som nevnt tidligere, er det et annet plugin som fungerer direkte med denne spesielle konstanten slik at du kan se alle spørsmålene innen WordPress; Men hvis du hellere vil unngå å bruke et plugin for å bidra til å gjengi informasjonen, definerer du bare denne konstanten, og skriv deretter ut resultatet av $ Wpdb-> spørsmål til ditt valgte utgangsformat.
I tillegg til å sette inn konstanter, finnes det en rekke kraftige plugins som jeg tror skal installeres i hver utviklers WordPress-installasjon som kan gi enda mer hjelp når de brukes med innstillingene ovenfor.
Selv om mange av dere vil ha plugins for å legge til i denne listen, og andre vil ha meninger om hver av disse pluginene, er disse de som jeg har funnet å være mest nyttige i min utviklingsarbeid.
Feilsøkingsbar introduserer et alternativ i administrasjonslinjen i WordPress-installasjonen din som gir informasjon om spørringer, hurtigbufferen og annen informasjon.
Dette pluginet brukes best sammen med WP_DEBUG og SAVEQUERIES aktivert. Vær oppmerksom på at dette pluginet også kreves for et antall av programtilleggene jeg legger opp etter denne. Det vil si at den har en rekke utvidelser som gjør den enda sterkere.
Dette pluginet introduserer to flere faner i Debug Bar, som lar deg se alle handlinger og filtre (det vil si alle kroker) som utføres på gjeldende sideforespørsel.
Dette er svært nyttig hvis du bygger et komplekst tema, eller hvis du har arvet en kodebase fra noen andre, og du prøver å finne Hvorfor Det skjer visse ting som kanskje ikke er enkle å finne på grunn av måten temaet er bygget på.
Dessverre har denne plugin ikke blitt oppdatert om noen år, så jeg vet ikke hvor lenge det vil fortsette å fungere med WordPress (med mindre noen adopterer det til utvikling), men det fungerer sammen med Debug Bar for å gi deg evnen til å utføre PHP og MySQL direkte fra WordPress.
Dette er veldig nyttig når du prøver å finne ut hvorfor, sier en funksjon i temaet ditt, ikke fungerer som det skal være. Dvs. du kan skrive en funksjon direkte i konsollen, utføre den og se resultatet uten å stadig hoppe tilbake til IDE, endre funksjonen, oppdatere og sjekke resultatet.
Hvis du jobber med et tema som bruker mange stiler og mange JavaScript-filer, spesielt de som er avhengige av andre stilark og andre JavaScript-filer, er det nyttig å vite hvilken rekkefølge de skal lastes inn og hvordan de skal være lastet.
Det er her dette Debug Bar addon kommer inn i spill.
Det gjør det mulig for oss å visualisere rekkefølgen der skript og stiler lastes og utføres slik at vi kan gjøre de nødvendige endringene for å sikre at alle avhengigheter er lastet slik at de skal være for at vårt tema skal fungere skikkelig.
Hvis temaet introduserer egendefinerte innleggstyper i dashbordet, så er oddsene du har hatt å jobbe med en rekke forskjellige egenskaper, omskrive regler og mer.
Det kan bli komplisert veldig fort, avhengig av hvor mye du bestemmer deg for å justere funksjonene til den egendefinerte innleggstypen.
Denne plugin legger til enda et panel til Debug Bar, slik at du enkelt kan se egenskapene for hver posttype. Det tillater ikke endring eller redigering i fly (som det kan gjøres i Debug Bar Console eller det kan gjøres ved ganske enkelt å redigere definisjonen for egendefinert innleggstype), men det gir et mye renere format enn en gigantisk rekkefølge på skjermen av en IDE.
Dette er en enkel plugin som logger bruk av gamle filer, funksjon, argumenter og så videre til en fil. Spesielt når du skriver et tema, vil dette pluginet varsle når du kjører noe som ikke er 100% kompatibelt med den gjeldende versjonen av WordPress.
For de som vil forsikre seg om at de er fremtidssikre deres arbeid, og som holder seg oppdatert med de nyeste APIene, anbefaler jeg dette pluginet.
En av de største misforståelsene om WordPress er at det å kjøre mange plugins fører til at nettstedet ditt lastes langsomt, eller at mange plugins forårsaker oppblåsthet. Det er ikke sant. Det er dårlig skrevet plugins som gjør det. De som følger WordPress beste praksis og kodingsstandardene, bør ha minimal innvirkning på belastningstiden.
Med det sagt, vil dette pluginet identifisere nøyaktig hvilke plugins som påvirker ytelsen mest. Sikker på at dette kan være nyttig når du prøver å begrense årsaken til at et nettsted utfører sakte, men det er også nyttig å utføre mot din egen kode for å sikre at du er ikke påvirker nettstedets ytelse negativt.
For alle som har gjort omfattende arbeid med egendefinerte innleggstyper, egendefinerte ruter eller nettadresser, eller som har måttet gå inn i Rewrite API, vet du utfordringene som eksisterer.
Dette pluginet hjelper å gi en visuell fremstilling av omskrivningsregler for installasjonen. Det er nyttig for å inspisere regler som eksisterer innenfor det nåværende temaet, men også nyttig for å hjelpe deg med å feilsøke når du prøver å definere en tilpasset ordning og har en vanskelig tid å spikre det vanlige uttrykket for å gjøre det.
Hvis du ønsker å markedsføre pluginet ditt til det bredeste publikum, er det mulig å teste hvordan det ser ut på språk som leses fra venstre til høyre og høyre til venstre, så vel.
Det vil si hvis du vil sørge for at du har internasjonalt temaet ditt riktig, så vil dette pluginet la deg se hvordan arbeidet ditt ser ut til internasjonale språk.
Hvis du ønsker å selge ditt tema, si, på WordPress.com, så er dette et must-ha.
Hvis du ønsker å sikre at temaet ditt er oppdatert med de nåværende retningslinjene for WordPress Theme Review, er Theme Check et ikke-omsettelig.
Den vil utføre en automatisk revisjon av temaet ditt og vil sørge for at all koden din er på linje med de nåværende retningslinjene. Hvis ikke, vil det vise deg en ren utgave av problemene og koblingene til retningslinjene du ikke følger. Det gir også forslag til ting du burde ha implementert.
Merk at de fleste (hvis ikke alle) av disse er fritt tilgjengelige fra WordPress Plugin Repository, slik at de kan installeres direkte fra WordPress selv.
Som jeg har sagt i tidligere artikler, er mange av de tingene jeg har delt i denne serien, litt subjektive eller kanskje ikke fungerer i ditt nåværende miljø. Selv om praksis og verktøy som jeg har delt, har blitt prøvd og bevist gjennom hele min personlige erfaring med å jobbe med WordPress i flere år, innser jeg også at vi ikke alle bruker samme verktøysett.
Som sådan betyr dette at noen av konfigurasjon, organisasjon og innstillinger kan variere for deg. Det er ok. Til slutt er poenget at vi som temautviklere trenger å gjøre en bedre jobb med å skrive vedlikeholdbare temaer fordi vi bruker så mye tid på å jobbe med dem etter deres første utgivelse.
Kanskje noen av tingene som foreslås gjennom hele denne serien, vil hjelpe deg med å gjøre nettopp det. Kanskje du må finjustere noen av forslagene for å matche verktøyene du bruker. Uansett hva som helst, håper jeg at det ikke bare har vært en nyttig serie med noen praktiske tips for å hjelpe deg med din pågående temautvikling, men at det også har gitt interesse for å sette grunnlaget for hvordan du organiserer og strukturerer prosjektene dine fremover.
Som vanlig, vær så snill å fortsette diskusjonen med kommentarer, spørsmål og annen generell tilbakemelding i kommentaren nedenfor.
