Share
Å vite riktig måte å inkludere JavaScript og CSS-filer i WordPress-temaene og pluginene er svært viktig for designere og utviklere. Hvis du ikke overholder beste praksis, risikerer du å være i konflikt med andre temaer og plugins, og potensielt kan du opprette problemer som lett kunne unngås. Denne artikkelen er ment som en referanse for å leke pent med andre.
Før vi kommer i gang, kan du bla gjennom WordPress Themes og WordPress Plugins, hvis du trenger å starte ditt neste prosjekt profesjonelt.
Og hvis du, etter å ha lest denne opplæringen, fortsatt ikke er sikker på hvordan du inkluderer JavaScript og CSS-filene på riktig måte, kan det være verdt å bestille noen av WordPress-tjenestene som er tilgjengelige på Envato Studio.
Fra installasjon til tilpasning, eller til og med SEO og hastighetsoptimalisering, kan du få en profesjonell WordPress-ekspert til å sette opp ting på riktig måte fra begynnelsen.
Hvis du noen gang har utviklet et tema eller et plugin for WordPress, eller jobbet med en som noen andre har opprettet, har du sannsynligvis kommet over flere forskjellige metoder for å inkludere JavaScript og CSS. Selv om det finnes flere metoder som kan synes å virke i et bestemt sett av omstendigheter, er det en primær metode som anbefales i WordPress Codex. Denne foretrukne måten sikrer at temaet eller plugin-funksjonen fungerer i alle tilfeller, forutsatt at andre også koder den riktige måten.
Det er også litt misforståelse om hva Codex sier om dette, som jeg vil bidra til å avklare.
Når du laster ned WordPress, er et utvalg av vanlige JavaScript-biblioteker allerede inkludert som du kan bruke til JavaScript-utviklingen. En liste over inkluderte biblioteker finnes i WordPress Codex wp_enqueue_script artikkel.
Alle disse bibliotekene er inkludert, men som standard laster WordPress bare de som den trenger, og bare når den trenger dem i administrasjonen. Hvis du skriver JavaScript som bruker et av disse bibliotekene, må du fortelle WordPress at skriptet ditt trenger biblioteket lastet først.
Noen av tingene du kan tenke på når du koder JavaScript for WordPress, er:
Å svare på disse spørsmålene hjelper deg å vite hva du trenger å gjøre for å registrere og laste inn skriptet ditt. Dette gjøres ved hjelp av en WordPress-funksjon kalt wp_register_script, og her er bruken i henhold til WordPress Codex:
wp_register_script ($ handle, $ src, $ deps, $ ver, $ in_footer);
Så hva er disse variablene og trenger vi dem hver gang? (Dette er dekket på Codex-siden, så jeg vil være kort og bruke vanlig engelsk)
Accentsconagua
$ håndtak - hva du vil bruke til å referere til dette spesielle skriptet, uansett hvor du kanskje trenger å enqueue det, og du må minst inkludere denne variabelen$ src - banen til kildefilen i plugin eller tema$ deps - en matrise som inneholder $ håndtak for andre skript må skriptet ditt kjøre (dvs. en avhengighet)$ ver - Versjonsnummeret for skriptet ditt, som kan brukes til cache-busting. Som standard vil WordPress bruke sitt eget versjonsnummer som versjonsnummer for skriptet ditt$ in_footer - vil du at skriptet ditt skal lastes i bunnteksten? Sett dette til ekte eller falsk. Det er falsk som standard, så det laster i overskriften der wp_head () er, og hvis du spesifiserer ekte det vil laste hvor wp_footer () vises i temaetNettlesere husker hvilke skript og stilark de har lastet ned for et bestemt nettsted basert på nettadressen til manuset og stilarket. Hvis du endrer nettadressen, til og med bare ved å legge til en spørringstreng, forutsetter nettleseren at den er en ny fil og laster den ned.
Her er det mest grunnleggende eksempelet for å laste et tilpasset skript:
funksjon wptuts_scripts_basic () // Registrer skriptet slik som for et plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // eller // Registrer skriptet slik som et tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js'); // For enten et plugin eller et tema, kan du da skrive inn skriptet: wp_enqueue_script ('custom script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic'); Først registrerer vi skriptet, så WordPress vet hva vi snakker om. Måten å finne banen for JavaScript-filen, er annerledes om vi kodes et plugin eller et tema, så jeg har tatt med eksempler på begge over. Da køber vi den til å bli lagt til HTML for siden når den genereres, som standard i hvor i wp_head () er i temaet.
Utgangen vi får fra det grunnleggende eksemplet er:
Nå hvis skriptet er avhengig av et av bibliotekene som følger med WordPress, som jQuery, kan du gjøre en veldig enkel endring til koden:
funksjon wptuts_scripts_with_jquery () // Registrer skriptet slik som for et plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery')); // eller // Registrer skriptet slik som for et tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // For enten et plugin eller et tema, kan du da skrive inn skriptet: wp_enqueue_script ('custom script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_jquery'); Merk: Som standard er jQuery lastet med noConflict for å forhindre sammenstøt med andre biblioteker (for eksempel Prototype). Se noConflict-delen av Codex hvis du ikke vet hvordan du skal håndtere det.
Se hva jeg gjorde der? Du legger bare til en matrise med "jquery" -håndtaket som en avhengighet. Den bruker en matrise her, fordi skriptet ditt kan ha flere avhengigheter. Hvis skriptet ditt bruker jQuery og jQuery brukergrensesnitt, vil du legge til jQuery-brukergrensesnittet i din avhengighetsgruppe, som array ('jquery', 'jquery-ui-core')
Så nå har produksjonen endret seg, og vi kan se at jQuery også er lagt til i av siden:
La oss prøve et eksempel med alle bjeller og fløyter:
funksjon wptuts_scripts_with_the_lot () // Registrer skriptet slik som for et plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery', 'jquery-ui -core '),' 20120208 ', true); // eller // Registrer scriptet som dette for et tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery', 'jquery-ui-core' ), '20120208', sant); // For enten et plugin eller et tema, kan du da skrive inn skriptet: wp_enqueue_script ('custom script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_the_lot'); Ok, så jeg har nå lagt til en versjon og angitt at dette skriptet må lastes i bunnteksten. For versionsnummeret har jeg valgt å bruke dagens dato fordi det er lett å holde styr på, men du kan bruke hvilken som helst versjon som du liker. Utgangen for denne er litt annerledes også, jQuery er utgang i og vårt skript sammen med jQuery brukergrensesnitt er utdata like før , som dette:
... ... ...
Noen mennesker foretrekker kanskje ikke å bruke de riktige enqueuing-metodene fordi de føler at de har mindre kontroll over rekkefølgen der skript er lastet. For eksempel, i et tema som bruker modernizr, kan temaforfatteren kanskje sørge for at modernizr er lastet tidlig.
Noe jeg ikke har nevnt tidligere, er mer detaljert på hvordan ADD_ACTION funksjon fungerer, da dette er hvor vi kan utøve liten innflytelse på rekkefølgen av ting. Her er bruken av funksjonen i henhold til WordPress Codex-siden:
add_action ($ tag, $ function_to_add, $ priority, $ accepted_args);
Legg merke til at ofte, og frem til nå i denne artikkelen, bare $ tag og $ function_to_add parametere brukes. De $ prioritet Parameterinnstillinger til 10, og $ accepted_args parametervalg til 1. Hvis vi vil at våre skript eller stiler skal skrives tidligere, setter vi bare verdien for $ prioritet fra standard. For eksempel:
funksjon wptuts_scripts_important () // Registrer skriptet slik som for et plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // eller // Registrer skriptet slik som et tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js'); // For enten et plugin eller et tema, kan du da skrive inn skriptet: wp_enqueue_script ('custom script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_important', 5); Utgangen vil være den samme som vi har sett tidligere, men det vil oppstå tidligere i HTML-dokumentet.
Det kan være ganger når du vil bruke en annen versjon av et bibliotek som er inkludert i WordPress. Kanskje du vil bruke en banebrytende versjon, eller du vil ikke vente på neste utgave av WordPress før du bruker den nyeste stabile versjonen av jQuery. En annen grunn kan være at du vil dra nytte av Googles CDN-versjon av et bibliotek.
Det er viktig å merke seg at dette skal bare gjøres på plugins eller temaer som brukes på nettsteder du vil være personlig vedlikehold. Eventuelle plugins eller temaer som du slipper for offentlig bruk, bør bruke biblioteker som følger med WordPress.
"Hvorfor?!", Jeg hører deg spørre. Av den enkle grunnen at du ikke kontrollerer disse nettstedene. Du vet ikke hva andre plugins og temaer kan brukes der, og du vet ikke hvor ofte de vil oppdatere plugin eller tema. Bruk av bibliotekene pakket med WordPress er det sikreste alternativet.
Når du har sagt det, hvis du ønsker å gjøre dette på et nettsted du kontrollerer, så er det slik det er gjort:
funksjon wptuts_scripts_load_cdn () // Deregister det medfølgende biblioteket wp_deregister_script ('jquery'); // Registrer biblioteket igjen fra Googles CDN wp_register_script ('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array (), null, false ); // Registrer skriptet slik som for et plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery')); // eller // Registrer skriptet slik som for et tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // For enten et plugin eller et tema, kan du da skrive inn skriptet: wp_enqueue_script ('custom script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_load_cdn'); Så først og fremst avregistrerer jeg den medfølgende versjonen av biblioteket, ellers kan konflikter mellom forskjellige versjoner bli introdusert. Registrer deretter den alternative versjonen, med samme håndtak, og jeg har valgt å angi null som versjon (den er allerede i nettadressen!) Og angitt ikke i bunnteksten. Resten av koden vår er den samme, fordi vi var avhengig av hvilket skript som helst som brukte jquery-håndtaket. Utgangen vi får nå ser ut som:
Merk: En av grunnene til at dette er en dårlig ide å gjøre i et plugin eller tema for offentlig utgivelse, er at alle andre plugins og temaer som brukes på dette nettstedet, nå må bruke denne versjonen av jQuery. Også den nylig registrerte versjonen av jQuery har ikke noConflict-sett, så hvis noen andre plugin- eller tema-skript bruker Prototype for eksempel, Dette vil bryte ting.
Så langt har vi ikke nevnt noe om hvordan du gjør alt dette i administrasjonen, bare på forsiden. Den primære forskjellen er hvilken handling du skal bruke. I stedet for add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic'); som vi bruker til frontend, er handlingen for administrasjonen add_action ('admin_enqueue_scripts', 'wptuts_scripts_basic');
Noe som er viktig å gjøre for både frontend og admin, er selektiv om hvilke sider du laster inn skriptene på. Hvis plugin eller tema har et skript som bare gjør noe på en forside eller admin side, for eksempel temaets valgside, eller kanskje en side med en bestemt widget, trenger du bare å laste skriptet på den siden. Ikke noe å tette opp ting og laste inn skript på sider der de ikke blir brukt!
Det er et godt eksempel i WordPress Codex om hvordan du laster inn skript bare på plugin-sider. Fordi plugins og temaer kan variere mye i hvordan de er skrevet, vil jeg ikke gå inn i detaljer her på hvordan å være kresne om hvilke sider du laster inn skript på, men det var viktig å nevne slik at du er klar over det når du er koding.
Prosessen for stiler er nesten nøyaktig den samme som prosessen for skript. Det er gjort ved hjelp av en WordPress-funksjon kalt wp_register_style, og her er bruken i henhold til WordPress Codex:
wp_register_style ($ håndtak, $ src, $ deps, $ ver, $ media);
Legg merke til at den eneste forskjellen er mellom wp_register_script og wp_register_style er det i stedet for en $ in_footer parameter, vi har a $ media parameter. Denne parameteren kan settes til et av følgende: 'alle', 'skjerm', 'Håndholdt', og 'skrive ut', eller hvilken som helst annen W3C-anerkjent medietype.
Så et eksempel på hvordan du kan enqueue en stil ville være:
funksjon wptuts_styles_with_the_lot () // Registrer stilen som dette for et plugin: wp_register_style ('tilpasset stil', plugins_url ('/css/custom-style.css', __FILE__), array (), '20120208', 'alle '); // eller // Registrer stilen som dette for et tema: wp_register_style ('tilpasset stil', get_template_directory_uri (). '/css/custom-style.css', array (), '20120208', 'alle'); // For enten et plugin eller et tema, kan du enqueue stilen: wp_enqueue_style ('custom-style'); add_action ('wp_enqueue_scripts', 'wptuts_styles_with_the_lot'); Dette er et ganske omfattende eksempel ved å utnytte de fleste parametrene, og produksjonen det produserer ser ut som:
Godt spørsmål, og det andre spørsmålet jeg antar du kan spørre, er: "Hva får deg til å tro at dette er riktig måte og ikke bare din preferanse?". I hovedsak er svaret at dette er tilnærmingen anbefalt av WordPress. Det sikrer at enhver kombinasjon av plugins og temaer skal kunne samarbeide lykkelig og uten å fordoble seg.
Jeg har sett noen temaer og rammer rundt det stedet som bruker og merker i deres header.php, Til og med footer.php, filer for å laste inn skript og stiler for selve temaet. Det er virkelig ingen grunn til å gjøre ting på denne måten. Som jeg har vist ovenfor, er det helt mulig å prioritere skript og stiler og nominere om de laster inn overskriften eller bunnteksten fra komforten og sikkerheten til din functions.php. Fordelen er at ditt tema / rammeverk vil fungere med et bredere spekter av andre plugins / barnemner.
Et eksempel var å laste jQuery ved hjelp av koder, som ser ut til å fungere pent, men dette kan faktisk føre til at jQuery lastes to ganger! Laster jQuery på denne måten vil ikke stoppe WordPress fra å laste sin versjon av jQuery for andre plugins, da WordPress 'versjonen er i noConflict-modus som standard, og et plugin kan angi det som en avhengighet. Så nå har du jQuery som arbeider for både noConflict-modus og $, og bryter også sannsynligvis noen plugin som bruker Prototype-biblioteket.
WordPress er et fantastisk system, og det har blitt utviklet med stor tanke. Hvis det er en mekanisme som er tilgjengelig for å gjøre noe, er det ofte en god ide å bruke den. Når du utvikler plugins og temaer, prøv å huske å kode omtenksomt og for å leke pent med andre.
Hva synes du om bruken av wp_enqueue_script og dets tilknyttede funksjoner og handlinger? Kjenner du om noen eksempler hvor det blir gjort feil? Vet du uansett grunn til ikke å følge rådene ovenfor?
Hvis du trenger en ferdig løsning, kan du bla gjennom Wordpress-temaene og Wordpress-pluginene på Envato Market.
