Så här inkluderar du JavaScript och CSS i dina WordPress-teman och plugins

Att veta rätt sätt att inkludera JavaScript och CSS-filer i WordPress-teman och plugins är mycket viktigt för designers och utvecklare. Om du inte följer bästa praxis riskerar du att störa andra teman och plugins, och eventuellt skapa problem som lätt skulle kunna undvikas. Denna artikel är avsedd som en referens för att leka snyggt med andra.

Innan vi börjar kan du bläddra genom våra WordPress-teman och WordPress-plugins, om du behöver kickstart ditt nästa projekt professionellt.

Och om du, efter att ha läst den här handledningen, fortfarande inte är säker på hur du inkluderar dina JavaScript och CSS-filer på rätt sätt, kan det vara värt att beställa några av de WordPress-tjänster som finns på Envato Studio.

Från installation till anpassning, eller till och med SEO och hastighetsoptimering, kan du få en professionell WordPress-expert för att ställa upp saker på rätt sätt från början.

Bästa praxis gör alla lyckliga

Om du någonsin har utvecklat ett tema eller plugin för WordPress, eller arbetat med en som någon annan har skapat, har du förmodligen stött på flera olika metoder för att inkludera JavaScript och CSS. Även om det finns flera metoder som kan verka att fungera under en viss omständighet, finns det en huvudmetod som rekommenderas i WordPress Codex. Detta föredragna sätt säkerställer att ditt tema eller plugin fungerar i alla fall, förutsatt att andra också kodar rätt sätt.

Det finns också lite missförstånd om vad exakt Codex säger om detta, vilket jag kommer att hjälpa till att klargöra.

Vad finns i boxen?

När du laddar ner WordPress ingår redan ett urval av vanliga JavaScript-bibliotek som du kan använda för din JavaScript-utveckling. En lista över inkluderade bibliotek finns i WordPress Codex wp_enqueue_script artikel.

Alla dessa bibliotek ingår, men som standard fyller WordPress bara de som behövs, och endast när det behövs dem i admin. Om du skriver JavaScript som använder ett av dessa bibliotek måste du berätta för WordPress att ditt skript behöver biblioteket laddat först.

Berätta WordPress om ditt script och vad det behöver

Några av de saker du ska tänka på när du kodar JavaScript för WordPress är:

Finns det ett medföljande bibliotek som jag kan använda?
Kan jag använda den version som ingår?
Behöver jag ladda mitt skript i fronten och i admin?
Vilka front-end och admin sidor behöver jag ladda mitt skript på?

Att svara på dessa frågor hjälper dig att veta vad du behöver göra för att registrera och ladda ditt skript. Detta görs genom att använda en WordPress-funktion som heter wp_register_script, och här är dess användning enligt WordPress Codex:

wp_register_script ($ handtag, $ src, $ deps, $ ver, $ in_footer);

Så vad är dessa variabler och behöver vi dem varje gång? (Detta är täckt på Codex-sidan, så jag ska vara kortfattad och använda vanlig engelska)

$ handtag - vad du ska använda för att hänvisa till det här skriptet, var du kanske behöver göra det, och du måste inkludera den här variabeln åtminstone
$ src - sökvägen till källfilen i ditt plugin eller tema
$ deps - en matris som innehåller $ handtag för andra skript behöver ditt skript springa (det vill säga ett beroende)
$ ver - Versionsnumret för ditt skript, som kan användas för cache-busting. Som standard använder WordPress sitt eget versionsnummer som versionsnummer för ditt skript
$ in_footer - vill du att ditt skript ska laddas i sidfoten? Ställ in detta till Sann eller falsk. Det är falsk som standard, så det laddas i rubriken där wp_head () är, och om du anger Sann det kommer att ladda var wp_footer () visas i temat

Vad är "Cache-Busting"?

Webbläsare kommer ihåg vilka skript och formatmallar de har hämtat för en viss webbplats baserat på webbadressen för manuset och stilarket. Om du ändrar webbadressen, till och med bara genom att lägga till en fråga, antar webbläsaren att det är en ny fil och hämtar den.

Ok, så låt oss försöka några exempel

Här är det mest grundläggande exemplet för att ladda ett eget skript:

funktion wptuts_scripts_basic () // Registrera skriptet så här för ett plugin: wp_register_script ('custom script', plugins_url ('/js/custom-script.js', __FILE__)); // eller // Registrera skriptet så här för ett tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js'); // För antingen ett plugin eller ett tema kan du skicka skriptet: wp_enqueue_script ('custom script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic');

Först registrerar vi skriptet, så WordPress vet vad vi pratar om. Sättet att hitta sökvägen för vår JavaScript-fil är annorlunda om vi kodar ett plugin eller ett tema, så jag har tagit med exempel på båda ovanstående. Sedan köper vi den i HTML-koden för sidan när den genereras, som standard i där det wp_head () är i temat.

Utgången vi får från det grundläggande exemplet är:

Nu om ditt skript bygger på ett av biblioteken som ingår i WordPress, som jQuery, kan du göra en mycket enkel ändring till koden:

