Wenn man seinen Webhoster wechselt, möchte man in der Regel auch mit dem Statistik-Tool umziehen. Daher hier eine kurze Erklärung wie dies mit Piwik funktioniert.

Dazu wird folgendes benötigt:

• FTP-Zugriff mit Client
• phpMyAdmin

Zuerst kümmern wir uns um ein Backup der Datenbank. Ich beschreibe hier nur den Weg für phpMyAdmin – andere Datenbank-Tools funktionieren natürlich auch. Zuerst wird die entsprechende Datenbank in der linken Spalte ausgewählt. Dann reicht ein Klick auf “Exportieren” und mit OK bestätigen. Wenn gewünscht können hier noch Voreinstellungen gemacht werden – ist aber prinzipiell nicht nötig.

Nun sollte von Piwik die neueste Version heruntergeladen werden und in das entsprechende Verzeichnis auf dem neuen Webspace kopiert werden. Es ist keine Installation erforderlich! Die config/config.ini.php-Datei vom alten Webspace sollte nun erstmal in den gleichen Ordner auf dem neuen Webspace verschoben werden. Hier nehmen wir einige Einstellungen vor. Dazu die Datei mit einem geeigneten Editor öffnen und bearbeiten:

[superuser]
login = "Name"
password = "kryptische Ziffern"
email = "Email-Adresse"
salt = "kryptische Ziffern"

[database]
host = "localhost"
username = "Benutername"
password = "Passwort"
dbname = "Datenbankname"
tables_prefix = "piwik_"
adapter = "PDO_MYSQL"
port = 3306

Im ersten Block sollte nichts verändert werden. Hier sind die Zugangsdaten des Administrators angegeben. Der nächste Block bezieht sich auf die Datenbank. Hier nehmen wir nun die entsprechenden Veränderungen vor. Das Tabellenpräfix sollte behalten werden, da nun gleich das Backup auf dem neuen Server eingespielt wird.

Also phpMyAdmin öffnen und via “Importieren” die entsprechende Datei hochladen. Hier sollte man aber sagen, dass es sowohl beim Backup erstellen als auch beim Importieren zu Schwierigkeiten kommen kann, wenn die Datei zu groß ist. Dann müsste diese vorher in kleine Stücke zerlegt werden.

Somit sind wir auch fertig. Zum Abschluss aber noch ein Hinweis: Piwik selbst ist nicht an eine bestimmte URL gebunden – allerdings der Tracking Code schon. Daher Domain wieder richtig setzen oder Tracking Code im Backend aktualisieren und in die Webseite neu einfügen.

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.

Dabei kann man auch wieder auf die Conditional Tags von WordPress zurückgreifen, was ich schon in einem anderen Beitrag beschrieben habe. Meine Version des title-Tags sieht so aus:

<code>
<title>
<?php bloginfo('name'); ?> | <?php bloginfo('description'); ?>
<?php if ( is_single() ) { ?> » Blog <?php } ?> <?php wp_title(); ?>
</title>
</code>

Zuerst wird der Blog-Name ausgegeben und dahinter abgetrennt mit “|” die Blog-Beschreibung. Beides lässt sich über das WP-Backend festlegen über Einstellungen → Allgemein. Falls es sich um einen Artikel handelt wird “» Blog” noch dazwischen eingefügt, bevor der Titel der Seite kommt.
In der Gestaltung des Titels ist man relativ frei. Möchte man beispielsweise, dass die Blog-Beschreibung nur auf der Startseite kommt, kann man dies mithilfe von is_home() tun.

Was soll geleistet werden?

Falls ein Nutzer die Adresse einer bestimmten Seite falsch in Erinnerung hat, sollen beim Erscheinen der Fehlerseiten mögliche Kandidaten als Vorschläge erscheinen. Diese sollen einen Hyperlink herausgeben zum gewünschten Artikel oder Seite. Die Datenbank soll dabei durchsucht werden. Das zur Suche verwendete Stichwort ist im Falle einer Trennung mit Backslash (“/”) das zuletzt verwendete Wort, bei einer Trennung mit Punkt (z.B. bei einer Dateiangabe wie .html oder .jpg) das Wort vor dem Punkt.

Die Umsetzung

