WordPress absichern: 10 Tipps für ein sicheres WP – Tipp 6-10

<< Zum ersten Teil des Artikels „WordPress absichern: 10 Tipps für ein sicheres WP“ (Tipp 1-5)

6. “wp-config.php” verschieben oder Zugriff zur “wp-config.php” verhindern

ordnerverzeichnis wordpress
Wenn es der Hoster erlaubt, sollte die wp-config.php ausserhalb des www-Ordners liegen

Die obenstehenden Punkte sind alle schön und gut, was aber, wenn ein Hacker es schafft, die Datei „wp-config.php“ als Textfile zu öffnen? Hier stehen beispielsweise die Datenbank-Passwörter im Klartext, was mehr als unschön ist. Zumal jedem Hacker bekannt ist, dass bei einer Standard-Installation diese Datei im Root liegt.

Eine nette Möglichkeit ist, diese Config-Datei aus dem Root in ein Verzeichnis unterhalb des Root-Verzeichnis zu verschieben. WordPress kann auch auf solche Verzeichnisse ohne Anpassung zugreifen. Wenn das Root-Verzeichnis beispielsweise „meineDomain_de/httpdocs“ heißt und der Hoster eine Dateiablage unterhalb des „www“-Verzeichnisses erlaubt, sollte man die wp-config.php aus „meineDomain_de/httpdocs“ in das Verzeichnis „meineDomain_de“ verschieben. Die meisten Hoster erlauben jedoch einen Zugriff unterhalb des eigentlichen Web-Verzeichnises nicht. Für diese Installationen bleibt die Möglichkeit, den Zugriff auf die Datei noch weiter per .htaccess-Datei zu verhindern. In der zentralen .htaccess-Datei (oder vhosts – siehe Punkt 10) einfach das nachfolgende Code-Fragment hinzufügen.

<files wp-config.php>
Order deny,allow
deny from all
</files>

7. Admin-Zugriff nur per SSL erlauben

Sofern der Hoster einen SSL-Zugang ermöglicht, sollte dies auf jeden Fall auch genutzt werden. Denn wenn der Admin Zugriff SSL gesichert erfolgt, werden die Benutzerdaten nur noch verschlüsselt übertragen. Um dies WordPress-seitig zu aktivieren, ist in der wp-config.php lediglich die nachfolgende Zeile einzutragen:

define('FORCE_SSL_ADMIN', true);

8. Admin-Zugang doppelt schützen: wp-admin mittels htaccess schützen

Klingt dies paranoid? Ein wenig vielleicht, doch es macht Sinn ein zweites Schloss an den Administrations-Zugang zu hängen: Wir schützen das WordPress Backend noch zusätzlich über eine vorgeschaltete Passwortabfrage per htaccess. Von Tipps, WordPress per Plugin noch weiter anzusichern, halte ich persönlich wenig. Vergleichen wir es mal mit einem Einbruch in einem Haus. Durch ein sicheres Passwort und einem Administratoren-Konto, welches nicht “admin“ lautet, haben wir schon einmal eine sehr gutes Schloss an der Tür. Wenn wir nun per Plugin fehlerhafte Login-Versuche protokollieren ist das in etwa so, als ob wir im Haus selbst einen Wächter stellen. Das ist sicherlich gut, doch sinnvoller wäre es, der Wächter kontrolliert außerhalb des Hauses einen Einbruchversuch. Und hier hilft eine vorgeschaltete Passwortabfrage per htaccess. Also um beim Beispiel zu bleiben: Gitter am Fenster und der Tür …

Man liest derzeit sehr oft, dass man das „wp-admin“-Verzeichnis per htaccess schützen soll. Ich rate Euch: Macht dies so nicht! WordPress greift intern auch auf Files in diesem Ordner zu und je nach Konstellation kann es sein, dass Eure WordPress-Installation so in einen Fehler läuft. Die Lösung ist per htaccess nicht das Verzeichnis, sondern die Datei „wp-login.php“ per htaccess zu sichern. Im nachfolgenden Codefragment ist der notwenige Eintrag in der htaccess abgebildet.

<Files wp-login.php>
  AuthName "WP-Admin-Bereich"
  AuthType Basic
  AuthUserFile /euer/pfad/zur/.htpasswd
  require valid-user
</Files>

Da es immer wieder ein Thema ist – hier kurz erklärt, wie man eine htacces und htpasswd Datei anlegt:

  1. Man erstellt mit einem einfachen Texteditor (notepad.exe – NICHT Microsoft Word oder Wordpad!) eine Datei und kopiert den obigen Code hinein. Lokal abspeichern unter „htaccess“ (ohne Punkt)
  2. Um die htpasswd zu erstellen, kann man auf diesen Passwortgenerator zurückgreifen. Vergebt einen Usernamen und Passwort, klickt „create“ und ihr erhaltet eine Zeile die dieser ähnelt: „blubb:$apr1$Nj4a6My4$Isb1wtXV8AlmIl8PgfiwV.“ Vergebt bitte ein vom eigentlichen WordPress-Admin Konto abweichender User und Passwort (doppelter Passwort-Schutz). Diese Zeile wird in einer leeren Datei unter „htpasswd“ gespeichert.
  3. In der Datei „htaccess“ muss nun der Pfad zur „.htpasswd“ angepasst werden („AuthUserFile /euer/pfad/zur/.htpasswd“). Dies aus Sicht des Webservers! Hilfreich ist dieser Artikel.
  4. Beide Dateien (htpasswd und htaccess) werden nun in den Ordner „wp-admin“ geladen (ASC-II-Modus!) und jeweils umbenannt, dass die Dateien „.htaccess“ und „.htpasswd“ lauten.
  5. Nun sollte dem Aufruf „deine-Domain.de/wp-admin“ ein Passwort-Dialog vorgeschaltet sein.

9. WordPress: Generator, Versionsnummer und readme.html verstecken

WordPress › liesmich
Auch die im Root befindliche liesmich.html oder readme.html verrät die installierte Programmversion

Durch ständige sicherheitsrelevante Updates gibt es als WordPress Admin eigentlich jede Woche etwas zu erledigen. Der folgende Tipp erhöht nicht die Sicherheit, er kann jedoch nur eine Angriffsfläche minimieren. Um es deutlich zu sagen: Man kann das Folgende ausführen, darf sich dadurch nicht in falscher Sicherheit wiegen!

Wenn eine Sicherheitslücke bekannt wird und eine neue Version veröffentlich wird, gibt es zeitgleich auch genügend Bots, die speziell nach diesen abgelösten Versionen suchen.

WordPress selbst schreibt im HTML-Code (meta) die Versionsnummer der WordPress-Installation. Eine einfache Möglichkeit für einen Bot ist, diese auszulesen und bei bekannten Sicherheitslücken dann die Seite zu attackieren. Kein Schutz im eigentlichen Sinne, aber vielleicht eine Möglichkeit einem Bot die eigene Seite nicht auf dem Silbertablett zu präsentieren ist die Möglichkeit, die WordPress-Generator Angabe zu entfernen.

