Share
De juiste manier kennen om JavaScript- en CSS-bestanden op te nemen in uw WordPress-thema's en plug-ins is erg belangrijk voor ontwerpers en ontwikkelaars. Als u zich niet houdt aan de aanbevolen procedures, loopt u het risico tegenstrijdigheden aan te gaan met andere thema's en plug-ins en mogelijk problemen te creëren die u gemakkelijk had kunnen voorkomen. Dit artikel is bedoeld als naslagwerk om mooi met anderen te spelen.
Voordat we aan de slag gaan, kunt u bladeren door onze WordPress-thema's en WordPress-plug-ins, als u uw volgende project professioneel wilt kickstarten.
En als je na het lezen van deze tutorial nog steeds niet zeker weet hoe je je JavaScript- en CSS-bestanden op de juiste manier moet opnemen, is het misschien de moeite waard om een aantal van de WordPress-services te bestellen die beschikbaar zijn op Envato Studio.
Van installatie tot aanpassing, of zelfs SEO en snelheidsoptimalisatie, u kunt een professionele WordPress-expert krijgen om alles vanaf het begin goed in te stellen.
Als je ooit een thema of plug-in hebt ontwikkeld voor WordPress of hebt gewerkt met een thema dat door iemand anders is gemaakt, ben je waarschijnlijk verschillende methoden tegengekomen voor het opnemen van JavaScript en CSS. Hoewel er verschillende methoden zijn die in een specifieke reeks omstandigheden kunnen werken, is er één primaire methode aanbevolen in de WordPress Codex. Deze voorkeursmanier zorgt ervoor dat uw thema of plug-in in alle gevallen werkt, ervan uitgaande dat anderen ook de juiste manier coderen.
Er is ook een misverstand over wat de Codex precies hierover zegt, wat ik zal helpen verduidelijken.
Wanneer u WordPress downloadt, is er al een selectie van algemene JavaScript-bibliotheken beschikbaar die u kunt gebruiken voor uw JavaScript-ontwikkeling. Een lijst met opgenomen bibliotheken is te vinden in de WordPress Codex wp_enqueue_script artikel.
Al die bibliotheken zijn inbegrepen, maar standaard laadt WordPress alleen degene die het nodig heeft, en alleen wanneer het ze nodig heeft in de admin. Als u JavaScript schrijft dat een van deze bibliotheken gebruikt, moet u WordPress vertellen dat voor uw script de bibliotheek eerst moet worden geladen.
Enkele dingen om over na te denken wanneer je JavaScript codeert voor WordPress zijn:
Als u deze vragen beantwoordt, weet u wat u moet doen om uw script te registreren en te laden. Dit wordt gedaan met behulp van een WordPress-functie genaamd wp_register_script, en hier is het gebruik volgens de WordPress Codex:
wp_register_script ($ handle, $ src, $ deps, $ ver, $ in_footer);
Dus wat zijn deze variabelen en hebben we ze elke keer nodig? (Dit staat op de Codex-pagina, dus ik zal het kort houden en gewoon Engels gebruiken)
Accentsconagua
$ handle - wat je zult gebruiken om naar dit specifieke script te verwijzen, waar je het ook nodig zou kunnen hebben, en je moet deze variabele op zijn minst opnemen$ src - het pad naar het bronbestand in uw plug-in of thema$ deps - een array met de $ handle voor andere scripts moet uw script worden uitgevoerd (dus een afhankelijkheid)$ ver - het versienummer voor uw script, dat kan worden gebruikt voor cachebusting. WordPress gebruikt standaard zijn eigen versienummer als versienummer voor uw script$ in_footer - wil je dat je script in de voettekst wordt geladen? Zet dit op waar of vals. Het is vals standaard, zodat het in de kop waar laadt wp_head () is, en als u opgeeft waar het zal waar laden wp_footer () verschijnt in het themaBrowsers onthouden welke scripts en stylesheets ze hebben gedownload voor een bepaalde site op basis van de URL van het script en de stylesheet. Als u de URL wijzigt, zelfs alleen door een querystring toe te voegen, gaat de browser ervan uit dat het een nieuw bestand is en downloadt het.
Hier is het eenvoudigste voorbeeld voor het laden van een aangepast script:
function wptuts_scripts_basic () // Registreer het script als volgt voor een plug-in: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // or // Registreer het script als volgt voor een thema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js'); // Voor zowel een plug-in als een thema kunt u het script vervolgens in wachtrij plaatsen: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic'); Eerst registreren we het script, zodat WordPress weet waar we het over hebben. De manier om het pad naar ons JavaScript-bestand te vinden, is anders, of we nu een plug-in of een thema coderen, dus ik heb voorbeelden van beide hierboven opgenomen. Vervolgens worden we in de wachtrij geplaatst om te worden toegevoegd aan de HTML voor de pagina wanneer deze wordt gegenereerd, standaard in de waar de wp_head () zit in het thema.
De output die we krijgen van dat basisvoorbeeld is:
Als uw script nu vertrouwt op een van de bibliotheken die bij WordPress zijn geleverd, zoals jQuery, kunt u de code heel eenvoudig wijzigen:
function wptuts_scripts_with_jquery () // Registreer het script als volgt voor een plug-in: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jQuery')); // or // Registreer het script als volgt voor een thema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // Voor zowel een plug-in als een thema kunt u het script vervolgens in wachtrij plaatsen: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_jquery'); Notitie: Standaard is jQuery geladen met noConflict om botsingen met andere bibliotheken (zoals Prototype) te voorkomen. Zie het gedeelte noConflict van de Codex als u niet weet hoe u daarmee moet omgaan.
Zie wat ik daar heb gedaan? U voegt gewoon een array met de 'jQuery'-handle toe als afhankelijkheid. Het maakt hier gebruik van een array, omdat uw script meerdere afhankelijkheden kan hebben. Als uw script de jQuery- en jQuery-gebruikersinterface gebruikt, voegt u de jQuery-gebruikersinterface toe aan uw afhankelijkheidsarray, zoals array ('jQuery', 'jquery-ui-core')
Dus nu is de uitvoer veranderd en we kunnen zien dat jQuery ook is toegevoegd aan de van de pagina:
Laten we een voorbeeld proberen met alle toeters en bellen:
function wptuts_scripts_with_the_lot () // Registreer het script als volgt voor een plug-in: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery', 'jquery-ui -core '),' 20120208 ', waar); // or // Registreer het script als volgt voor een thema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery', 'jquery-ui-core' ), '20120208', waar); // Voor zowel een plug-in als een thema kunt u het script vervolgens in wachtrij plaatsen: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_the_lot'); Ok, dus ik heb nu een versie toegevoegd en aangegeven dat dit script in het voettekst moet worden geladen. Voor het versienummer heb ik ervoor gekozen om de datum van vandaag te gebruiken, omdat deze eenvoudig kan worden bijgehouden, maar u kunt elke versienummering gebruiken die u wilt. De uitvoer voor deze is ook iets anders, jQuery wordt uitgevoerd in de en ons script samen met de gebruikersinterface van jQuery wordt net eerder weergegeven , zoals dit:
... ... ...
Sommige mensen gebruiken misschien liever niet de juiste methoden om in te zoomen, omdat ze vinden dat ze minder controle hebben over de volgorde waarin scripts worden geladen. In een thema dat bijvoorbeeld modernizr gebruikt, wil de thema-auteur wellicht ervoor zorgen dat modernizr al vroeg wordt geladen.
Iets wat ik niet eerder heb genoemd, is meer informatie over hoe het add_action functie werkt, omdat we hier een beetje invloed op de volgorde van dingen kunnen uitoefenen. Dit is het gebruik van de functie volgens de WordPress Codex-pagina:
add_action ($ tag, $ function_to_add, $ priority, $ accepted_args);
Merk op dat vaak, en tot nu toe in dit artikel, alleen de $ tag en $ function_to_add parameters worden gebruikt. De $ prioriteit parameter standaard ingesteld op 10 en de $ accepted_args parameter standaard ingesteld op 1. Als we willen dat onze scripts of stijlen eerder in de wachtrij worden geplaatst, verlagen we gewoon de waarde voor $ prioriteit van de standaard. Bijvoorbeeld:
function wptuts_scripts_important () // Registreer het script als volgt voor een plug-in: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // or // Registreer het script als volgt voor een thema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js'); // Voor zowel een plug-in als een thema kunt u het script vervolgens in wachtrij plaatsen: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_important', 5); De uitvoer zal hetzelfde zijn als we eerder hebben gezien, maar het zal eerder in het HTML-document voorkomen.
Er kunnen momenten zijn dat u een andere versie van een bibliotheek wilt gebruiken die is opgenomen in WordPress. Misschien wilt u een geavanceerde versie gebruiken of wilt u niet wachten op de volgende versie van WordPress voordat u de nieuwste stabiele versie van jQuery gebruikt. Een andere reden zou kunnen zijn dat u wilt profiteren van de CDN-versie van Google van een bibliotheek.
Het is belangrijk op te merken dat dit zou moeten enkel en alleen worden gedaan op plug-ins of thema's die worden gebruikt op sites die u gaat worden persoonlijk onderhouden. Alle plug-ins of thema's die u vrijgeeft voor openbaar gebruik, moeten de bibliotheken gebruiken die bij WordPress zijn geleverd.
"Waarom?!", Ik hoor je vragen. Om de eenvoudige reden dat u die sites niet beheert. U weet niet wat andere plug-ins en thema's daar kunnen gebruiken en u weet niet hoe vaak zij uw plug-in of thema zullen bijwerken. Het gebruik van de bibliotheken met WordPress is de veiligste optie.
Dit gezegd hebbende, als u dit wilt doen op een site die u beheert, dan is hier de manier waarop het gedaan is:
function wptuts_scripts_load_cdn () // Deregister de included library wp_deregister_script ('jQuery'); // Registreer de bibliotheek opnieuw vanuit het CDN van Google wp_register_script ('jQuery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array (), null, false ); // Registreer het script als volgt voor een plug-in: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jQuery')); // or // Registreer het script als volgt voor een thema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // Voor zowel een plug-in als een thema kunt u het script vervolgens in wachtrij plaatsen: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_load_cdn'); Dus eerst en vooral, ik deregistreren de bijgevoegde versie van de bibliotheek, anders kunnen conflicten tussen verschillende versies worden geïntroduceerd. Registreer vervolgens de alternatieve versie met dezelfde handle en ik heb ervoor gekozen om null als de versie op te geven (deze staat al in de URL!) En is niet opgegeven in de voettekst. De rest van onze code is hetzelfde, omdat we afhankelijk waren van het script dat de 'jQuery'-handle gebruikte. De uitvoer die we nu krijgen ziet er als volgt uit:
Notitie: Een van de redenen waarom dit een slecht idee is om te doen in een plug-in of een thema voor openbare publicatie, is dat alle andere plug-ins en thema's die op deze site worden gebruikt nu deze versie van jQuery moeten gebruiken. Ook heeft de nieuw geregistreerde versie van jQuery geen noConflict-set, dus als andere plug-ins of themascripts Prototype gebruiken, bijvoorbeeld, dit zal dingen breken.
Tot nu toe hebben we niets gezegd over hoe dit allemaal te doen in de admin, alleen aan de voorkant. Het belangrijkste verschil is welke actie moet worden gebruikt. In plaats van add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic'); die we gebruiken voor de front-end, de actie voor de beheerder is add_action ('admin_enqueue_scripts', 'wptuts_scripts_basic');
Iets dat belangrijk is om te doen voor zowel de front-end als de beheerder, is selectief te zijn over de pagina's waarop u uw scripts laadt. Als uw plug-in of thema een script heeft dat alleen iets doet op een front-end of beheerderspagina, zoals de pagina met opties voor het thema, of misschien een pagina met een specifieke widget, hoeft u alleen uw script op die pagina te laden. Geen enkel punt dat dingen verstopt en scripts laadt op pagina's waar ze niet worden gebruikt!
Er is een geweldig voorbeeld in de WordPress Codex over het laden van scripts alleen op plugin-pagina's. Omdat plug-ins en thema's sterk kunnen verschillen in de manier waarop ze zijn geschreven, zal ik hier niet ingaan op de vraag op welke pagina's u scripts laadt, maar het was belangrijk om te vermelden, zodat u er van op de hoogte bent wanneer je codeert.
Het proces voor stijlen is bijna precies hetzelfde als het proces voor scripts. Het wordt gedaan met behulp van een WordPress-functie genaamd wp_register_style, en hier is het gebruik volgens de WordPress Codex:
wp_register_style ($ handle, $ src, $ deps, $ ver, $ media);
Merk op dat het enige verschil daar tussen is wp_register_script en wp_register_style is dat in plaats van een $ in_footer parameter, we hebben een $ media parameter. Deze parameter kan op een van de volgende worden ingesteld: 'allemaal', 'scherm', 'Handheld', en 'afdrukken', of elk ander door W3C herkend mediatype.
Dus een voorbeeld van hoe je een stijl kunt inruilen, zou zijn:
function wptuts_styles_with_the_lot () // Registreer de stijl als volgt voor een plug-in: wp_register_style ('custom-style', plugins_url ('/css/custom-style.css', __FILE__), array (), '20120208', 'all '); // or // Registreer de stijl als volgt voor een thema: wp_register_style ('custom-style', get_template_directory_uri (). '/css/custom-style.css', array (), '20120208', 'all'); // Voor een plug-in of een thema kunt u vervolgens de stijl in wachtrij plaatsen: wp_enqueue_style ('custom-style'); add_action ('wp_enqueue_scripts', 'wptuts_styles_with_the_lot'); Dit is een tamelijk uitgebreid voorbeeld, waarbij de meeste parameters worden gebruikt, en de uitvoer die het produceert, ziet er als volgt uit:
Goede vraag, en de andere vraag die je misschien zou kunnen stellen, is: "Waarom denk je dat dit de" juiste "manier is en niet alleen maar je voorkeur?". In wezen is het antwoord dat dit de aanpak is die wordt aanbevolen door WordPress. Het zorgt ervoor dat elke combinatie van plug-ins en thema's in staat moet zijn om gelukkig en zonder verdubbeling samen te werken.
Ik heb een paar thema's en kaders gezien rond de plek die gebruikt en tags in hun header.php, en zelfs footer.php, bestanden om de scripts en stijlen voor het thema zelf te laden. Er is echt geen reden om dingen op deze manier te doen. Zoals ik hierboven heb aangetoond, is het perfect mogelijk om scripts en stijlen voorrang te geven en te bepalen of ze in de kop- of voettekst laden vanuit het comfort en de veiligheid van uw functions.php. Het voordeel is dat uw thema / framework zal werken met een breder scala aan andere plug-ins / kindthema's.
Een voorbeeld was het laden van jQuery met behulp van de tags, die misschien mooi lijken te werken, maar dit kan ertoe leiden dat jQuery twee keer wordt geladen! Het op deze manier laden van jQuery zal niet voorkomen dat WordPress zijn versie van jQuery laadt voor andere plug-ins, aangezien de versie van WordPress standaard in de noConflict-modus staat en een plug-in dit als afhankelijkheid kan specificeren. Dus nu zul je jQuery werken voor zowel NoConflict-modus als $, en waarschijnlijk ook elke plug-in die de Prototype-bibliotheek gebruikt verbreekt.
WordPress is een fantastisch systeem en het is met veel nadenken ontwikkeld. Als er een mechanisme beschikbaar is om iets te doen, is het vaak een goed idee om het te gebruiken. Denk er bij het ontwikkelen van uw plug-ins en thema's aan om zorgvuldig te coderen en goed met anderen te spelen.
Wat vindt u van het gebruik van wp_enqueue_script en de bijbehorende functies en acties? Kent u voorbeelden waarbij het verkeerd wordt gedaan? Kent u een reden om het bovenstaande advies niet te volgen??
Als u een kant-en-klare oplossing nodig heeft, kunt u bladeren door onze WordPress-thema's en WordPress-plug-ins op Envato Market.