funktion wptuts_scripts_with_jquery () // Registrera skriptet så här för ett plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery')); // eller // Registrera skriptet så här för ett tema: wp_register_script ('custom script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // För antingen ett plugin eller ett tema kan du skicka skriptet: wp_enqueue_script ('custom script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_jquery');

Notera: Som standard är jQuery laddad med noConflict för att förhindra sammandrabbningar med andra bibliotek (till exempel Prototype). Se avsnittet NoConflict i Codex om du inte vet hur man hanterar det.

Se vad jag gjorde där? Du lägger bara till en matris med "jquery" handtaget som ett beroende. Det använder en matris här, eftersom ditt skript kan ha flera beroenden. Om ditt skript använder jQuery och jQuery UI, lägger du till jQuery-gränssnittet till ditt beroendeberättigande, som array ('jquery', 'jquery-ui-core')

Så nu har produktionen ändrats, och vi kan se att jQuery också har lagts till i av sidan:

Låt oss försöka ett exempel med alla klockor och visselpipor:

funktion wptuts_scripts_with_the_lot () // Registrera skriptet så här för ett plugin: wp_register_script ('custom script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery', 'jquery-ui -core '),' 20120208 ', true); // eller // Registrera skriptet så här för ett tema: wp_register_script ('custom script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery', 'jquery-ui-core' ), "20120208", sant); // För antingen ett plugin eller ett tema kan du skicka skriptet: wp_enqueue_script ('custom script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_the_lot');

Ok, så jag har nu lagt till en version och angett att det här skriptet måste laddas i sidfoten. För versionsnumret har jag valt att använda dagens datum eftersom det är lätt att hålla reda på, men du kan använda vilken versionsnummer du vill ha. Utsignalen för denna är något annorlunda också, jQuery matas ut i och vårt skript tillsammans med jQuery UI är produktionen strax innan , så här:

... ...  ...

Få dina prioriteringar rakt

Vissa människor kanske föredrar att inte använda de riktiga enqueuing-metoderna eftersom de känner att de har mindre kontroll över den ordning i vilken skript laddas. Till exempel, i ett tema som använder modernizr, kan temaförenaren se till att modernizr laddas tidigt.

Något som jag inte har nämnt tidigare är mer detaljerad om hur add_action funktion fungerar, eftersom det är här vi kan utöva lite inflytande över ordningen av saker. Här är användningen av funktionen enligt WordPress Codex-sidan:

add_action ($ tag, $ function_to_add, $ priority, $ accepted_args);

Observera att ofta, och hittills i den här artikeln, bara $ tag och $ function_to_add parametrar används. De $ prioritet Parametern är standard till 10 och $ accepted_args parametervärden till 1. Om vi vill att våra skript eller stilar ska skrivas tidigare, sänker vi bara värdet för $ prioritet från standardvärdet. Till exempel:

funktion wptuts_scripts_important () // Registrera skriptet så här för ett plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // eller // Registrera skriptet så här för ett tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js'); // För antingen ett plugin eller ett tema kan du skicka skriptet: wp_enqueue_script ('custom script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_important', 5);

Utdata kommer att vara detsamma som vi tidigare sett, men det kommer att hända tidigare i HTML-dokumentet.

Övergripande standardbibliotek och användning av innehållsleveransnät

Det kan finnas tillfällen när du vill använda en annan version av ett bibliotek som ingår i WordPress. Kanske vill du använda en banbrytande version eller du inte vill vänta på nästa utgåva av WordPress innan du använder den senaste stabila versionen av jQuery. En annan anledning kan vara att du vill utnyttja Googles CDN-version av ett bibliotek.

Det är viktigt att notera att detta borde ske endast görs på plugins eller teman som används på webbplatser som du kommer att vara personligen upprätthålla. Alla plugins eller teman som du släpper ut för offentligt bruk bör använda bibliotek som ingår i WordPress.

"Varför?!", Jag hör dig att fråga. Av den enkla anledningen att du inte kontrollerar dessa webbplatser. Du vet inte vilka andra plugins och teman som kan användas där, och du vet inte hur ofta de ska uppdatera ditt plugin eller tema. Att använda bibliotek som är förpackade med WordPress är det säkraste alternativet.

När du har sagt det, om du vill göra det på en webbplats du kontrollerar, så är det hur det görs:

funktion wptuts_scripts_load_cdn () // Avregistrera det medföljande biblioteket wp_deregister_script ('jquery'); // Registrera biblioteket igen från Googles CDN wp_register_script ('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array (), null, false ); // Registrera skriptet så här för ett plugin: wp_register_script ('custom script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery')); // eller // Registrera skriptet så här för ett tema: wp_register_script ('custom script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // För antingen ett plugin eller ett tema kan du skicka skriptet: wp_enqueue_script ('custom script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_load_cdn');

Först och främst avregistrerar jag den medföljande versionen av biblioteket, annars kan konflikter mellan olika versioner introduceras. Registrera sedan den alternativa versionen med samma handtag, och jag har valt att ange null som version (det finns redan i webbadressen!) Och anges inte i sidfoten. Resten av vår kod är densamma, för vi var beroende av vilket script som helst som använde "jquery" -handtaget. Den produktion vi får nu ser ut som:

Notera: En av anledningarna till att det här är en dålig idé att göra i ett plugin eller tema för offentliggörande är att alla andra plugins och teman som används på den här webbplatsen nu måste använda den här versionen av jQuery. Den nyregistrerade versionen av jQuery har inte heller noConflict-inställningen, så om andra plugin- eller temaskript använder Prototype till exempel, Detta kommer att bryta saker.

Var inte girig

Hittills har vi inte nämnt något om hur man gör allt detta i admin, bara på fronten. Den primära skillnaden är vilken åtgärd du ska använda. Istället för add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic'); som vi använder för fronten, är åtgärden för administratören add_action ('admin_enqueue_scripts', 'wptuts_scripts_basic');

Något som är viktigt att göra för både frontend och admin är selektiv om vilka sidor du laddar in dina skript på. Om ditt plugin eller tema har ett skript som bara gör något på en front-end eller administratörssida, till exempel temaets options sida, eller kanske en sida med en viss widget, behöver du bara ladda ditt skript på den sidan. Det går inte att blockera saker och ladda upp skript på sidor där de inte används!

Det finns ett bra exempel i WordPress Codex om hur man bara laddar skript på pluginsidor. Eftersom plugins och teman kan variera mycket i hur de skrivs kommer jag inte att gå in i detaljer här om hur du ska vara kösig om vilka sidor du laddar in skript på, men det var viktigt att nämna så att du är medveten om det när du kodar.

Det är skript, nu stilar

Processen för stilar är nästan exakt samma som processen för skript. Den är klar med en WordPress-funktion som heter wp_register_style, och här är dess användning enligt WordPress Codex:

wp_register_style ($ handtag, $ src, $ deps, $ ver, $ media);

Observera att den enda skillnaden finns mellan wp_register_script och wp_register_style är det istället för en $ in_footer parameter, vi har a $ media parameter. Denna parameter kan ställas in på något av följande: 'Allt', 'skärm', 'Handhållen', och 'skriva ut', eller någon annan W3C-erkänd media typ.

Så ett exempel på hur du kanske skulle göra en stil skulle vara:

funktion wptuts_styles_with_the_lot () // Registrera stilen så här för ett plugin: wp_register_style ('custom-style', plugins_url ('/css/custom-style.css', __FILE__), array (), '20120208', 'alla '); // eller // Registrera stilen så här för ett tema: wp_register_style ('custom-style', get_template_directory_uri (). '/css/custom-style.css', array (), '20120208', 'alla'); // För antingen ett plugin eller ett tema kan du sedan ange stilen: wp_enqueue_style ('custom-style');  add_action ('wp_enqueue_scripts', 'wptuts_styles_with_the_lot');

Detta är ett ganska omfattande exempel, som använder de flesta parametrarna, och den produktion som den producerar ser ut som:

Så, varför gör alla inte redan detta sätt?

Bra fråga, och den andra frågan jag antar att du kanske frågar är "Vad får dig att tro att det här är rätt sätt och inte bara din preferens?". I huvudsak är svaret att detta är den metod som rekommenderas av WordPress. Det säkerställer att alla kombinationer av plugins och teman ska kunna fungera tillsammans lyckligt och utan att fördubblas.

Jag har sett några teman och ramar runt den plats som använder och taggar i deras header.php, och även footer.php, filer för att ladda skript och stilar för själva temat. Det finns verkligen ingen anledning att göra saker på detta sätt. Som jag har visat ovan är det helt möjligt att prioritera skript och stilar och nominera om de laddar i rubriken eller sidfoten från din komfort och säkerhet functions.php. Fördelen är att ditt tema / ramverk kommer att fungera med ett bredare utbud av andra plugins / barnteman.

Ett exempel var att ladda jQuery med hjälp av taggar, som kan tyckas fungera bra, men det kan faktiskt få jQuery att laddas två gånger! Laddar jQuery på det här sättet kommer inte att stoppa WordPress från att ladda sin version av jQuery för andra plugins, eftersom WordPress versionen är i noConflict-läge som standard och ett plugin kan ange det som en dependancy. Så nu har du jQuery som arbetar för både noConflict-läge och $, och bryter också förmodligen alla plugin som använder prototypbiblioteket.

Slutsats

WordPress är ett fantastiskt system, och det har utvecklats med mycket tanke. Om det finns en mekanism som görs tillgänglig för att göra något, är det ofta en bra idé att använda den. När du utvecklar dina plugins och teman, försök att komma ihåg att koda eftertänksamt och för att leka bra med andra.

Vad tycker du om användningen av wp_enqueue_script och dess tillhörande funktioner och åtgärder? Känner du till några exempel där det görs felaktigt? Vet du av någon anledning att inte följa ovanstående råd?

Om du behöver en färdig lösning kan du bläddra genom våra Wordpress-teman och Wordpress-plugins på Envato Market.

Koda