Hierzu muss einfach in der functions.php der nachfolgende Code hinzugefügt werden:

remove_action('wp_head', 'wp_generator');

Allerdings sollte auch die Datei liesmich.html und readme.html aus dem root entfernt werden, da hier ebenfalls die Programmversion ersichtlich ist. Da diese jedoch bei neuen WordPress Versionen erneut in das Root kopiert werden, kann ein Zugriff auf diese Dateien (wie auch auf die Datei wp-config.php aus Punkt 6) verhindert werden:

<FilesMatch "(.htaccess|.htpasswd|wp-config.php|liesmich.html|readme.html)">
order deny, 
allow deny from all 
</FilesMatch>

10. Meine vhost-Datei (Plesk > 10) für einen WordPress Blog

Auch basieren auf meinen Artikel „Ranking Faktor Page Speed“ sieht eine vhosts-Datei in meinem Fall wie nachfolgend aus. Dieser Code kann auch (mit eventuellen Anpassungen) in einer zentralen htaccess-Datei im Root einer gehosteten WordPress-Blogs eingesetzt werden:

<Directory /var/www/vhosts/DOMAIN.de/httpdocs>
Options +FollowSymLinks
Options –Indexes
php_admin_flag engine on
php_admin_flag safe_mode off
<FilesMatch "(.htaccess|.htpasswd|wp-config.php|liesmich.html|readme.html)">
Order deny,allow
deny from all
</FilesMatch>
<Files wp-login.php>
  AuthName "WP-Admin-Bereich"
  AuthType Basic
  AuthUserFile /euer/pfad/zur/.htpasswd
  require valid-user
</Files>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
AddOutputFilterByType DEFLATE font/truetype font/opentype
</IfModule>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
</Directory>

Abschließend bleibt der Hinweis, dass jeder WordPress-Admin darauf zu achten hat, dass er die WP-Installation sowie alle verwendeten Plugins stets aktuell hält. Um es wieder mit einem zu sichernden Haus zu beschreiben: Es macht keinen Sinn, die Tür optimal abzusichern, wenn ein Fenster ebenerdig stets gekippt ist ….

WordPress absichern: 10 Tipps für ein sicheres WP

Aufgeschreckt durch Meldungen bei heise.de oder spiegel.de versuchen der Tage alle WordPress-Administratoren ihr WordPress-CMS abzusichern. Aus diesem Grund möchte ich hier meinen Leitfaden veröffentlichen, den ich bei einer Neuinstallation einer WP-Instanz anwende. Ich versuche aus aktuellem Anlass auch darauf einzugehen, eine bestehende WordPress-Installation nachträglich abzusichern. Beachten Sie bitte, dass die aktuelle Problematik „wp-admin“ per htaccess abzusichern erst im Punkt 8 ausführlich erläutert wird.

1. Kein Administrator namens „admin“

Zuerst sollte jeder WP-Admin sich in WordPress einloggen und unter Benutzer die Konten prüfen. Viele Administratoren gibt es? Sind es plötzlich mehr? Wenn ja, dürfte ein Angriff bereits stattgefunden haben. Wenn nein, sind nach Möglichkeit die Anzahl der Administratoren auf ein Minimum zu reduzieren. Auch zu prüfen: Gibt es einen Administrator namens „admin“? Wenn ja, ist dieser unbedingt zu ändern! Genau darauf bau der aktuelle Angriff: Wenn bekannt ist, dass das Administrationskonto „admin“ lautet, ist dies schon die halbe Miete. Nun muss nur noch das Passwort per Brute Force ermittelt werden.
Also unbedingt den Benutzernamen des „admin“ in einen individuellen Benutzer-Namen ändern. Dass alle Passwörter auch entsprechend lang und kryptisch sein sollen, ist hoffentlich selbstverständlich.

2. Ein Administrator veröffentlicht keine Artikel. NIE!

Warum? WordPress hinterlässt bei jedem Artikel den Namen des Autors. Dies ist sehr sinnvoll aus vielerlei Gründen. Aus Sicherheitsgründen ist dies jedoch eine Katastrophe, da darüber in den meisten Fällen auch der Benutzername bekannt ist. Somit muss nur noch dem passenden Passwort gesucht werden. Hat dieser Benutzer auch noch Admin-Rechte, ist der Blog schnell in fremder Hand.

3. Die ID des Administrators ändern

Bei der Installation des Blogs wird automatisch das Administrationskonto angelegt und erhält in der Datenbank die User-ID 1. Dies ist ein weiterer Ansatzpunkt beim Hacken einer WordPress Installation. Die ID ist nachträglich mit nachfolgenden SQL-Statements änderbar:

UPDATE wp_users SET ID = '[NEUE ID]' WHERE wp_users.ID = 1;
UPDATE wp_usermeta SET user_id = '[NEUE ID]' WHERE wp_usermeta.user_id = 1;
UPDATE wp_posts SET post_author = '[NEUE ID]' WHERE wp_posts.post_author = 1;
UPDATE wp_links SET link_owner = '[NEUE ID]' WHERE wp_links.link_owner = 1;

Nachdem so die Sicherheit für das Administrations-Konto erhöht wurde, sollte man sich nun an die „wp-config.php“ machen. Diese Datei liegt gewöhnlich im Root der Installation.

4. Prüfen, ob die Sicherheitsschlüssel in der „wp-config.php“ gesetzt sind

Mit wenig Aufwand kann hier die Sicherheit ein gutes Stück erhöht werden. In den Abschnitt „Sicherheitsschlüssel“ gehören zu jedem Define-Block ein „gehörig gesalzener Key“. WordPress macht es sehr einfach. Der Aufruf unter https://api.wordpress.org/secret-key/1.1/salt/ über den Browser erlaubt die Generierung der Keys. Diese Ausgabe im Broser kann einfach via Copy & Paste in die wp-config.php übernommen (bzw. überschieben) werden.

define('AUTH_KEY', '%Sc#(H|Zo5p+wn=>i.yM*!k%w8[zh9K{d5-v2>`:^>M%B:(tr{2;VkGMxTE+NFD)');
define('SECURE_AUTH_KEY', 'ZXsorW!Z_6qi/PC^tDUUftZo*sQ6Ej!MzW9,Ze3z6>W?H+G}*$<iddH/a#Z7+&EO');
define('LOGGED_IN_KEY', 's@X$cZ(*.wCI1tU.Lw$|Ion<Os5+~^F<u,+zo,!|}u#n e6+aJG|dn/u!x`;8k,k');
define('NONCE_KEY', 'aM3~ZibX) Jz4IB+RW%m4M4cY*LHtOwN|Z1kQ/-GVyWOD. RD,n<>:,_GF)A`p:>');
define('AUTH_SALT', ']-tLB^g{c$+NL$%=Npsn,-P~t%9jH0h-t-e-A=-m@!Wh7y-6f1D|;LvU5qG');
define('SECURE_AUTH_SALT', '4p mo_GfknF1>zk$PY[_V_e#f9@![wsE9?head7ZJkMJ..^]S|fZ6+3Zw+ZoV/bq');
define('LOGGED_IN_SALT', 'ACKwio1l@N8P#H|T:$NC-9- 6;geaT2CPp+b[acWxI;Gona}eKl2w5wZZ2KA5I;B');
define('NONCE_SALT', 'Gbl4l,Eu%;|F4/9EMq7%$D-xzuNuc[[+Xn.#dk#|CR:6iu*l{7B62Mzq17!vPO8T');

 

