Fabian Letscher – Blog + Portfolio

WordPress: wp_enqueue_style

Mit wp_enqueue_style lässt sich relativ einfach ein Stylesheet einbinden. Das besondere hierbei ist, dass ein Stylesheet genau einmal eingefügt wird. Dies beugt vor, dass dasselbe Stylesheet mehrere Male geladen wird.

Aufbau:

[siehe auch: WP Codex (engl.)]

<code><?php wp_enqueue_style( $handle, $src, $deps, $ver, $media ) ?></code>

• $handle ist ein String und gibt den Namen des Stylesheets wieder. Beispiel:
  ‘print’

  Ein Name muss angegeben werden.

• $src ist die URL vom Hauptverzeichnis ausgehend. Beispiel:
  ‘/wp-content/themes/my_theme/print.css’

  Keine Angabe notwenig. Default-Wert: false

• $deps ist ein array() was Abhängigkeiten mit anderen Stylesheets betont. Beispiel:
  array(‘print’, ‘style’)

  Es ist keine Angabe notwendig. Falls man jedoch eine macht, sollte klar sein, dass das Stylesheet vorher auch mithilfe von wp_enqueue_style geladen wird. Im Beispiel würde das bedeuten: Wenn print.css und style.css geladen sind, wird dieses Stylesheet auch geladen

• $ver ist die String-Angabe einer Version. Beispiel:
  ’1.0′

  Keine Angabe notwendig, Default-Wert: false.

• $mediaString für das Ausgabemedium. Beispiel:
  ‘print’

  Keine Angabe notwendig, Default-Wert: false

Anwendung

Manchmal ist es sinnvoll, ein Stylesheet nur für bestimmte Seiten zu laden. Will man beispielsweise auf allen Seiten und immer dann wenn Kommentare erlaubt sind, dass ein Stylesheet namens “forms.css”eingebunden wird, so könnte man folgendes tun:

<code>
if (comments_open() ) {
        wp_enqueue_style('forms', '/wp-content/themes/wp_theme/forms.css', array() , false , 'screen' );
}
if (is_page() ) {
        wp_enqueue_style('forms', '/wp-content/themes/wp_theme/forms.css', array() , false , 'screen' );
}
</code>

Nun könnte ja auf einer Seite (is_page) auch die Kommentarfunktion erlaubt sein (comments_open), dann wird die forms.css allerdings nicht zweimal geladen – was ja unnötig wäre – sondern genau einmal.

Probleme mit wp_enqueue_script() und jQuery

Mit wp_enqueue_script() kann man ja prinzipiell ganz einfach eine beliebige Javascript-Bibliothek einbinden, die sowieso in WordPress enthalten ist. Was dabei alles möglich ist kann man im WordPress Codex nachlesen. Mein angestrebtes Ziel war die Einbindung von jQuery mittels:

wp_enqueue_script(jquery);

Dies funktioniert auch einwandfrei.
Als ich meine entsprechende Javascript-Datei mit den Funktionen eingebunden hatte, war mir noch nicht bewusst, dass WordPress dann keine “$” mehr akzeptiert um Konflikte mit anderen Bibliotheken wie Prototype aus dem Weg zu gehen. Demnach werden bei einer Funktion alle $ gegen jQuery ausgetauscht:
Nochmal ein Beispiel, aus:

