WordPress wordt geleverd met een aantal standaardscripts die u kunt gebruiken om uw thema's en plug-ins van stroom te voorzien. jQuery is het veelgebruikte script, net als TinyMCE. Maar wat als u uw eigen jQuery-script wilt integreren?

We hebben onlangs laten zien hoe u jQuery-scripts correct aan uw installatie kunt toevoegen. WordPress gebruikt hetzelfde interne mechanisme, wat betekent dat we scripts in de wachtrij kunnen verwijderen of zelfs vervangen door onze eigen scripts.

In deze tutorial zal ik je laten zien hoe uitschrijven Bestaande scripts zodat u uw eigen scripts kunt toevoegen. We zullen u ook laten kennismaken met de verschillende omstandigheden waarin u het kunt doen en u vertellen waarom sommige mensen denken dat het verwijderen van een intern script onverantwoord is.

Waarom de interne scripts aanpassen: Case of jQuery?

Er is een reeks scenario's waarin u mogelijk de geladen interne scripts wilt wijzigen. WordPress gebruikt momenteel bijvoorbeeld standaard jQuery 1.11.3, maar de nieuwste versie is eigenlijk 1.12.3 of 2.2.3. Als u een toepassing schrijft die afhankelijk is van geavanceerde jQuery-functionaliteit, moet u mogelijk een nieuwere versie van het script gebruiken.

Ik kreeg ook te maken met een situatie waarin een oude plug-in de problemen met de verouderde scripts veroorzaakte. In dit geval vertrouwde een klant op een plug-in, maar werd het geladen script niet daadwerkelijk gebruikt. We dachten dat het verwijderen de beste optie was, maar in plaats van de plug-in-code rechtstreeks aan te passen, wat toekomstige updates zou hebben voorkomen, hebben we besloten om een ​​nieuwe plug-in te gebruiken om de geladen scripts aan te passen.

Het is belangrijk op te merken dat hoewel er legitieme gevallen zijn waarin u de scripts die door de kern van WordPress en andere plug-ins of thema's zijn geladen, kunt verwijderen en wijzigen, u altijd twee keer moet nadenken en voorzichtig moet zijn.

Als u een nieuwe versie van jQuery forceert op uw Site webhet kan bijvoorbeeld onvoorziene compatibiliteitsproblemen veroorzaken. Test WordPress indien mogelijk altijd lokaal en vermijd het wijzigen/verwijderen van scripts tenzij dit absoluut noodzakelijk is.

Moeten we interne codes verwijderen uit WordPress

Hoe scripts te bewerken

Dankzij de magie van WordPress kun je elk in je thema ingebouwd script wijzigen of zelfs een plug-in maken om het voor je te doen. Dit betekent dat u de originele code die het aanstootgevende script laadt niet hoeft (en dat ook niet!) Ik zal u enkele voorbeelden geven.

Stel dat uw thema een script gebruikt dat u wilt verwijderen of vervangen. In dit geval kunt u een onderliggend thema maken en de vereiste code laden.

Als u de scripts in de plug-ins wilt wijzigen, kunt u de nodige wijzigingen aanbrengen in uw child-thema of in een nieuwe plug-in. Afhankelijk van de omvang van het project, raad ik aan om een ​​plug-in te maken die specifiek is om de scripts van andere plug-ins te wijzigen.

Als u een eenvoudig WordPress-script wilt bewerken, kunt u dit het beste doen in het product dat u schrijft. Als u met een plug-in werkt, moet u het erop doen, als het een thema is, moet u het in het bestand function.php doen.

Het "uitschrijven" van scripts

Als je de vorige tutorial nog niet hebt bekeken over het correct toevoegen van een script in WordPress, kun je dat nu doen en terugkomen. We hebben gezien dat de methode om scripts toe te voegen aan WordPress is door ze te registreren. De verwijdering ervan is natuurlijk het omgekeerde proces, wat betekent "uitschrijving" of liever uitschrijving. Het is gedaan met behulp van de wp_deregister_script () functie als volgt:

wp_deregister_script ('jquery');

De enige parameter die u hier nodig heeft, is de naamruimte van het script. De naamruimte wordt gegeven toen het script werd opgeslagen en je kunt in mijn bericht lezen over het toevoegen van jQuery aan WordPress voor meer gedetailleerde informatie.

Als u de bovenstaande code gebruikt, wordt het jQuery-script volledig verwijderd.

Scripts vervangen

Als u een script wilt vervangen, is het niet voldoende om het eenvoudig met nieuwe parameters op te slaan (deze worden genegeerd). U moet het register afmelden en vervolgens opnieuw registreren. Hier is een snel voorbeeld:

functie my_enqueued_assets () {wp_deregister_script ('jquery'); wp_enqueue_script ('scriptnaam', '//code.jquery.com/jquery-2.2.3.min.js', array (), '2.2.3'); } add_action ('wp_enqueue_scripts', 'my_enqueued_assets');

Zoek opgeslagen scripts

Als je op zoek bent naar alle scripts die WordPress opslaat, heb je geluk. Neem een ​​kijkje in de documentatie van wp_enqueue_scripts en u vindt een tabel binnen handbereik.

Het vinden van scripts die door plug-ins zijn opgeslagen, is echter iets moeilijker. U kunt alle scripts in de wachtrij weergeven door het bestand inhoud van de variabele $wp_scripts.

globale $ wp_scripts; echo ' ';
var_dump ($ wp_scripts);
echo ' ';

Een andere methode die ik gebruik, is zoeken naar wp_enqueue_scripts in mijn plug-ins-directory. Hierdoor kan ik zien welke plug-in verantwoordelijk is voor welk script op mijn site.

Waarom vervangende scripts niet altijd een goed idee zijn

Hoewel sommige thema- en plug-in-ontwikkelaars het absoluut noodzakelijk vinden om hun eigen scripts te laden, en in het bijzonder een andere versie van jQuery, is er enige controverse in de WordPress-gemeenschap over de vraag of het echt gepast is om het te laden. doen.

Met het feit dat WordPress jQuery laadt in de noConflict-modus, is de kans erg klein dat er een conflict zal zijn, en daarom mogen de thema's het gedrag van WordPress niet veranderen, en met name WordPress werkt de embedded versie van jQuery regelmatig.

Samenvatten

Bij het verwijderen of vervangen van scripts, iets wat u niet elke dag moet doen, is het belangrijk om te weten hoe u dit op de juiste manier moet doen, zodat u, wanneer u met een situatie wordt geconfronteerd waarin het nodig is, dit zonder zorgen en zonder “breken” kunt doen. jouw blog.

Door je af te melden voor scripts via een aangepaste plug-in, zorg je ervoor dat je de broncode van WordPress of een thema waarvan je niet de auteur bent niet wijzigt, waardoor je je code veilig kunt houden tijdens updates.