5. Datenbank-Präfix ändern

Immer wieder ist zu lesen, dass dies die Sicherheit extrem erhöhen sollte. Ich persönlich habe den Fokus auf andere Punkte. Doch wenn ein neuer Blog angelegt wird, schadet es auf keinen Fall, die Variable $table_prefix = ‚wp_‘; in der wp-config.php beispielsweise in ‚wp3h3r6_’ zu ändern. Warum das ganze? Wenn das Datenbank-Prefix „wp_“ nicht geändert wird, ist bekannt, wie die Tabellen in der MySQL-Datenbank lauten. Somit kann speziell nach diesen Tabellen gesucht werden bzw. Datenbank-Sicherheitslücken, die nur beschränkten Zugriff auf eine Datenbank erlauben, sind gegebenenfalls von größerer Gefahr.

Wer nachträglich die Datenbanknamen ändern möchte, kann dies in der wp-config.php erledigen und muss dann zusätzlich auf der Datenbank die Tabellen umbenennen (alle!)

-- Beispiel für die Tabelle wp_posts. Beispiel-Prefix: ‚wpSic#er_’
RENAME TABLE wp_posts to wpSic#er_posts;

Hier geht es weiter zu den Tipps 6 – 10 >>

Gimp: Bild als Comic oder Strichzeichnung konvertieren

Gimp: Bild als Comic

Diese Schritte führen nicht bei jedem Portrait zu einem guten Ergebnis. Auch die Parameter müssen je nach Vorlage ausprobiert werden.

Gimp Bild als Comic
Wir starten mit diesem Bild und möchten einen Comic-Effekt erhalten

Schritt 1: Wir beginnen mit dem Gaußschen Weichzeichner. Dieser ist in Gimp unter „Filter – Weichzeichnen – Selektiver Gaußscher Weichzeichner“ zu finden. Dort wählen wir als Weichzeichenradius den Wert „20“ und als „Max. Delta“ den Wert „60“ aus (Bild 1).
Achtung: Je nach Portrait bzw. Bild muss hier schon experimentiert werden. Ziel ist es eine Einstellung zu finden, die das Bild von Details befreit, ohne es zu entstellen.

Schritt 2: Nun verwenden wir den Gimp-eigenen Filter „Cartoon“. Dieser ist unter „Filter – Künstlerisch – Cartoon“ zu finden. In unserem Beispiel wähle ich als Maskenradius „50“. Den Schwarzanteil lasse ich auf „0“. Bei anderen Portraits ist „0,7“ oft ein guter Wert.

Schritt 3: Nun möchte ich dem Bild noch Farben entziehen. Dazu wähle ich das Menü „Farben – Posterisieren“. Bei diesem Bild sind die Ergebnisse mit weniger Farben nicht optimal. Ich reduziere die Farben lediglich auf den Wert „30“. Bei vielen Bildern habe kann der Wert „2“ durchaus gute Ergebnisse liefern. In meinem Beispiel erhält auch der Hintergrund Farb-Morees. Da ich das Bild im Anschluss sowieso beschneiden möchte, ist dies kein Hindernis.

Gimp Cartoon Filter
Der Gimp Cartoon Filter liefert ein interessantes Ergebnis

Schritt 4: Nach dem Entziehen der Farben kann nun noch die Farbsättigung angepasst werden. Unter „Farben – Farbton/Sättigung“ kann der Wert „Sättigung“ beeinflusst werden. Meist muss dieser erhöht werden (Wert „100“). In meinem Beispiel habe ich den Wert jedoch auf „-60“ reduziert.

Sieht das Bild nun wie ein Cartoon aus? Nun, leider nicht wirklich. Je nach Vorlage führen diese Schritte durchaus zu einem optimalen Ergebnis. Aber zu einem Erfolg haben diese Schritte durchaus geführt: Das Ergebnis gefällt mir deutlich besser, also das Original.

Gimp: Portrait als Strich-Zeichnung

Strichzeichnung in Gimp
Strichzeichnung in Gimp: Farben entziehen

Um ein Bild in eine Bleistift-Zeichnung umzuwandeln, bedarf es ebenfalls nicht vieler Schritte. Hier ist zu beachten, dass der Hintergrund möglichst neutral sein sollte. Je nach Motiv ist es ratsam, das Bild zuerst freizustellen..

Schritt 1:  Zuerst wird die Ebene dupliziert (rechte Maustaste im Fenster „Ebenen“, „Ebene duplizieren“).

Schritt 2: Nun wird die duplizierte Ebene entfärbt. Unter „Farben – Farbton/Sättigung“ wird die Sättigung auf „-100“ eingestellt.

Schritt 3: Nun wird auch diese Ebene noch einmal dupliziert dupliziert (rechte Maustaste im Fenster „Ebenen“, „Ebene duplizieren“). Wir haben nun drei Ebenen unseres Bildes.

Schritt 4: Nun kommt der „Filter – Weichzeichnen – Gaußschwer Weichzeichner“ zum Einsatz. In meinem Beispiel habe ich den Wert „5“ gewählt.

Schritt 5: Da wir eine invertierte Ebene benötigen, wählen wir nun „Farben – Invertieren“

Schritt 6: Der invertieren Ebene wird nun eine Deckkraft von „50“ Prozent zugewiesen (siehe Bild) Nun haben wir ein graues Bild mit schwach erkennbaren Kanten und Konturen.

Schritt 7: Nun wird diese Ebene mit der darunterliegenden Ebene vereint. Im Fenster „Ebenen“ wird die oberste dritte Ebene ausgewählt. Rechte Maustaste – „Nach unten vereinen“

Gimp Ebene abwedeln
Ebene abwedeln

Schritt 8: Weil wir Ebenen noch nicht genug dupliziert haben, führen wir diesen Schritt mit unserer obersten Ebene erneut durch. Den Ebenenmodus der soeben duplizierten Ebene stellen wir auf „Abwedeln“.

Je nach Vorlage kann die Arbeit hier bereits enden. Wenn wir die Linien noch verstärken möchten, gehen wir wie folgt vor:

Schritt 9: Es werden nun die zwei obersten grauen Ebenen zu einer vereint („Nach unten duplizieren“) und danach die vereinte Ebene wieder dupliziert. Der Ebenenmodus der soeben duplizieren Ebene stellen wir auf „Multiplikation“

Schritt 10: Weitere Experimente gefällig? Mit jeder Duplikation der Ebene (Modus „Multiplikation“) verstärkt sich der Effekt.

C#: Wie man eine Grafik in eine Resource hinzufügt

In Windows-Form Anwendungen kommt man öfters in die Verlegenheit, irgendwelche Bilder, Icons oder Logos anzuzeigen. Auch in Tabellen oder in einem DataGridView können kleinen Grafiken die Lesbarkeit stark erhöhen. Die Grafiken der eigentlichen Exe beizulegen mag seine Vorteile haben, doch oftmals ist es besser, diese in der ausführbaren Datei zu inkludieren und aus dem Speicher abzurufen. Wie man eine Datei als Resource in Visual Studio bereitstellt, beschreibe ich hier.

Zuerst muss man zum Resourcen-Fenster navigieren. Ein Weg, dorthin zu gelangen, ist ein Rechtsklick im Projektmappen-Explorer auf die Applikation, dann „Eigenschaften“ wählen. Im sich öffnenden Fenster sieht man nun einige Tab-Reiter. Man wählt hier den Tab Reiter „Ressourcen“. Die Schaltfläche „Ressource hinzufügen“ ist eigentlich selbsterklärend. Man wählt die passende Eigenschaft (oder wählt „vorhandene Datei hinzufügen“), vergibt dem Bild bzw. der Ressource einen eindeutigen Namen. Wenn man eine Datei direkt hinzufügt, sollte man je nach Namenskonvention diesen noch anpassen.

Die Grafik Resource in C# ansprechen
Nun haben wir also eine Grafik als Resource hinzugefügt. Nun möchten wir diese auch im Programmcode verwenden. Dies ist in C# nun sehr einfach, denn wir verwenden die statische Klasse „Properties.Resources“. Diese Klasse gewährt uns Zugriff auf die eingebettete Resource.
Im nachfolgenden Beispiel verwenden wir eine PictureBox um eine Grafik anzuzeigen. Eine Grafik „link.jpg“ habe ich als Resource mit dem Namen „link“ hinzugefügt. Der Zugriff auf die Grafik ist nun per „Properties.Resources.link“ möglich:

/// <summary>
/// Wir zeigen eine Grafik in einer PictureBox an
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void Form1_Load(object sender, EventArgs e)
{
            //Eingebette Resource: link.jpg. Resourcen-Name: link
            pictureBox1.Image = Properties.Resources.link;
}
grafik in datagrid
Einbettung eines Image

In Anlehnung an mein Beispiel im Artikel „C# Images in DataGridView anzeigen” greife ich im untenstehenden Beispiel direkt auf die Resource hinzu und spare mir dem Umweg, das Image erst noch explizit zuzuweisen. Wer nicht den direkten Weg über die Properies.Resource gehen möchte, kann den von Microsoft hier beschriebenen Weg über einen Stream gehen.

DataGridViewImageColumn dgv_pic = new DataGridViewImageColumn(false);
DataGridViewColumn dgv_text = new DataGridViewTextBoxColumn();

//Füge die Colums hinzu
dataGridView1.Columns.Add(dgv_pic);
dataGridView1.Columns.Add(dgv_text);

//Hier werden manuell zwei Rows hinzugefügt
dataGridView1.Rows.Add(2);

dataGridView1[0, 0].Value = Properties.Resources.lampe_rot; // (Image)lampe_rot;
dataGridView1[0, 1].Value = Properties.Resources.lampe_gruen; //(Image)lampe_gruen;
dataGridView1[1, 0].Value = "Server A";
dataGridView1[1, 1].Value = "Server B";

Vorteil einer eingebettenen Resource
Der größte Vorteil ist natürlich, dass die Ressource, beispielsweise eine Grafik oder ein Icon nach dem Release in der Exe enthalten ist. Man muss sich keine weitere Gedanken mehr über die Grafik machen und man kann sicher sein, dass die Anwendung auch auf das Bild zugreifen kann. Aber auch der Nachteil liegt klar auf der Hand: Jedes so integrierte Bild vergößert die Exe. Es dürfte also wenig Sinn machen, große Images so zu integrieren. Kleine Status-Bilder oder Icon-Sets können aber so elegant integriert werden.

Moot: Kommentar-Funktion auf sirmark.de

Ich habe es auf die lange Bank geschoben: Nun möchte ich eine Kommentarfunktion auch auf sirmark.de anbieten. Der Bedarf für eine solche Funktion liegt auf der Hand: Es erreichen mich immer wieder Fragen per Mail zu den einzelnen Artikeln. Diese könnten – für alle nachvollziehbar – auch in den Kommentaren abwickeln lassen. Aber auch aus SEO-Sicht bietet die Kommentarfunktion Vorteile: Der Seiten-Content wird mit jedem Kommentar erweitert und mit weiteren – hoffentlich – suchmaschinenrelevanten Stichwörtern angereichert.
Nachteil: Es ist Arbeit, die Kommentare zu sichten, zu beantworten und vor allem auch den Spam auszumisten.

Übersicht behalten: Wie den Kommentar-Spam bekämpfen
Dieser Blog läuft unter WordPress, dem Platzhirsch der CMS. Seine Kommentarfunktion ist per se gut. Doch wer nur ein paar Tage einen Blog mit offener Kommentarfunktion online hatte weiß, was sich da so alles ansammelt: Von PPC-Kommentaren („Porn, Pills, Casino“) über anderweitigen Schrott. Diesen auszufiltern ist nicht schwer. Schon beim groben Sichten können diese Kommentare zuverlässig entfernt werden. Bei manchen Kommentaren fragt man sich, warum hier einer (eine Maschine) diesen Kommentar gepostet hat, denn der Kommentar verfügt über keinen Backlink. Wer mal die Scrapebox-Anleitung gelesen hat, weiß warum. Schritt 1 des automatisierten Comment-Spammers ist ein sinnloser Kommentar ohne Bezug zum eigentlichen Projekt, für das gespammt werden soll. Wenn dieser Kommentar bei einer Prüfung in den folgenden Tagen online erscheint, wird der eigentliche Spam-Kommentar in Schritt 2 gepostet. So wird die eigentliche Seite nicht „verbrannt“.