Im folgenden Teil wird zunächst die aktuelle Adresse ausgelesen. Dann wird sie in ein Array gepackt welches nach “/” abgetrennt wird. Es wird das letzte Wort ermittelt nach einem Backslash. Falls kein Wort mehr dort steht wird das Wort davor weiterverarbeitet.
Dann kommt eine Untersuchung auf Datei-Endungen. Es wird wieder das Wort getrennt, bei einem Punkt. Das Wort vor dem Punkt ist ausschlaggebend und wird als Suchwort benutzt. In dem Array $liste2 befindet sich das Suchwort an “Platz” Null.

<code>
<?php $string = $_SERVER['REQUEST_URI'];
		$liste = explode("/",$string);
		$count = (count($liste)-1);
		if ($liste[$count] == "") {$string2 = $liste[($count-1)];} else {$string2 = $liste[$count];}
		$liste2 = explode(".",$string2);
		// Bis hierin wird der letzte Begriff ausgewählt, welcher in der Adresszeile steht, da dieser höchst wahrscheinlich sinnvoll ist.
</code>

Nun geht es weiter mit der Suchanfrage auf die Datenbank. Es wird dabei im Titel und in einem “Post” selbst nach dem Begriff gesucht. Es muss sich um eine Seite oder ein Artikel handeln und darf kein Entwurf sein. Letztlich wird ein Link in einer ungeordneten List ausgegeben. Falls keine Ergebnisse gefunden wurden, erscheint eine Mitteilung.

<code>
//Nun soll die Suche gestartet werden!
$abfrage = "SELECT * FROM $wpdb->posts WHERE (post_content LIKE '%".addslashes(strip_tags($liste2[0]))."%' OR post_title LIKE '%".addslashes(strip_tags($liste2[0]))."%') AND (post_type = 'page' OR post_type = 'post') AND NOT(post_status = 'draft') GROUP BY post_title ASC";
$posts = $wpdb->get_results($abfrage);?>
<?php if (!empty($posts)) { ?>
<p><em>Hier könnte was passendes dabei sein:</em></p>
<ul>
	<?php foreach($posts as $the_post) { ?>
  	<?php $post = get_postdata($the_post->ID); ?>
	<li>
	<a href="<?php echo get_permalink($post['ID']); ?>" title="<?php echo $post['Title']; ?>">
	<?php echo $post['Title']; ?></a>
      	</li> <?php } ?>
</ul>

		<?php } else { ?>
		<p><em>Leider konnten keine möglichen Ergebnisse angezeigt werden! Benutze bitte die Suche und achte auf die Rechtschreibung!</em></p>
		<?php } ?>

</code>

Bei der Suchanfrage ist dem ein oder anderen vielleicht aufgefallen, dass es nicht die übliche Anfrage ist. Diese Version lässt es offen welches Präfix man für seine Tabellen benutzt. Bei der herkömmlichen Methode muss man das mitangeben. Somit ist diese Version unabhängig von der WP-Installation. Diese Art der Abfrage habe ich auf i-jeriko gefunden als ich nach einer Möglichkeit gesucht habe die letzten WordPress-Kommentare anzuzeigen.

Was gibt es noch zu bemängeln?

Ja – Es ist nicht perfekt! Vieles bleibt bei dieser Art unberücksichtigt. Zum einen muss der Nutzer bereitwillig die vollständige Adresse eintippen (die jedoch nicht existiert). Er darf dabei keine Rechtschreibfehler machen (sofern ich nicht selbst welche dabei habe). Dies wird in den wenigsten Fällen der Fall sein, da wenn man sich schon eine Adresse merkt, dann wird man sie höchstens falsch schreiben. Zudem wird es bei WP-Blogs dann schwierig, wenn sowieso keine sprechenden URLs verwendet werden.
Keine sinnvollen Ergebnisse erhält man bei einer Angabe wie “/die/”, da dies letztlich wohl alle Beiträge anzeigt. Die Sortierung ist auch nicht gerade ausgefeilt. Es wird nicht nach Priorität ausgegeben sondern alphabetisch. Somit könnte ein wesentlich besserer Artikel weiter unten stehen und ein unpassender ganz vorne. Jedoch ist es schwierig dies umzusetzen. Man könnte gegebenenfalls die Häufigkeit der Suchwörter als Merkmal benutzen, ob aber dies wirklich viel effektiver ist, bezweifle ich noch.

