Für eine Kunden-Website mit WordPress-Unterbau hatte ich einmal eine kleine Daten­bank­anwendung gebaut: Die Pfade zu den Logos der angeschlossenen Mitgliedsunternehmen wurden automatisch aus den Datensätzen einer Datenbanktabelle ausgelesen und an eine JavaScript-Slideshow weitergereicht. Bei einer Änderung eines Firmenlogos oder bei neu hinzugekommenen oder ausgeschiedenen Unternehmen wird ja sowieso die Datenbank geändert, und nun muss man nicht auch noch von Hand die Diaschau pflegen.

Das klappte auch lange Zeit sehr gut, aber vor einiger Zeit erschien eine Fehlermeldung über der Diaschau: Warning: Missing argument 2 for wpdb::prepare(), called in […]. In WordPress-Versionen ab 3.5 benötigt das $wpdb-Objekt zwei Argumente, vorher hatte eines genügt. Genauer gesagt: im Fall, dass eine WHERE-Klausel gesetzt wurde, werden zwei Argumente benötigt; aber offensichtlich auch, wenn man ORDER BY verwendet. Da es in diesem Fall kein sinnvolles zweites Argument geben kann, setzte ich NULL dahinter, und das Problem war erledigt.

global $wpdb;
$wpdb->show_errors();
$mitglieder = $wpdb->get_results (
    $wpdb->prepare (
        "SELECT logoundinfo
        FROM [Tabelle]
        ORDER BY firmenname ASC", NULL
    )
);

Genauere Angaben zur Verwendung der wpdb-Klasse findet man im sogenannten WordPress-Codex, also der Code-Referenz.

Als ich kürzlich in den WordPress-Quelltext einer Kunden-Website schaute, wunderte ich mich über den aufgeblähten Kopfbereich der untersuchten HTML-Datei. Da war ein JavaScript-Code, den ich nicht kannte und der ursprünglich nicht dort gewesen war, und zusätzlich gab es noch ein paar CSS-Angaben. Der Begriff wpemojiSettings fiel mir auf, und ich forschte erst mal nach, was ein Emoji ist. Nun, es ist ein Ideogramm, ähnlich wie ein Smiley oder Emoticon – der Begriff Emoji ist aber weiter gefasst und nicht auf Emotionen beschränkt.

Da ich den Quellcode gern schlank halte, aus Geschwindigkeitsgründen auf alles Überflüssige verzichten möchte und nicht zuletzt der Meinung bin, dass man im geschäftlichen Bereich ganz gut ohne alberne Bildschriftzeichen auskommen kann, stand die zweiteilige große Frage im Raum: »Wie ist der Mist da hinein gekommen und wie werde ich ihn wieder los?«

Die Antwort fand ich auf ehtio.de: Die Emojis kamen mit dem WordPress-Update 4.2, und loswerden kann man sie durch ein wenig Code in der Datei functions.php. Danke an Tim Ehling für seinen Blogartikel und die elegante Lösung!

Ich versuche immer, meine HTML- und CSS-Quellcodes schlank zu halten. Erstens, weil man dann bei späteren Bearbeitungen besser durchblickt, und zweitens, weil Suchmaschinen es lieben, wenn Webseiten so beschaffen sind, dass sie deutlich mehr echten Inhalt als Layout-Angaben beinhalten.

Zum Beispiel trägt das benutzerdefinierte Menü von WordPress zu viel Ballast mit sich. CSS-Klassen, die zwar im Quelltext aufgeführt sind, aber gar nicht benötigt werden, blähen Webseiten unnötig auf und sollten entfernt werden. Was kann man tun?

Wie so oft liegt die Lösung darin, Code in die Datei functions.php, die man im Theme-Ordner findet, einzufügen. Aber wie? Das erfährt man von Monika in ihrem Blog texto.de. Da es in deutscher Sprache ist, schlage ich vor, bei Interesse ihren sehr gut erklärten Artikel HTML output von wp_nav_menu verringern zu lesen.

In aller Regel wird man, wenn man ein WordPress-Blog erstellt, keinen Link zur Startseite im Navigationsmenü vorfinden. Man kann aber einen dorthin bekommen.

In dieser Kurzanleitung fangen wir mal ganz bei Null an und basteln uns eine Navigation selbst. Falls sie in dieser Form schon im Theme vorhanden ist, können die Punkte 1 bis 3 übersprungen werden.

Davon ausgegangen, dass es sich sich um ein selbst gehostetes WordPress handelt (also nicht um ein bei WordPress.com eingerichtetes) und dass wir natürlich FTP-Zugriff zum Webserver haben, dann sind folgende Schritte zu unternehmen:

1. Menü-Funktion hinzufügen

   Um ein benutzerdefiniertes Menü zu ermöglichen, das dann übers Dashboard konfiguriert werden kann, folgenden Code der Datei functions.php im Theme-Ordner hinzufügen:
   

   add_action( 'init', 'my_custom_menus' );
    
   function my_custom_menus() {
       register_nav_menus(
           array(
               'primary-menu' => __( 'Primary Menu' ),
               'secondary-menu' => __( 'Secondary Menu' )
           )
       );
   }

   In diesem Fall wollen wir zwei Navigationsmenüs haben, eine Hauptnavigation und eine untergeordnete.

2. Template-Datei modifizieren

   Unser Theme müssen wir jetzt mit den Navigationsmenüs ausstatten; dafür fügen wir folgenden Code ein, im Fall des Hauptmenüs wohl am ehesten in die Template-Datei header.php:
   <?php wp_nav_menu( array( 'theme_location' => 'primary-menu', 'menu_class' => 'primary', 'fallback_cb' => '') ); ?>.
   Mit dem Submenü verfahren wir ähnlich. – In unsere CSS-Datei können wir jetzt die Klasse primary-menu einfügen, um das Navigationsmenü zu gestalten. Die Fallback-Möglichkeit ist für den Fall gedacht, dass es überhaupt kein Menü gibt (weil zum Beispiel gar keine Subnavigation benötigt wird), dann wird nichts angezeigt.

3. Menü im Dashboard erstellen

   Im Admin-Dashboard der WordPress-Installation klickt man jetzt auf Design > Menüs, wo man jetzt den Menübaukasten sieht. Dort kann man seine Navigationsmenüs auf einfache Weise konfigurieren.

4. Homepage-Link im Navigationsmenü anzeigen

   Dumm ist nur, dass die Homepage (die Startseite) dennoch nicht in unserer Navigationsleiste angezeigt wird bzw. nicht im Menübaukasten als Menüpunkt erscheint. Auch hier liegt die Lösung darin, dass man die Datei functions.php im Theme-Ordner um etwas Code erweitern muss:
   

   function home_page_menu_args( $args ) {
       $args['show_home'] = true;
       return $args;
   }
   add_filter( 'wp_page_menu_args', 'home_page_menu_args' );

   Sobald dieser Code eingefügt worden ist, sollte das dazu führen, dass »Home« als Option unter dem »Seiten«-Widget auf der Menü-Verwaltungs-Seite erscheint, sodass man jetzt per Klick entscheiden kann, ob die Startseiten in der Navigation angezeigt werden soll oder nicht.

Quellen:
Box Model Junkie
WPBeginner

Frank Bültge, den man wohl als eines der deutschsprachigen WordPress-Urgesteine bezeichnen darf, hat vor Jahren eine recht lange Liste von nützlichen WordPress-Plugins vorgestellt, die er entwickelt hat, an denen er in irgendeiner Weise mitgewirkt hat oder die er empfiehlt.

Einer meiner Lieblinge ist AddQuicktag. Denn mit den vorgegebenen Quicktags (also den Schaltflächen, mit denen man auf einfache Weise häufig benötigte HTML-Elemente in den Textbereich des Editors einfügen kann) war ich nie so ganz zufrieden. Es fängt ja schon damit an, dass die Buttons b und i die Elemente <strong> und <em> erzeugen. In HTML5 haben aber bold und strong bzw. italic und emphasis völlig unterschiedliche Bedeutungen (was an dieser Stelle nicht näher ausgeführt werden soll). Darüber hinaus fehlen zum Beispiel öfters benötigte Sonderzeichen. Und natürlich wäre es wünschenswert, immer wiederkehrende Code- oder Text-Schnippsel als Schaltflächen in die Menüleiste des Editors aufnehmen zu können.

Mit AddQuicktag ist das alles auf eine sehr leichte Weise zu bewerkstelligen. Dieses Plugin erleichtert mir wirklich die Arbeit und beschleunigt das Erstellen von Blogartikeln.

Die Werkzeugleiste des Editors in WordPress ist ja nicht unbedingt nach jedermanns Geschmack. Einige Schaltflächen mag man als überflüssig empfinden; andere oft benötigte HTML-Elemente werden gar nicht als Button angeboten. Glücklicherweise gibt es Hilfe in Form von Plugins, mit denen man diese Toolbar anpassen oder auch völlig ummodeln kann. Das leistungsfähigste Plugin, das ich finden konnte, ist AddQuicktag von Frank Bültge. Denn hiermit lassen sich nicht nur neue Elemente hinzufügen und sortieren, sondern sogar die standardmäßig vorgegebenen entfernen. Und das alles über eine sehr einfach zu bedienende Oberfläche.

Der Editor im WordPress-Backend lässt sich ja zwischen visueller und HTML-Ansicht umstellen. Benötigt man die visuelle WYSIWYG-Ansicht nicht, lässt sie sich in den Benutzereinstellungen deaktivieren. So handhabe ich es in meinen eigenen Blogs, in denen nur ich selber schreibe.