Schon eine gute Lösung: Captcha
Prinzipiell ist ein Captcha, also ein in eine Grafik eingebundene Textnachricht keine Hürde. Diverse Dienste, über die ich auch schon berichtet habe (Bookmark richtig setzen), knacken den Captcha-Code binnen Sekunden für einen lächerlich niedrigen Preis. So gesehen bietet ein Captcha für das Veröffentlichen eines Kommentars keine 100prozentige Lösung. Auf diversen anderen Seiten habe ich das WordPress-Plugin „SI CAPTCHA Anti-Spam“ eingesetzt. Und man glaubt es kaum: Das Spam-Aufkommen geht merklich zurück, die Qualität der Kommentare steigt. Wir lernen daraus, dass Kommentar-Spammer sehr geizig sind und der Captcha Code durchaus das Spam-Aufkommen reduziert. Umgekehrt, gebe ich als Kommentator einer Seite eher den Vorzug, wenn ein solches Captcha vorhanden ist. Weiß ich im Gegenzug, dass der Webmaster dadurch das Spam-Aufkommen reduziert und es eher unwahrscheinlich ist, dass mein Kommentar in den Unmengen des PPC-Spams untergeht.

Kommentare auf sirmark.de
Trotz dieser positiven Erfahrungen habe ich auf dieser Seite die WordPress-Kommentar-Funktion nicht freigeschaltet. Faulheit? Ja. Ein Artikel auf t3n.de hat heute mein Interesse geweckt. Dort wird über Mott, einer Diskussions- und Forenplattform berichtet, die sich leider erst in einem Beta-Stadium befindet. Die Beschreibung liest sich sehr gut. Auch der Hinweis, dass hinter diesem Projekt die Macher von JQuery stecken, verstärkt mein Interesse.

Warum Moot.it und nicht die WordPress Kommentar-Funktion?
Auf diese Frage kann ich heute noch keine Antwort geben. Ich selbst sehe sirmark.de immer gerne als Testsystem. Hier probiere ich gerne mal ein neues Plugin aus. Vor der Kommentarfunktion habe ich mich hier ein wenig „gedrückt“. Moot.it liest sich sehr gut. Es soll sehr schnell sein, leicht zu installieren und in der Administration ebenfalls nicht zeitraubend sein. Also werde ich es testen und Euch über meine Erfahrungen unterrichten.
Etwas ist leider jetzt schon klar: Der Content wird sicherlich nicht um Keys erweitert. Denn Moot läd die Kommentare per JavaScript nach. Und man muss davon ausgehen, dass dies von den Suchmaschinen nicht ausgewertet wird. Oder etwa doch? Ich werde es hier testen. Oder wisst Ihr schon die Antwort? Dann hinterlasst doch einen Kommentar …

HowTo: WordPress auf hohen PageSpeed optimieren – Teil 3

Im einleitenden Artikel und in den beiden vorangegangenen Artikel haben wir uns bereits über die Möglichkeiten ausgelassen, einen WordPress Blog in der Geschwindigkeit zu optimieren. Google legt uns nahe, auf die Geschwindigkeit Wert zu legen. Dieser nicht zu unterschätzende Fingerzeig soll heißen, dass eine Seite noch so guten und einzigartigen Inhalt haben kann – wenn die Seite langsam im Aufbau ist, verärgert dies den Leser und Google straft die Seite ab. Grund genug also, die Hinweise der Mutter aller Suchmaschinen nicht auf die leichte Schulter zu nehmen.

JavaScript später parsen
Man war es gewohnt, im Header einer Seite auch alle JavaScript-Blöcke zu definieren. Inzwischen geht man dazu über, die nachzuladenden JavaScript -Dateien erst am Ende der HTML-Seite einzubinden. Man erhöht dadurch zwar nicht die Ladezeit, doch die Darstellung der HTML-Seite erfolgt schneller. Denn erst zum Schluss werden die meist für die Bedienung benötigten JS-Dateien geladen. Wenn man eine Seite selbst erstellt, sollte man dies heute beachten. Bei WordPress bedeutet dies wieder einen tiefen Eingriff und die Gefährdung des Updates. Gerade Plugins binden gerne ihr JavaScript im Header ein. Nur wenig neuere Plugins haben diesen Modus umgestellt. Wer möchte, kann in ein solches Plugin eingreifen.

mod_rewrite.c: Der WordPress-Klassiker zur Definition der Permalinks. Das Mod_rewrite-Modul schreibt online eine lesbare URL („domain.de/kategorie/mein-artikel“) in die von WordPress verwendete interne Struktur um.
ACHTUNG: Den genauen Syntax innerhalb dieses Blockes an die eigene Permalink-Struktur anpassen. WordPress selbst gibt unter den Einstellungen die Struktur vor.

Anfragezeichenfolgen aus statischen Ressourcen entfernen
Google mag es gar nicht, wenn man beispielsweise einer CSS-Datei einen Parameter übergibt. Was das soll? Beispielsweise das WordPress-Plugin Rating Star erstellt das auszuliefernde CSS per PHP-Code. Dies kann Sinn machen, denn dann wird nur der Teil des Codes ausgeliefert, der auch für den Client notwendig ist. Doch Google findet einen Aufruf wie „rating.css?KEY“ wenig schick. Lösung? Aufgrund der getroffenen Konfiguration des Plugins könnte man – wie von Google gewünscht – ein statisches CSS erstellen und veröffentlichen. Problem: Bei jedem Plugin-Update muss ich den neuen Output untersuchen und ggfls. nachbessern.

Da ich seit Monaten auf ein Update des Plugins warte, habe ich den schnellen Weg gewählt: Ich habe die entsprechende PHP Datei geöffnet und den CSS-Teil optimiert (Kompressor). Somit habe ich die Ladezeit schon „ein wenig“ optimiert und lebe weiterhin mit dem „Low priority“-Makel.

Zeichensatz angeben
Zu Recht eine „Low Priority“, doch schnell erledigt. Im Header der HTML-Seite einfach den Meta-Aufruf korrekt einfügen.

Ich hoffe ich konnte hier einige Anregungen und Tipps für die Optimierung geben. Wie ich mehrfach erwähnt habe, folge ich nicht jeder Empfehlung von Google in Sachen PageSpeed. Gerade im Bereich der „Low priority“-Meldungen wäge ich zwischen Aufwand und Nutzen ab. „Rote“ und „gelbe“ Meldungen sind jedoch auf jeden Fall wert, im Sinne der Empfehlung von Google umzusetzen.

HowTo: WordPress auf hohen PageSpeed optimieren – Teil 2

Nachdem wir uns bereits um die optimale Bildergröße gekümmert und den HTML und CSS Code per Kompressor verkleinert haben (HowTo: WordPress auf hohen PageSpeed optimieren – Teil 1), kommen wir nun noch zu weiteren Punkten, die wir verbessern können:

„Browser Caching nutzen“, Dateien online komprimieren
Die folgenden Änderungen können in einer htaccess-Datei vorgenommen werden. Bei Hosting-Paketen ist dies meistens auch die einzige Möglichkeit. Wer einen eigenen (V) Server hat, sollte die Änderungen direkt in der vhost-Datei vornehmen.

Warum? Nun, die htaccess-Datei wird bei jedem Aufruf einer Datei gelesen. Egal ob die Index-Seite, den eingebetteten Bildern, JavaScript und CSS-Dateien. Also alleine für eine Startseite gut und gerne fünf bis zehn Aufrufe. Wenn die Änderung zentral in der vhost vorgenommen werden, wird dies nur beim Start des Apache einmalig gelesen.