$(document).ready(function() {
	$("div#images, div#download").addClass('hide');

wird dann:

jQuery(document).ready(function() {
	jQuery("div#images, div#download").addClass('hide');

Weiterführende Links

• Frank Bülgte: JavaScript-Bibliotheken in und aus WordPress nutzen
• aus dem WordPress-Forum Deutschland

Piwik vs. Google Analytics

Vor einiger Zeit habe ich berichtet, dass ich neben Google Analytics nun auch Piwik nutze um die Webseiten-Statistiken zu erfassen. Hier folgt nun ein Résumé des ganzen Vergleichs. Ich habe jetzt letztlich den Beobachtungszeitraum auf eine Woche begrenzt. Die tabellarischen Auswertungen beziehen sich daher auf Daten vom 11. Juni 2009 bis zum 18. Juni 2009. Bei der Auswertung habe ich mich nur auf ein paar technische Kriterien festgelegt, da diese besser zu vergleichen sind:

Betrachtet man diese Ergebnisse, stellt man schon einige gravierende Unterschiede fest. Bei den Zugriffen beträgt die Differenz von den Piwik und Google Analytics-Werten immerhin 8 Zugriffe. Das ist doch relativ schwer erklärlich. Wohingegen die Suchwörter auch wirklich identisch sind. Bei den technischen Gegebenheiten lassen sich ein paar kleine Unterschiede schon aufweisen.

Bei Piwik fällt einem zusätzlich auf, dass die Anzahl der Browser, Betriebssysteme und Bildschirmauflösungen im Grunde zusammengezählt die Zugriffszahl ergeben müssten (unbekannte Zugriffe wurden immerhin auch verzeichnet) – dies ist allerdings nicht der Fall. Google Analytics zeigt dabei bessere Werte und lässt es bei den Bildschirmauflösungen dann offen, da die Unbekannten nicht gespeichert wurden.

Letztlich möchte ich nun auch meine Entscheidung bekanntgeben, welches Statistik-Tool weiterhin auf fabianletscher.de genutzt wird. Ich habe mich nun letztlich für Google Analytics entschieden. Wenn man die Fakten vergleicht stellt man eine durchaus starke Abweichung fest. Da meine Besucherzahlen bisher sehr gering sind, fallen die Anteile noch mehr ins Gewicht. Ich habe mich letztlich für Google Analytics entschieden, da es mehr Möglichkeiten bietet und so für die Zukunft sinnvoll erscheint. Es gibt schon einiges, was ich an Piwik besser finde – so habe zum Beispiel ich die alleinige Kontrolle über die Daten und sie sind bei jedem Aufruf aktuell. Jedoch habe ich auch bemerkt, dass die Datenbank von Piwik sehr schnell anwächst. (Hier kann ich aber nichts Näheres dazu sagen, da ich noch nicht so lange Piwik getestet habe.)

Zum Abschluss: Ganz von Piwik trenne ich mich nicht. Ich habe mich nur entschieden Piwik für die Webseite nicht mehr einzusetzen. Dagegen werde ich das Statistik-Tool für andere Webseiten nutzen um so noch mehr Erkenntnisse zu sammeln und die Entwicklung begutachten zu können. Denn im Grunde steckt dahinter viel Potential.

Weiterführende Links

• Ergebnis: Google Analytics gegen Piwik von t3o.org

WordPress – mehr Suchergebnisse

In diesem Beitrag geht es um einen kleinen Mehrwert, den ich am Beispiel der Template-Datei search.php zeigen werde. Zunächst soll die Anzahl der Suchergebnisse, sowie das gesuchte Wort ausgegeben werden. Zusätzlich soll die Anzahl der Suchergebnisse auf 10 erhöht werden.

Die WordPress-Suche ist nicht gerade die effektivste Lösung, wenn es um das Suchen auf der eigenen Plattform geht. Um trotzdem eine kleine Verbesserung zu erzielen und keine Plugins zu nutzen, zeige ich ein paar Funktionen. Zunächst einmal soll in der Überschrift der Seite die Anzahl der Suchergebnisse und das Suchwort mit ausgegeben werden. Dazu findet man in der Loop die Überschrift der Seite. Man ersetzt mit folgendem:

<code>
<h2><?php echo $wp_query->found_posts; ?> Suchergebnisse für "<?php echo the_search_query(); ?>"</h2>
</code>

Der erste Teil fragt die Anzahl der Suchergebnisse ab und mit the_search_query() wird das gesuchte Wort ausgegeben.

Die Anzahl der auszugebenden Suchergebnisse wird grundlegend über das Backend bestimmt. Die Einstellung findet man über “Einstellungen → Ausgabe → Blogseiten zeigen maximal”. Jedoch bewirkt eine Änderung hier, dass jedes Mal beim Aufruf der Loop genau diese Anzahl an Posts dargestellt wird. Das Problem lässt sich auch wieder direkt in der search.php des Templates lösen mit der query_posts()-Funktion.

<code>
<?php query_posts($query_string . '&post_type=any&showposts=10'); ?>
</code>

Diese Zeile sollte vor Beginn der Loop stehen. Zur Erklärung der Parameter: Die Variable $query_string ist sehr wichtig, da sie dafür sorgt, dass die eigentliche Intention beibehalten wird. Dadurch wird also zunächst einmal der Suchvorgang nicht unterbrochen. Weiterhin wird sowohl in den Artikeln als auch in den Seiten gesucht und die Anzahl der herausgegebenen Suchergebnisse pro Seite auf 10 erhöht.

Bei mir findet die query_posts()-Funktion auch in der archive.php Anwendung, da ich hier auch mehr Posts ausgeben möchte, als grundlegend im Backend eingestellt. Der Einsatz dieser Funktion ist dabei ziemlich vielfältig, wenn es um die Loop geht. Daher lohnt sich ein Blick in die Funktionsreferenz.