Was aber, wenn man ein Blog für mehrere Autoren anbietet oder eins für einen Kunden erstellt? Nicht alle der im WYSIWYG-Editor angebotenen zusätzlichen Möglichkeiten sind sinnvoll einsetzbar. Zum Beispiel könnte ein Autor unpassende Textfarben einstellen. Aber durch eine Zeile Code in der Datei functions.php im Theme-Ordner kann man diesen visuellen Editor deaktivieren.

Hier steht, wie es geht: www.guru-20.info.

Für mich ist WordPress immer noch am ehesten ein Blogsystem. Wenn also das Hauptaugenmerk eines Webauftrittes nicht auf einem Blog- oder Newsbereich liegt, sondern hohe Flexibilität in den Seitenlayouts gefragt ist, würde ich WordPress eher nicht einsetzen.

Für eine bestimmte Kundin standen die News stark im Vordergrund, weswegen ich WordPress wählte. Allerdings gibt es auch eine ganze Anzahl »statischer« Seiten (pages), die jedoch nicht alle gleich aufgebaut sind. Manche haben einen vollformatigen Inhaltsbereich, andere eine Seitenleiste (sidebar). Innerhalb des Gestaltungsthemas (theme) muss es also verschiedene Seitenvorlagen (templates) geben. Darüber hinaus müssen die Seitenleisten je nach Seite unterschiedliche Inhalte tragen.

Das in WordPress umzusetzen, war eine neue Anforderung für mich. In meinem anderen Lieblings-System, concrete5, ist so etwas super-leicht umzusetzen, aber auch in WordPress geht es ganz gut, wenn man erst einmal weiß, wie. Die Lösung fand ich auf drei Websites, und zwar so gut erklärt, dass ich mir die Mühe spare, alles mit eigenen Worten wiederzugeben. Hier sind die Quellen:

Templates für Seiten (Pages) in WordPress
[WordPress] Mehrere Sidebars nutzen
{WordPress} Unterschiedliche Inhalte in der Sidebar anziegen

Ist mir gerade passiert: drei Plugins waren in WordPress zu aktualisieren, was normalerweise glatt über die Bühne geht. Diesmal jedoch blieb WordPress im Wartungsmodus hängen und ich konnte das Backend nicht mehr bedienen. Zum Glück fand ich schnell eine sehr einfache Lösung, und zwar im Blog von Ansas Meyer: WordPress Wartungsmodus manuell beenden. Vielen Dank für den Tipp!

Blogs, die auf dem wohl verbreitetsten Blogsystem WordPress laufen, sind natürlich äußerst beliebte Ziele von Crackern. Bots versuchen, durch wiederholtes Ausprobieren von Benutzernamen und Passwörtern in die Systeme einzudringen. Diese Brute-Force-Attacken sind weit verbreitet.

Es gibt verschiedene Möglichkeiten, sich zu schützen, die ich in diesem Rahmen nicht alle besprechen möchte. Sicherlich fängt der Schutz damit an, dass man keinen Benutzer admin im System hat und natürlich keine Passwörter wie password oder 1234 benutzt.

Ein bekanntes und beliebtes, wenn auch inzwischen veraltetes Plugin ist Limit Login Attempts, das eben diese Brute-Force-Attacken abzuwehren versucht. Wie es das macht, beschreibt Vladimir Simović in seinem Blog perun.net.

Dumm nur, wenn man sich selbst ausschließt. Es ist peinlich, aber ich muss zugeben: mir ist das gestern passiert. Irgendwie habe ich wohl drei- oder viermal ein altes, nicht mehr gültiges Passwort eingegeben, und schon kam ich nicht mehr ins Backend hinein. Vladimir empfiehlt, entweder die Zeitsperre abzuwarten oder eine andere IP-Adresse zu verwenden. Dazu müsste man im Falle eines DSL-Modems die Internet-Verbindung trennen und sich neu einloggen. Im Falle eines DSL-Routers müsste man vermutlich den Router neu starten, um eine andere IP zu erhalten, oder?

Ich schlage eine weitere Möglichkeit vor. Sie setzt allerdings voraus, dass man Zugriff auf die WordPress-Datenbank hat, und den hat man nur bei einem selbst gehosteten WordPress-Blog, nicht aber bei einem Blog auf wordpress.com. Außerdem eignet sich diese Methode auch nur für versierte Anwender. Und zwar löscht man einen Eintrag in der Datenbank (zum Beispiel über phpMyAdmin, falls der Webhoster es zur Verfügung stellt oder man es selbst installiert hat).

Im Detail: Tabelle wp_options, Feld option_name, Eintrag limit_login_lockouts, Feld option_value, und hier den Eintrag aus <MEMO> löschen.

Allerdings gibt es Plugins mit weiteren Möglichkeiten, sein WordPress-Blog sicher zu machen. Mehrere werden auf t3n.de vorgestellt. Welche man einsetzen will, mag jeder für sich entscheiden.