Hinweis für Plesk: Bei meinen Plesk-Servern ist das Apache Modul „mod_expires“ nicht aktiviert. Dies kann jedoch über die Plesk-Oberfläche erledigt werden. Aber auch der klassische Weg, das Modul über Apache zu aktivieren, ist möglich.

# BEGIN WordPress

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
</IfModule>

<IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
 AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
 AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
 AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
 AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
 AddOutputFilterByType DEFLATE font/truetype font/opentype
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Was macht unser Code? Der Code besteht aus drei Blöcken, die jeweils das Vorhandensein eines bestimmten Apache-Modules (<IfModule) prüfen. Wenn das Modul vorhanden ist, wird der Code innerhalb der IF-Tags ausgeführt. Fehler im Code quittiert der Apache mit einem Fehler 500.

mod_expires.c: Wir aktivieren dieses Modul und weisen den Apache an, bestimmten Dateitypen wie Grafiken, JS oder CSS-Dateien ein bestimmtes Ablaufdatum im Header mitzusenden. Somit kann der aufzurufende Browser die Datei cachen und läd sie nicht immer erneut vom Webserver. Dies spart sehr viel Bandbreite, wenn immer wiederkehrende Bilder oder eine zentrale CSS-Datei nicht bei jedem Blättern einer Seite erneut geladen wird.

mod_deflate.c: Obwohl wir unseren HTML und CSS Code bereits über einen Kompressor optimiert haben, weisen wir nun den Apache an, die definierten Dateien per gzip online zu komprimieren und so verkleinert an den Browser zu senden. Was aufwändig klingt, zeigt sich in der Praxis als gängig und optimal. Die Zeit, die der Server für die Komprimierung und der Ziel-Browser für das Entpacken benötigt, ist durch den geringeren Datenaustausch von Server zum Client gut angelegt. Auch kommen heute alle gängigen Browser mit einer solch online optimierten Übertragung zu Recht. In unserer Definition werden nur Textdateien (HTML, CSS etc) und keine Bilder komprimiert.

Im dritten und letzten Teil unserer kurzen Artikelserie über PageSpeed gehen wir auf JavaScript, den Zeichensatz und Mod_rewrite ein.

HowTo: WordPress auf hohen PageSpeed optimieren – Teil 1

Im einleitenden Artikel „Ranking Faktor Page Speed: WordPress optimieren“ dieser kleinen Artikel-Reihe bin ich auf die Gründe, warum man seine Webseite auf Geschwindigkeit optimieren sollte, bereits eingegangen. Hier beschäftigen wir uns nun mit den gängigen Vorschlägen von Google für einen schnelleren WordPress Blog.

404-Fehler: Wenn eine Webseite auf eine Grafik verweist, die nicht vorhanden ist, schickt der Webserver einen Fehler „404“ zurück. Die ist unnötig und bremst die Seite aus. Zumeist sind solche „Leichen“ in der CSS-Datei (style.css) verborgen. Also: Analysieren und entweder den Aufruf entfernen oder die Datei (Image) korrekt zur Verfügung stellen.

GIF-Bilder: Google kritisiert sehr gerne GIFs, die auf der Webseite bzw. in der Theme verwendet werden. Hier erreicht man sehr schnell Abhilfe, indem man das GIF mittels der freien Grafiksoftware „Gimp“ öffnet und als PNG (Kompression 9) exportiert. Diese PNG-Datei dann in den HTML-Code oder CSS-Datei einbinden.

HTML, CSS und JS-Dateien optimieren: Ziel ist es, den nachzuladenden Code so kurz wie möglich bereit zu stellen. Kommentare im Code, so sinnvoll sie für Änderungen sind, sind unnötiger Ballast bei der Übertragung zum Besucher. Auch Einrückungen in HTML oder CSS erhöhen die Lesbarkeit, sind aber unnötig. Also wird man zwei Versionen dieser Dateien benötigen. Die lesbare Ur-Version und eine auf dem produktiven Server zur Auslieferung bereitstehenden optimierten Code.
Zur Optimierung gibt es diverse CSS und HTML online Kompressoren. Für alle gilt: Immer die Original-Version zuerst sichern! Den optimierten Code im Web einsetzen und testen. Hier muss man probieren und experimentieren.
Tipp: Oftmals gibt es Probleme mit WordPress-Dateien, die HTML und PHP-Code beinhalten. Kommentare im PHP-Block bereiten je nach Kompressor hier Probleme. Meist entferne ich zuerst diese Kommentare per Hand und nutze dann einen Kompressor. Je nach Datei optimiere ich auch nur den HTML-Code und lasse den PHP-Block unverändert.

  1. YUI Compressor: JS und CSS Kompressor
  2. HTML Compress: HTML Kompressor

Bilder optimieren, skalierte Version bereitstellen
Viele Punkte Abzug in Rechung stellt Google, wenn man zu große Bilder auf einer Webseite einfügt und diese mittels „width“ und „height“-Tag herunterskaliert. Google hat schon Recht: Es ist unnötige Ressourcenverschwendung. Beispielsweise stellen wir im Artikel „WordPress: Recent Post (Letzte Artikel) mit Thumbnail-Images in der Sidebar anzeigen“ per WordPress eine Sidebar mit Thumbs zur Verfügung. Hier nutzen wir 150px große Bilder. Im Code reduzieren wir die Anzeige auf 70px. Ein böses Foul und Google moniert dies mit einer roten Karte.

Wie man individuelle WordPress-Bildgrößen (automatische Erstellung) generiert, zeige ich in einem weiteren Artikel. Auch sei erwähnt, dass Google die Kompression von JPGs mittels WordPress anmäkelt. Laut Google kann die Kompression noch weiter erhöht werden. Da ich mit 96 Punkten PageSpeed zufrieden bin, ignoriere ich diese „Low priority“-Meldung.

Wichtig auch: WordPress bietet beim Einbinden eines Bildes an, eine vorliegende Bildgröße herunterzurechnen. Dies mit Bedacht wählen. Besser: Die endgültige Größe des einzubindenden Bildes optimal komprimiert via WordPress hoch laden und einbinden. Zuvor das optimale Grafikformat PNG/JPG für Grafiken/Bilder wählen.

Zum Teil 2: HowTo: WordPress auf hohen PageSpeed optimieren – Teil 2

Ranking Faktor Page Speed: WordPress optimieren

