Im WordPress Theme Directory immer seltener anzutreffen, in freier Wildbahn sieht man sie aber noch häufig: hardkodierte Referenzen zu CSS- oder JavaScript-Dateien im Header bzw. Footer des Themes. Es muss wohl daran liegen, dass sich einige Webdesigner nicht so richtig mit PHP anfreunden wollen und/oder aber Angst haben, da etwas falsch zu machen. Anders kann ich mir das nicht erklären.
Die Nachteile dieser Vorgehensweise überwiegen aber ganz deutlich.
Auch wenn ihr euch darum kümmert, dass erst die Stylesheets und danach die JavaScripten geladen werden, so werdet ihr in den meisten Fällen trotzdem die Funktion wp_head in der Datei header.php und die Funktion wp_footer in der Datei footer.php stehen lassen, um den zum Einsatz kommenden Plugins die Möglichkeit zu lassen, eigene Styles oder Scripten nachladen zu können.
An dieser Stelle wird bereits klar, dass man nicht mehr viel optimieren kann, wenn man an der Vorgehensweise festhält, CSS und JavaScript auf die „klassische Weise“ einzubinden, aber auf Plugins nicht verzichten will. Ein bunter Mix im HTML-Header wird fast unvermeidlich sein. Aber hier ist meist noch lange nicht Schluss mit den Problemen, die man sich so eingehandelt hat.
Wer sich jedoch mit wp_enqueue_script und wp_enqueue_style anfreunden kann, wird – zusätzlich zum sauberen und performanten HTML-Code – noch weiter belohnt. Hier deshalb noch einmal alle Vorteile im Überblick:
-
Saubere Auflösung von Abhängigkeiten in den Skripten
In vielen Projekten wird beispielsweise auf jQuery gesetzt, wenn es darum geht, Interaktionen im Browser gescheit umzusetzen. Oft kommen noch weitere Bibliotheken wie zum Beispiel jQuery UI Einsatz. Wenn man die Art und Weise beibehält und externe Bibliotheken auch statisch einbindet, läuft man Gefahr einige der Scripten und/oder Stylesheets mehrfach zu laden. Geht man den empfohlenen Weg, werden die Referenzen nur einmal (und in der richtigen Reihenfolge) aufgebaut und die definierten Abhängigkeiten werden sauber aufgelöst.
-
Keine Probleme mehr bei der Aktualisierung von Plugins
Wie anfangs bereits beschrieben, laden heutzutage so einige Plugins JavaScript dazu. Es gibt natürlich auch unter den Entwicklern einige, die sich wenige Gedanken darüber machen, was passiert, wenn man eine eigene Erweiterung lädt, die eigentlich schon Teil der WordPress-Installation ist. Aber das ist nicht die Regel. Viel eher ist es so, dass sich der Autor eines Plugins auf die vordefinierten Bibliotheken stützen möchte und deshalb nur das Handle angibt, unter welchem ein benötigtes Script bereits registriert wurde. Dopplungen werden vermieden und nach den Updates funktionieren diese Plugins auch (fast) immer reibungslos.
-
Weitere Steigerung der Geschwindigkeit beim Seitenaufbau möglich
Für einige Leser ist das vielleicht nicht sofort ersichtlich, aber nur wenn die CSS-Dateien und JavaScripts in die Warteschlange geschoben wurden, können Cache- bzw. Plugins für die Optimierung überhaupt erst wirksam werden. Wer also darüber nachdenkt, solche Hilfsmittel zu installieren, die dann die referenzierten Dateien automatisch zusammenzufassen, minimieren oder zwischenzuspeichern, muss hier bereits an der Basis wirksam werden und sich mit der angesprochenen Thematik beschäftigen. Zudem kann man auch – beispielsweise mittels Conditional Tags – steuern, wann eine bestimmte Datei eingebunden werden soll, was die Ausgabe in einigen Fällen zusätzlich stark reduzieren kann.
-
Lokalisierung der JavaScript-Dateien ermöglichen
Das ist vermutlich Neuland für einige, aber mehrsprachige Websites mit WordPress sind auch nicht unbedingt eine Seltenheit heutzutage. Möglicherweise habt ihr euch aber schon öfter mal gefragt, wie ihr die Lokalisierung der JavaScript-Dateien am geschicktesten lösen könnt. Die Antwort darauf ist wp_localize_script. Nachdem man ein Script in die Warteschlange geschoben hat, kann man ein Array an wp_localize_script übergeben, dass dann als JavaScript-Objekt zur Verfügung steht. Das wirkt auf den ersten Blick vielleicht etwas umständlich, ist aber eine klasse Sache, mit der man sich einen großen Teil der üblichen Probleme beim Umgang mit Zeichenketten im JavaScript-Code ersparen kann.
Nach dieser etwas länger geratenen Einführung gibt es nun etwas Code, um die Geschichte noch etwas zu vertiefen:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<?php | |
function my_enqueue_scripts() { | |
wp_enqueue_style( 'my-style', get_stylesheet_uri() ); | |
wp_enqueue_script( | |
'my-script', | |
get_template_directory_uri() . '/js/script.js', | |
array( 'jquery' ), | |
false, | |
true | |
); | |
wp_localize_script( | |
'my-script', | |
'objectL10n', | |
array( | |
'str_hello_world' => __( 'Hello world!', 'my-textdomain' ), | |
) | |
); | |
if ( is_front_page() ) { | |
wp_enqueue_style( | |
'front-style', | |
get_template_directory_uri() . '/css/front.css' | |
); | |
wp_enqueue_script( | |
'front-script', | |
get_template_directory_uri() . '/js/front.js', | |
array(), | |
false, | |
true | |
); | |
} | |
} | |
add_action( 'wp_enqueue_scripts', 'my_enqueue_scripts' ); |
Die gesamte Funktion (auch der Aufruf von add_action) gehört in die functions.php des Themes. Mein Beispiel enthält so ziemlich alle Dinge, die bisher angesprochen wurden:
Der Aufruf von wp_enqueue_style schiebt eine CSS-Datei in die Warteschlange. In dem Fall die style.css eures Themes. Den URL zu dieser Datei kann WordPress mit der Funktion get_stylesheet_uri selbst auflösen. Bei allen anderen Dateien benutzt man eine Verkettung von get_template_directory_uri (bzw. get_stylesheet_directory_uri, wenn es sich um ein Child-Theme handelt) und einer Pfadangabe relativ zum Theme, wie bei den folgenden Codeabschnitten.
wp_enque_script kümmert sich entsprechend um die JavaScripten. Mit dem ersten Argument bestimmt man ein Handle, das man sich am besten wie eine ID bei CSS vorstellt. Darauf folgt dann die Pfadangabe, wie bereits in Punkt 1 angesprochen. Der dritte Parameter ist ein Array, das die Handles der Scripten enthält, von denen unseres abhängig ist, hier als Beispiel jQuery. Mit dem vorletzten Parameter kann man dann eine Version festlegen und schlussendlich sogt das true im Beispielcode dafür, das der Verweis auf das Script im Footer platziert wird.
wp_localize_script ermöglicht die Internationalisierung/Lokalisierung von JavaScript. Der erste Parameter ist das Handle eines Scriptes, dass bereits registriert bzw. in die Warteschlange geschoben wurde. Beispielsweise ist das hier genau mit dem Befehl davor passiert. Der nächste Parameter gibt an, wie der Name der Objektinstanz lautet, die wir für die JavaScript-Strings verwenden. Man muss sich das wie einen einfachen Container vorstellen, der den 3. Parameter der Funktion – hier direkt als assoziatives Array übergeben – aufnimmt:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jQuery(document).ready(function($) { | |
$('#message-box').html( | |
objectL10n.str_hello_world | |
); | |
}); |
Am Ende der Funktion gibt es noch ein Beispiel, wie sich über ein Conditional Tag weitere Dateien dazu laden lassen. In diesem Fall wird geprüft, ob es sich um die Startseite handelt und im Fall des Falles noch ein entsprechendes Stylesheet und ein JavaScript mit aufgenommen. So kann man bereits viele Fälle ziemlich gut abdecken.
Jetzt seid ihr dran. Hab ich etwas vergessen? Oder gibt es vielleicht noch Unklarheiten?
Danke für die Tipps!
Ich nutze das WordPress Plugin „CSS & Javascript Toolbox“ und komme damit sehr gut klar.
Danke für die Tipps!
Ich nutze das WordPress Plugin „CSS & Javascript Toolbox“ und komme damit sehr gut klar.
Hi Dennis,
besten Dank für die vielen interessanten posts.
Ich habe ein Problem, das mich sehr fuchst. Nachdem ich meine wordpress 3.9.1 Installation Multisite-fähig gemacht habe, werden bei der neuen site (Unterverzeichnis für andere Sprache) die CSS-Änderungen, die ich bei der primary site (Pinzolo theme) vorgenommen habe, nicht übernommen. Es wird das theme im Originallayout gezeigt. Vom super-admin dashboard habe ich das theme „network enabled“…Was könnte ich hier nicht beachtet haben? Ich möchte für beide Seiten ein identisches layout haben, nämlich das layout der primary site.
Besten Dank und viele Grüße
Mario
Sorry für die späte Antwort. Ich habe die Nachricht, dass ein Kommentar wartet, wohl übersehen. Zu Deiner Frage: Ich kann da nur schätzen, was das Problem sein kann. Eventuell benutzt Du ein Childtheme, das im Primary aber nicht in dem anderen Blog aktiviert ist.
Hi Dennis,
besten Dank für die vielen interessanten posts.
Ich habe ein Problem, das mich sehr fuchst. Nachdem ich meine wordpress 3.9.1 Installation Multisite-fähig gemacht habe, werden bei der neuen site (Unterverzeichnis für andere Sprache) die CSS-Änderungen, die ich bei der primary site (Pinzolo theme) vorgenommen habe, nicht übernommen. Es wird das theme im Originallayout gezeigt. Vom super-admin dashboard habe ich das theme „network enabled“…Was könnte ich hier nicht beachtet haben? Ich möchte für beide Seiten ein identisches layout haben, nämlich das layout der primary site.
Besten Dank und viele Grüße
Mario
Sorry für die späte Antwort. Ich habe die Nachricht, dass ein Kommentar wartet, wohl übersehen. Zu Deiner Frage: Ich kann da nur schätzen, was das Problem sein kann. Eventuell benutzt Du ein Childtheme, das im Primary aber nicht in dem anderen Blog aktiviert ist.