Weitere Tipps, Kritik und Ideen werden gern angenommen.

Fazit

In der Tabelle erkennt man deutlich, dass eine Optimierung des Stylesheets sich als schwierig erweist. Die drei benutzen “Optimierer” bieten drei verschiedene Ansätze an. Davon vergrößert einer sogar die Datei. Grundlegend hängt diese Optimierung stark vom Aufbau der Datei ab, kann also immer verschiedene Ergebnisse erzielen. Ich würde daher empfehlen, erst mal selbst über den eigenen Code zu schauen. Vieles kann man erst mal selbst verbessern, immerhin kennt der Ersteller sich damit am besten aus. Danach kann man immernoch einen dieser CSS-Verbesserer nutzen und vergleichen welcher den größten Erfolg verbucht.

Tipps zur Optimierung des eigenen Stylesheets

1. Mehrere IDs sind nicht immer günstig

   Mir ist aufgefallen, dass ich beim Erstellen des Stylesheets viele IDs hintereinander benutze um eine Struktur zu bewahren. Dies ist dann immer unnötig, wenn die ID in keinen Zusammenhang mit einer anderen steht. Beispiel:

   <code>
   #wrapper form#searchform {...}
   /* Dies lässt sich so vereinfachen */
   #searchform {...}
   </code>
   

   Die ID “searchform” soll immer gleich auf der Seite aussehen, egal welche andere ID davorsteht. Zudem ist klar, dass es sich um eine “form” handelt.

2. Gleiche Inhalte zusammenfassen

   Oft kommt es vor, dass man das gleiche Attribut mit dem gleichen Wert im Stylesheet öfters benutzt. Die kann man ganz einfach zusammenführen, indem man die verschieden Elemente mit Kommata abtrennt.

   <code>
   #searchform {display:none}
   .hide {display:none}
   /* Dies lässt sich so vereinfachen */
   #seachform, .hide {display:none}
   
   </code>

3. Grundlegende Formatierung vornehmen

   Darunter verstehe ich, dass beispielsweise bei einem Hyperlink das Attribut “text-decoration” auf “none” gesetzt wird. Falls man dies nicht am Anfang des Stylesheets schon festlegt, muss man jedes “a”, dass darin vorkommt mit diesem Wert zuweisen. Das verbraucht unnütz viel Speicherplatz. Einige empfehlen ein Reset-Stylesheet immer einzufügen, das solche grundlegenden Sachen übernimmt.

4. Kurzschreibweise

   Wirklich effizient ist es die Kurzschreibweise zu benutzen. Da spart man sich sehr viel Tipparbeit und es spart Platz. Dies funktioniert mit einigen Attributen sehr gut. Hierdurch kann allerdings auch einiges an Übersichtlichkeit verloren gehen. Beispiel:

   <code>
   font-family: helvetica, arial, sans-serif;
   font-size: 10px;
   /* Dies lässt sich so vereinfachen */
   font: 1px helvetica, arial, sans-serif;
   
   </code>

5. Das Semikolon vor dem Schließen weglassen

   Wenn die Wertezuweisung zu Ende ist, kann man das Semikolon getrost weglassen. Ich mache dies allerdings nicht, da einer meiner häufigsten Fehlerquellen darin liegt ein Semikolon zu vergessen. Wenn man jedoch fertig ist kann man gerne nochmal drüber schauen und die unnötigen entfernen. Beispiel:

   <code>
   a {text-decoration:none;}
   /* Dies lässt sich so vereinfachen */
   a {text-decoration:none}
   
   </code>

Hier findet man auch genug solcher Bedingungen. Ich habe mich beispielsweise dafür entschieden, die Sidebar so zu gestalten, dass bei einem Artikel die Informationen über den Autor, die Kategorie und Datum der Veröffentlichung in dieser erscheinen. Dies gestaltet sich mit den Conditional Tags sehr einfach:

<code>
<?php if (is_single () ) {
      //Hier erscheint die Anweisung, wenn es ein Artikel ist
   }
</code>

Dies ist beliebig erweiterbar. Statt “single” kann man, wie die Dokumentation zeigt, eine Vielzahl anderer Bedingungen aufstellen. Es erlaubt einem auch den Titel der Webseite speziell anzupassen und findet in vielen Formen eine Anwendung.