Um eine Webseite oder ein Blog optimal für die Suchmaschinen zur Verfügung zu stellen, verwenden wir viel Zeit. Die Texte werden optimiert, der Aufbau der Seite wird entsprechend angepasst und irgendwann (und nicht allzu spät) sollte man sich mit dem Thema „Page Speed“ beschäftigen.
Google (Slogan: „Make the Web faster!“) selbst sagt, dass die Geschwindigkeit einer Webseite ein wichtiger Ranking-Faktor ist. Dass die Zufriedenheit eines Besuchers mit einer Website nicht nur mit dem Inhalt und dem Design, sondern auch mit der Ladezeit zusammenhängt, sollte jedem Surfer bekannt sein. Wer hat schon Geduld, Sekunden um Sekunden zu warten, bis sich eine Webseite aufgebaut hat? Der Onlinehändler Amazon hat nach eigenen Angaben eine Untersuchung durchgeführt die besagt, dass mit jeder Sekunde, die eine Webseite länger zum Aufbau benötigt, 10 Prozent Umsatz weg brechen. Zehn Prozent Umsatz bei Amazon: Das dürfte den einen oder anderen Webmaster animieren, seine Webseite auf die Ladezeit hin zu optimieren.

Aber auch mehr Besucher von Google sollte ein Anreiz sein, den Page Speed seiner Webseite zu kontrollieren und wenn nötig die Seite anzupassen. Google stellt hierfür im Developers Bereich eine Seite bereit, über die man seine Webseite online prüfen kann. Google vergibt bis zu 100 Punkte für den Speed der Seite. Ziel ist also, den Page Speed an 100 anzunähern. Ob wirklich 100 erreicht werden müssen, sei dahingestellt. Viele Webmaster können auch mit einem Page Speed im Bereich 80 bis 90 Punkte gut schlafen. Für viele Seiten habe ich ohne großen Aufwand 96 Punkte erreicht. Die Optimierung um vier Punkte auf 100 habe ich bewusst gelassen. Wer mit seiner Webseite eine Page Speed von unter 80 oder gar unter 70 Punkten hat, sollte auf jeden Fall die Vorschläge von Google angehen.

Webseite oder WordPress-Blog auf Page Speed testen
Nun ist es also endlich an der Zeit, die eigene Webseite einem ersten Speed-Test zu unterziehen. Über das Google Tool PageSpeed wird nach Eingabe der URL die Seite getestet. Neben dem Score (Punkte) erfährt man in den Kategorien „High priority“ (rot), „Medium priority“ (gelb) und „Low priority“, welche Vorschläge Google zur Optimierung vorschlägt. Ziel ist es meiner Meinung nach auf jeden Fall, die Punkte „Rot“ und „Gelb“ abzuarbeiten. Unter den Punkten „Low priority“ und „Experimental rules“ wird es – gerade bei WordPress Blogs – schwer, alle Vorschläge von Google zu befolgen. Hier wären zum Teil tiefe Eingriffe in WordPress Plugins notwendig, die ein Update desselben dann wieder unnötig erschweren. Da viele Updates aus Sicherheitsgründen schnell und unkompliziert eingespielt werden sollen, muss man abwägen, ob einem diese Hürde der „letzte Punkt zum PageSpeed von 100“ wert ist.

Page Speed: Dieser Blog
Diesen Blog sehe ich nicht als Referenz für den PageSpeed an. Bei Speed Test erreichte er 82 von 100 Punkten, ohne eine Anpassung. Die Mängelliste von Google ist lang und zu gegebener Zeit werde ich auch hier die Optimierung angehen.

Hier geht es weiter: In der kurzen Artikel-Serie „HowTo: WordPress auf hohen PageSpeed optimieren – Teil 1“ beschreibe ich die gängigen Änderungen für einen besseren PageSpeed

WordPress: Recent Post (Letzte Artikel) mit Thumbnail-Images in der Sidebar anzeigen

Neben der Anzeige von „ähnlichen Artikeln“ geniest die Anzeige der „Neuste Artikel“ in WordPress eine wichtige Bedeutung. Neben den Suchmaschinen, die auf eine interne Verlinkung achten, kann man auch Besucher für weitere Artikel gewinnen, die einmal auf die Seite gelangt, sich nun auch noch über ein anderes Thema informieren. Schon im Standard bietet WordPress das Widget „Neuste Artikel“ (Recent Post), wie es auch dieser Blog einsetzt. In der Sidebar sieht der Leser eine bestimmte Menge an Artikel, die in jüngster Vergangenheit geschrieben wurden.

Seit der Diskussion um das Star Rating und den Autor-Vorschaubildern in den Google-Suchergebnissen wissen wir, dass ein Bild „mehr sagt als tausend Worte“. Der Wunsch liegt auf der Hand: Das WordPress-Widget „Neuste Artikel“ soll mit Vorschau-Bildern (Thumbs) angereichert werden. Ein einfacher Wunsch – leider keine Standard Lösung.

Lösung 1: Das WordPress Plugin „Special Recent Posts“

Das WordPress Plugin Special Recent Posts
Das WordPress Plugin „Special Recent Posts“ bietet einen Vorschautext samt Image in der WordPress Sidebar auf die neusten Artikel

Was liegt näher, als unter WordPress das 1001 Plugin zu installieren? Bei der Suche nach einem Plugin, welches einem administrative Freiheiten bei der Definition der „Neusten Artikel“ in der Sidebar ermöglicht, stößt man auf das WordPress Plugin „Special Recent Posts“. Dieses Plugin ermöglicht eine Anzeige eines Images zum Artikel. Bei meiner Suche habe ich leider kein weiteres Plugin gefunden, die dies in vernünftiger Form ermöglicht. Um es aber auch gleich vorweg zu nehmen: Zu 100 Prozent war bzw. bin ich nicht zufrieden mit diesem Plugin.
Aber zurück zum Plugin: Die Installation ist problemlos. In den Optionen erreicht man eine Konfigurationsseite des WordPress-Plugins, die sicherlich aber in den meisten Fällen unverändert übernommen werden kann. Interessant wird es erst in den Design-Widgets. Dort findet man nach der Installation des Plugins unter „Verfügbare Widgets“ das Plugin. Anklicken, in die Sidebar ziehen und schon ist das Plugin aktiviert. Doch halt: Zuerst sollten weitere Einstellungen unter den Widgets / Sidebar vorgenommen werden. Hier ist neben dem „Widget Title“, die „Max Number of Pages to Display“ und einige andere Dinge einzustellen. Ein besonderes Augenmerk sollte auf die „Thumbnail Options“ fallen: Hier kann einiges über das Aussehen der Images festgelegt werden.
Positiv beeindruckt hat mich das Caching der Images. Die Thumbs werden einmal generiert und in einem Cache-Verzeichnis gespeichert. In der Regel sind die Thumbs ja nur 50 bis  vielleicht 80 Pixel groß. Das Original-Image aus dem Artikel liegt meist in wesentlich größeren Dimensionen auf der Festplatte. Nachteil: Das Cache-Verzeichnis benötigt weitreichende Schreibrechte. Mehr als mir lieb ist.

