Das Plugin W3 Total Cache ist eine tolle Möglichkeit, die eigene Website deutlich schneller zu machen. Wenn man Beiträge nachträglich ändert oder Seiten speichert, muss man jedoch den Cache manuell leeren, damit die Änderungen auf der Website sichtbar werden. Dafür gibts das Plugin W3 Total Cache Purge All Page, das den Cache leert, sobald man einen bestehenden Beitrag ändert.

Sofern man aber auch Benutzerdaten in seine Pages eingebunden hat, reicht das nicht aus – denn wenn ein Benutzer seine Daten ändert, werden nach wie vor die alten Daten aus dem Cache auf der Website angezeigt. Das lässt sich mit wenigen Zeilen Code in der Datei functions.php beheben:

/* Cache leeren, wenn Benutzerdaten gespeichert werden */
function xyz_clearCache()  {
	if (function_exists('w3tc_pgcache_flush')) {
		w3tc_pgcache_flush();
	} 
   return true;
}
add_action('user_register', 'xyz_clearCache');
add_action('profile_update', 'xyz_clearCache');

Aus Sicherheitsgründen ist es ratsam, das WordPress-Tabellenprefix nicht beim Standardwert wp_ zu belassen. Wenn man das nachträglich bei einer WordPress-Installation vornimmt, muss man einerseits in der wp-config.php das neue Prefix eintragen (z.b. wp_projektname_) und danach vie Datenbanktool (z.B. phpmyadmin) alle Tabellen umbenennen.

Danach wird allerdings kein Login in den Admin-Bereich möglich sein, da das Tabellenprefix auch in den Datenbankeinträgen in wp_options einige Male zu finden ist. Abhilfe schaffen folgende kurzen SQL-Befehle:

UPDATE neuesPrefix_options SET option_name = REPLACE(option_name, 'altesPrefix_', 'neuesPrefix_');
UPDATE neuesPrefix_usermeta SET meta_key = REPLACE(meta_key, 'altesPrefix_', 'neuesPrefix_');

Danach klappts auch wieder mit dem Einloggen :-)

Kontaktfelder kann man sehr einfach zum WordPress-Benutzerprofil hinzufügen oder entfernen. Einfach dieses Codeschnipsel in die functions.php einfügen:

// Kontaktmethoden hinzufügen

add_filter('user_contactmethods', 'meine_neuen_kontaktfelder');
              
function meine_neuen_kontaktfelder($user_contactmethods){
 
    // Neue Felder hinzufügen (Name / Beschriftung)
  $kontaktfelder['twitter'] = 'Twitter @username';
  $kontaktfelder['facebook'] = 'Facebook URL';
  $kontaktfelder['gplus'] = 'Google+ URL';
  
  // Nicht benötigte Felder entfernen
  unset($kontaktfelder['yim']);
  unset($kontaktfelder['aim']);
  unset($kontaktfelder['jabber']);
 
  return $kontaktfelder;
}

Der Abruf im Theme erfolgt wie bei anderen Benutzer-Metadaten:

$metadata = get_user_meta($benutzerID);

echo "Twitter:  ".$metadata['twitter'][0];
echo "Facebook: ".$metadata['facebook'][0];
echo "Google+:  ".$metadata['gplus'][0];

Normalerweise kann jeder Benutzer die Meta-Boxen rund um den Editor selbst zuschalten oder wegschalten (im Editorfenster rechts oben unter “Optionen”), bei Kundenprojekten kann es aber sinnvoll sein, manche der Boxen serienmäßig aus- oder einzuschalten oder deren Reihenfolge vorab festzulegen. Das geht mit ein bißl Bastelei recht flott:

– In den Verwaltungsbereich einloggen, das Editorfenster für Beiträge aufrufen (z.B. mit “Beitrag -> Erstellen”) und rechts oben unter “Optionen” alle Boxen wegschalten, die nicht gebraucht werden.

–  Mindestens eine der Boxen an eine neue Position ziehen. Das kann man unmittelbar danach wieder rückgängig machen, aber so wird der entsprechende Eintrag in der Datenbanktabelle wp_usermeta angelegt.

– Nun kann man in der Datenbanktabelle wp_usermeta die Einträge

meta-box-order_post
metaboxhidden_post

zur eigenen Benutzer-ID suchen. Dort stehen die Reihenfolge der Boxen sowie die versteckten Boxen drin (zwar nicht ganz im Klartext, aber es sollte kein Problem sein).

– In der functions.php folgendes Codeschnipsel einfügen und entsprechend anpassen:

