Share
En av de beste tingene med WordPress er dens livlige økonomi. For mange brukere er det trivielt enkelt å finne temaer som passer til designet som de sikter mot, eller for å finne plugins som gir funksjonalitet som de ønsker å introdusere i deres nettsted.
Men hvor mange av dere - som utviklere eller designere - har mottatt den telefonsamtalen eller den e-posten der kunden hevder at noe er galt med nettstedet deres bare for å oppdage at nettleserkonsollen viser noe om en feil som har å gjøre med JavaScript eller jQuery?
Nøyaktig. Sannsynligvis alle som har bygget og / eller vedlikeholdt et nettsted for noen, har kommet over dette problemet spesielt hvis sluttbrukeren får tillatelse til å legge til egne plugins, tillate egne oppdateringer, etc.
I dette innlegget skal vi gjennomgå noen begreper rundt jQuery og WordPress for å sikre at vi som utviklere ikke bare arbeider for å bygge våre produkter riktig, men at vi også vet hvordan vi skal diagnostisere problemer som de oppstår i kundens nettsteder.
Dette bestemte emnet er ikke nytt for Wptuts +. Faktisk har vi skrevet en omfattende artikkel om den før komplett med en rekke kodeeksempler, som alle skal gi deg alt du trenger for å forstå hvordan du arbeider med JavaScript innen WordPress.
Men når vi fortsetter å observere bestemte rutiner som skjer i samfunnet som vi vil gjerne hjelpe med å løse, har vi ikke noe imot å dekke flere aspekter av samme emne.
Så før du leser denne artikkelen, må du være sikker på at du er kjent med hvordan du inkluderer JavaScript og CSS i WordPress-temaene og pluginene.
Når det gjelder byggeprodukter i WordPress, er en av de tingene som vi som utviklere må forsøke å gjøre, å behandle WordPress-programmet som et fundament.
Akkurat nå gir API-en oss en enorm fleksibilitet når det gjelder å bygge temaer, plugins og applikasjoner, og dette er en god ting.
Men når vi begynner å fjerne biblioteker som sender med WordPress til fordel for våre egne, er det nesten som om vi lager en "mini-fork" av prosjektet.
Dette er ikke en god praksis å vedta.
Så vidt jeg er bekymret, sender WordPress med sitt kjernesett av funksjoner og biblioteker som gjør at det fungerer som det gjør. Endring av viktige deler av programmet - for eksempel jQuery - påvirker ikke bare WordPress selv, men hele økosystemet til produkter som er bygget på toppen av det.
Gode temaer og plugins avhenger av tilstedeværelsen av disse bibliotekene. Når vi endrer den funksjonaliteten, bryter vi potensielt hver arbeidsdel som er avhengig av dem.
Vi må slutte å se WordPress som noe vi kan ta fra hverandre og sette sammen igjen når vi trenger det, og se det som et grunnlag for å bygge vårt eget unike arbeid.
Generelt sett eksisterer problemet med JavaScript-konflikter av en av tre grunner. En utvikler har enten:
Først kan noen av de tre ovennevnte tilfellene gjøres på en gang, men oftere enn ikke en av de ovennevnte. For det andre tror jeg ikke at utviklere vanligvis gjør dette med dårlig hensikt.
Jeg tror det er mer mangel på utdanning og / eller forståelse for konsekvensene.
Ved dette mener jeg at utvikleren har fått feil tilgang til jQuery-biblioteket enten ved å utføre noConflict, ikke returnere variabelen riktig til sin opprinnelige tilstand, eller bare omdøpe shortcut-funksjonen.
Senere i denne artikkelen tar vi en titt på den beste praksisen for hvordan du skriver WordPress-spesifikke jQuery slik at det tillater oss å dra full nytte av biblioteket uten at det er i konflikt med andre plugins, temaer eller prosjekter..
Dette er noe som ofte gjøres med god hensikt: Ideen er at utvikleren gir en oppdatering til versjonen av jQuery som er inkludert i WordPress, slik at nye funksjoner eller mer moderne jQuery kan skrives.
Problemet med å gjøre dette er at tidligere utviklede prosjekter ikke er skrevet med noen av de nyere funksjonene i den nyeste versjonen av jQuery. Også, hvis jQuery har avskrevet eller helt fjernet en funksjon i den nye versjonen som var til stede i den gamle versjonen, vil det forhindre at koden fungerer.
Selv om dette er et mindre vanlig problem, er det noe som skjer noen ganger: I et forsøk på å bidra til at et nettsted lastes raskere, vil utviklerne flytte rekkefølgen der jQuery er lastet lenger ned på siden, vanligvis til bunnteksten.
Mens du laster inn JavaScript i fotfeltet til en side, oppfordres av et antall høyprofilerte nettsteder, går dette tilbake til å tenke på WordPress, holistisk, som grunnlag for applikasjonsutvikling.
Hvis WordPress, som standard, laster inn jQuery på et bestemt sted, må vi huske å la det være der, da alle arbeider som er bygget på toppen av applikasjonen, avhenger av at det er i den plasseringen og ingen andre steder.
Selv om det finnes en rekke forskjellige måter du kan forberede JavaScript-kildefilene dine på for å bruke jQuery, er det en måte jeg pleier å følge fordi den beskytter og encapsulates helt $ funksjon.
(funksjon ($) "bruk streng"; $ (funksjon () // Din kode her); (jQuery));
Du kan også se GitHub-gjesten her.
Kort oppsummert:
Dette gir en riktig lastet versjon av jQuery som bruker standarden
$funksjonsreferanse slik at vi kan fortsette å gå om vårt arbeid.
Merk at "bruk strenge"erklæring gir følgende:
Strenge modus er en ny funksjon i ECMAScript 5 som lar deg plassere et program, eller en funksjon, i en "streng" driftskontekst. Denne strenge konteksten forhindrer at visse handlinger blir tatt og kaster flere unntak
For de som er interessert, kan du lese mer om det på dette nettstedet.
Til slutt, den faktiske document.ready funksjonen er valgfri. Her brukes det bare for å vise hvordan du kan begynne å bruke standard jQuery-funksjonene innenfor konteksten av koden.
Vær oppmerksom på at neste versjon av WordPress planlegger å sende med en oppdatering som vil gjøre denne diskusjonen utdatert, i det minste så langt som instrumentbrettet går.
Spesielt er det for øyeblikket en billett i Trac der WordPress ikke tillater oss å fjerne jQuery fra Dashboard. Det er en god ting.
Kort sagt, de viktigste takeaways for denne artikkelen er som følger:
Accentsconagua
$ Fungerer ved hjelp av riktige JavaScript-funksjonerJeg vil si at å gjøre noe annet er å sette deg opp for potensielt dårlige resultater.