Wer schnell seine Sitebar mit Images aus den jeweiligen Artikeln anreichern möchte, kann das WordPress Plugin „Special Recent Posts“ nutzen. Ebenso schnell, wie es installiert ist, kann man dieses Plugin auch wieder löschen.

Was mich am Plugin „Special Recent Posts“ gestört hat:

  • Weitreichende Schreibrechte für den Cache-Ordner von Nöten
  • Design der Anzeige nur über tiefgründige Änderungen in der Plugin-CSS und den
  • PHP-Dateien möglich, was ein Plugin-Update „erschwert“
  • Inkompatibilitäten bei manchen Themes
  • Vorschautext des Artikels zeichenbegrenzt

Lösung 2: Sidebar Widget „Neuste Artikel“ mit Thumbnail-Images ohne Plugin

Wordpress Sidebar Widget Neuste Artikel mit Thumbnail-Images ohne Plugin
Im Eigenbau: WordPress Sidebar Widget „Neuste Artikel“ mit Thumbnail-Images ohne Plugin

Nachdem ich massive Änderungen am Design für eine WordPress Installation vorgenommen habe, die ein zukünftiges Plugin-Update nicht vereinfacht, machte ich mir Gedanken über Alternativen. Es störte mich weiter, dass der Vorschautext eines Artikels nicht individuell bestimmbar, sondern zeichenbegrenzt ist. Dies bedeutet, dass die Vorschau nach x-Zeichen endet, egal ob ein Wort zu Ende ist, oder nicht. Neben diesem unschönen Verhalten hat das Plugin mit einer weiteren von mir eingesetzten Theme unschöne Design-Inkompatibilitäten gezeigt, so dass ich dazu überging, Thumbs in der Sidebar ohne Plugin-Hilfe anzuzeigen.

Grundsätzliche Überlegungen zu Images in der Sidebar bei den letzten Artikeln:

  • Jedem Artikel ist ein Image als Artikelbild zugeordnet. Dies soll auch im Widget „Recent Posts“ angezeigt werden.
  • Wir benötigen eine „Kurzbeschreibung“ zu jedem Artikel. Ein oder zwei Sätze sollen neben dem Artikel-Titel eine Vorschau geben.

Artikelbild den „Neusten Artikel“ zuordnen
Zu aller erst muss ein Artikelbild jedem Artikel zugeordnet werden. Dies ist  Bestandteil von WordPress und im Artikel „WordPress: Artikelbild (Vorschaubild) einfügen“ ausführlich beschrieben. Wer bei der Erstellung eines WordPress-Artikels den Kasten „Artikelbild“ nicht zu Gesicht bekommt, der muss die functions.php seiner Theme ändern. Informationen dazu siehe das Update im eben beschriebenen Artikel.

Somit haben wir nun das notwendige Image zum Artikel. WordPress legt das Image in der Dimension 150×150 Pixel ab. Diese Größe werden wir zur Anzeige unseres Thumbs nicht benötigen. Doch die verkleinerte Anzeige eines Images auf rund 60 bis 80 Pixel ist bei einem Original-Image von 150 Pixel vertretbar. Bei 300, 400 oder gar mehr Pixel, wäre dies eine deutliche Traffic-Verschwendung.

Kommen wir nun zum Vorschautext. Dieser soll kurz und prägnant sein, Lust zum Weiterlesen machen. Beim zuvor beschriebenen Plugin hat mich gestört, dass der Text nach einer bestimmten Anzahl von Zeichen einfach angeschnitten wurde. Eine Kurzbeschreibung bietet WordPress als Feld nicht an. Da die meisten WordPress-Nutzer auch das Plugin „All in one SEO“ nutzen, hätte man auch das Feld „Description“ nutzen können. Wer möchte, kann die folgende Lösung so umschreiben. Ich nutze hier ein eigenes „Benutzerdefiniertes Feld“ namens „kurzbeschreibung“. Vorteil: Ich kann hier speziell für diesen Zweck meinen Vorschausatz definieren.

Was wir nun also vornehmen müssen sind Änderungen in der Theme. Kritiker mögen einwenden, dass auch hier Code-Änderungen vorgenommen werden. Ja, nur Hand aufs Herz: Plugin-Änderungen macht der Webmaster aus Sicherheitsgründen, ein Update der Theme wird selten bis gar nicht durchgeführt.

Kommen wir nun zum Code. Wir öffnen das PHP-Script „sidebar.php“ unserer Theme. Der folgende Code muss nun an der passenden Stelle eingefügt werden. Dieser Code ist nicht optimiert und bewusst hier so angezeigt, um individuelle Anpassungen zu erleichtern:

<li id="meta" class="widget-container">

<h2 class="widget-title"><?php _e( 'Überschrift Neuste Artikel'); ?></h2>
<ul>

<?php $the_query = new WP_Query('showposts=10&orderby=post_date&order=desc');

while ($the_query->have_posts()) : $the_query->the_post();
      $id = $the_query->post->ID;
      $mymeta_field = get_post_meta($id, "kurzbeschreibung", false);
      $kurzbeschreibung = $mymeta_field[0];
      ?>
      <li>
            <a title="<?php the_title(); ?>" href="<?php the_permalink() ?>"><?php the_post_thumbnail(array(70,70), array ('class' => 'alignleft')); ?></a>
            <a title="<?php the_title(); ?>" href="<?php the_permalink() ?>"><?php the_title(); ?></a> <?php echo $kurzbeschreibung; ?>
    </li><br>
    <?php endwhile; ?>
</ul>
   <?php wp_reset_query(); ?>
</li>

Was passiert in unserem Code?

  1. Wir fügen einen neuen „Widget-Container“ ein. Dieser bezieht seine Daten durch die SQL-Abfrage mittels „WP_Query“. Im Select werden mittels „Showpost“ die neusten („DESC“) 10 Artikel abgefragt.
  2. Dann gehen wir die SQL-Abfragemenge mittels While-Schleife durch, setzen die Variable $id mit der aktuellen Post_ID, rufen das Meta-Feld „kurzbeschreibung“ des Artikels auf uns speichern diese in der Variable $kurzbeschreibung. Dieser Code ist sicherlich optimierungsfähig.
  3. Dass öffnen wir den Tag „<li>“, fügen das Artikel-Images in der Dimension 70×70 Pixel hinzu, versehen es mit der CSS-Class „alignleft“ und einem Hyperlink. Wenn uns die Anzeige des Images nicht zusagt, können wir dem Thumbnail eine eigene CSS-Klasse zuweisen und im CSS-Code der Theme entsprechende Anweisungen vergeben.
  4. Als Vorschautext wird zuerst der Title des Artikels („the_title()“) mit Link zum Artikel und dann unser individueller Vorschautext aus dem benutzerdefinierten Feld angezeigt.
  5. Zu guter Letzt beenden wir den „<li>“ bzw. den „<ul>“-Tag, schließen die While-Schleife ab und resetten auch die Query. Das Abschließende „<li>“ darf natürlich nicht vergessen werden.