// Reihenfolge und eingeschaltete Editorboxen definieren
add_action('admin_init', 'set_user_metaboxes');
function set_user_metaboxes($user_id=NULL) {
    // aktuelle User-ID herausfinden
    if ( ! $user_id) $user_id = get_current_user_id(); 
    // 1. Reihenfolge für Meta-Boxen bei Beiträgen festlegen
    if ( ! get_user_meta( $user_id, 'meta-box-order_post', true) ) {
        $meta_value = array(
            'side' => 'categorydiv,submitdiv,postimagediv',
            'normal' => 'revisionsdiv,postcustom,commentstatusdiv,commentsdiv,slugdiv,authordiv',
            'advanced' => '',
            );
        update_user_meta( $user_id, 'meta-box-order_post', $meta_value );
	}
    // 2. Versteckte Meta-Boxen bei Beiträgen festlegen
    if ( ! get_user_meta( $user_id, 'metaboxhidden_post', true) ) {
        $meta_value = array('page_option_choice','postexcerpt','trackbacksdiv','postcustom','slugdiv'); 
        update_user_meta( $user_id, 'metaboxhidden_post', $meta_value ); 
        }
    // Hier ggf. noch gleichlautende Codes für Pages oder benutzerdefinierte Typen hinzufügen 
        // 1. Reihenfolge für Meta-Boxen bei Seiten festlegen (Code von oben anpassen)
        // 2. Versteckte Meta-Boxen bei Seiten festlegen (Code von oben anpassen)
 } // Ende der Funktion

– Für den Seiten-Editor lauten die entsprechenden Einträge in der wp_usermeta entsprechend metaboxhidden_page und meta-box-order_page, für benutzerdefinierte Beitragstypen metaboxhidden_TYPE und meta-box-order_TYPE, ansonsten bleibt die Vorgangsweise gleich.

Wenn man Websites mit WordPress und dem Genesis-Framework baut, dann spart das viel Arbeit. Durch den immer gleichen modularen Aufbau kann man auch umfangreichere Arbeiten relativ flott umsetzen. Hier eine englische Anleitung, wie man ein Genesis Theme in weniger als einer Stunde handytauglich macht.

Einziger Punkt, der mir noch dabei gefehlt hat: wenn man position:absolute; im Stylesheet verwendet, so muss man diese Angabe durch position:static; ersetzen.

Wenn man den Link zu einer Website auf Facebook postet, so holt sich Facebook den aktuellen Inhalt und verschiedene Angaben im Seitenkopf, um Titel, Beschreibung und ein Vorschaubild anzeigen zu können. Diese Angaben werden bei Facebook zwischengespeichert, damit dieser Vorgang nicht jedesmal Traffic verursacht. Wenn aber genau zu diesem Zeitpunkt der Inhalt dieser Website nicht korrekt aufbereitet wurde (kein Seitentitel, kein Bild oder falsche Seitenbeschreibung), so merkt sich Facebook ziemlich lange irgendwelchen Blödsinn – und jeder, der die betreffende Seitenadresse teilt, verbreitet den Schas noch weiter.

Nachdem dieses Problem nun zwei Mal kurz hintereinander bei Kundenwebsites aufgetaucht ist, die ich Facebook-fit machen sollte, habe ich mich schlau gemacht, wie man Facebook dazu bringt, diese Informationen einfach neu von der betreffenden Website abzuholen.

Das geht ganz einfach – wenn man weiß, wie:

Facebook bietet ein Tool namens “Sharing Debugger” an (das hieß früher “URL Linter”) . Dort gibt man eine Seitenadresse ein und klickt auf “Fehlerbehebung” – dann zeigt Facebook die für diese Seite zwischengespeicherten Informationen an. Wenn man dann auf “Erneut scrapen” klickt, holt Facebook die Infos zur betreffenden Website frisch von deren Server ab und bietet eine Vorschau, wie die Website-Inhalte auf Facebook beim Teilen angezeigt werden.

Netterweise überschreiben die abgeholten Daten den Facebook-Zwischenspeicher – wenn also eine Seite zickt, kann man sie entsprechend umbauen, URL in den Debugger, Ergebnis prüfen – und auch alle anderen, die ab diesem Zeitpunkt die Website-Adresse teilen, kriegen die aktualisierten Daten geliefert. Die META-Description einer Website wird z.b. als Beschreibungstext verwendet, so kann man also gezielt bestimmen, was Facebook dort anzeigen soll. Wers ganz genau wissen (und gestalten) will, der kann anstatt META-Description & Co. auch die Facebook-OpenGraph-Metatags im Seitenkopf verwenden, die sich etwa mit Plugins wie All In One SEO in WordPress ziemlich einfach einbauen lassen.

Für LinkedIn gibts ein ähnliches Tool, das nennt sich dort “Post Inspector” und funktioniert sehr ähnlich: URL eingeben, “Inspect” klicken, die Informationen werden live von der URL abgeholt und der Link-Cache für LinkedIn wird dabei automatisch erneuert. Diese beiden nützlichen Werkzeuge (und noch viele mehr) finden sich stets aktuell auf meiner Linkliste “Online-Tools”.

Mit der aktuellen WordPressversion kann ja prinzipiell mit einer Installation mehrere Websites oder Blogs betreiben. Die Einrichtung ist gar nicht schwer, es reichen einige wenige Handgriffe, um WordPress Multisite-Fähigkeiten einzuhauchen. Danach sind allerdings alle neuen Sites nur via Subdomain erreichbar, man kann also nicht verschiedene Domains nutzen. Ein Tipp übrigens: wenn man auf dem Webserver keine Wildcard-Domains anlegen kann (oder darf), dann funktioniert Multisite trotzdem. Man muss lediglich für jedes Blog die Subdomain manuell anlegen und aufs Verzeichnis der WordPress-Installation zeigen lassen.

Es gibt auch die Möglichkeit, mehrere Domains mit einer einzigen Installation zu bespielen. Dazu benötigt man das WordPress MU Domain Mapping Plugin und nochmal 15 Minuten Handarbeit an den Quellcodes. Die genaue Anleitung dazu gibts ebenfalls auf thingybob.de. Grade eben eingerichtet, funktioniert einwandfrei.

Dateien aus fremden Quellen sollte man ja grundsätzlich misstrauen. Das gilt aber auch für Bereiche, in denen der Durchschnittsbenutzer keinerlei Risiko vermutet. Siobhan Ambrose von WPMU.org hat getestet, welches Sicherheitsrisiko kostenlose WordPress-Vorlagen sein können, die man von weit oben in Google gereihten Download-Sites laden kann (die Suchbegrifffe waren schlicht “free wordpress themes”). Das Ergebnis ist erschreckend: von 10 getesteten Websites enthielten nur die Vorlagen aus dem Theme-Fundus direkt auf WordPress.org keine base64-codierten Elemente und waren daher als “sicher” einzustufen. Diese base64-codierten Programmzeilen enthalten (wenn man Glück hat) nur unerwünschte Links auf Fremdsites, um deren Google-Ranking zu erhöhen. Im schlimmsten Fall können die codierten Teile aber auch ein ernstes Sicherheitsproblem am Server verursachen.

Der Tipp der Expertin: man sollte nur Themes aus zuverlässigen Quellen verwenden. Beispielsweise kann man auf diesen  Websites fündig werden:

Mit den folgenden Plugins kann man Themes auf möglichen Schadcode prüfen:

Wenn man base64-codierte Zeilen in einem Theme entdeckt hat, kann man diese mit folgenden Tools decodieren:

Eine sichere Quelle für dein persönliches WordPress-Theme ist die EGM-Website-Werkstatt. Denn meine Vorlagendateien sind zwar nicht kostenlos, dafür sind sie auf dich oder deine Firma maßgeschneidert und enthalten keinerlei Schadcode. Garantiert :-)

Während man ab WordPress-Version 3 das Kernsystem oder die Updates aktualisiert, wird das Weblog automatisch in einen Wartungsmodus gesetzt. Seitenbesucher, die währenddessen auf Besuch kommen, kriegen lediglich zu lesen:

“Für kurze Zeit nicht verfügbar um eine regelmäßige Instandhaltung durchzuführen. Prüfe in einer Minute nochmals”

Eine feine Sache, solange beim Update alles glatt läuft. Blöd, wenn nicht: dann bleibt das Weblog im Wartungsmodus und man kann mit etwas Pech nicht einmal mehr aufs Backend zugreifen. Die Abhilfe ist einfacher als man glaubt: man verbindet sich per FTP mit dem Server, aktiviert im FTP-Programm die Anzeige versteckter Dateien und löscht im Hauptverzeichnis des Weblogs die Datei .maintenance – dann funktioniert das Login wieder und man kann dem Fehler auf den Grund gehen.

Mit dem Plugin WPML Multilingual CMS soll sich jede WordPress-Website kinderleicht mehrsprachig betreiben lassen. Die Features klingen viel versprechend, jetzt sollte ich nur noch die Zeit finden, es zu testen ;-)

Update 26.12.2009: wie der Zufall es will, brauche ich genau diese Funktionalität für ein aktuelles Projekt, da sich die Kundin dazu entschlossen hat, ihre Website mehrsprachig anzubieten. Das Plugin arbeitet bisher stabil unter WordPress 2.9 und integriert sich nahtlos in die Admin-Oberfläche. Man erhält bei jeder Seite und bei jedem Post die Auswahlmöglichkeit der Übersetzung hinzu. Die übersetzten Daten werden zwar als neue Seiten bzw. Posts mit eigener ID gespeichert, aber in der Übersichtsliste im Admin-Bereich nicht als eigene Punkte, sondern nur als Übersetzung angezeigt. Dadurch bleibt die Liste aufgeräumt und man sieht auf einen Blick, für welche Seitenbereiche bereits Übersetzungen existieren.

Das Verhalten mancher Template-Tags ist allerdings gewöhnungsbedürftig, aber im Prinzip logisch. Ich habe etwa eine Navigation eingebaut, die auf der Funktion wp_list_pages basiert. Beim Anzeigen einer übersetzten Seite war plötzlich die Navigation verschwunden. Die Lösung ist einfach – wenn mans weiß!
Weiterlesen