Schlagwort-Archive: Wordpress

Konzept zum Deployment meines Blogs mit Ansible

An dieser Stelle möchte ich ein Konzept erarbeiten, um meinen Blog mit Hilfe von Ansible1 2 auf einem Ubuntu-Server ausbringen zu können.

Dabei hoffe ich auch ein wenig auf eure Unterstützung. Habt ihr Anregungen, konkrete Verbesserungsvorschläge oder auch Fragen, freue ich mich über eure Kommentare. Denn ich selbst bin kein Ansible-Experte und führe dieses Projekt zum Selbststudium und zu Übungszwecken durch.

Die Testumgebung

Die Testumgebung besteht aus der Ansible Control Machine, basierend auf RHEL 73 und dem Zielsystem, basierend auf Ubuntu Bionic Beaver4. Zum Zeitpunkt der Erstellung dieses Artikels nutze ich Ansible in Version 2.4.2.

Zwar wurde bereits die Ansible-Version 2.5 veröffentlicht, in den RHEL-7-Paketquellen ist jedoch noch die Version 2.4.2 enthalten. Ich verwende diese Version auch auf der Arbeit und erhoffe mir so, Erkenntnisse aus diesem Projekt in meine dienstliche Tätigkeit einfließen lassen zu können.

Auf dem Zielsystem existiert ein Benutzer, welcher über volle sudo-Berechtigung verfügt. Dieser Benutzer muss sich mit seinem Passwort authentisieren, wenn er sudo verwendet.

Auf der Ansible Control Machine wird ein SSH-Schlüsselpaar5 generiert, dessen privater Schlüssel nicht mit einer Passphrase geschützt ist. Der öffentliche Schlüssel wird auf dem Zielsystem abgelegt. Damit wird sichergestellt, dass die Ansible Control Machine SSH-Zugriff auf das Zielsystem hat.

Die Konfiguration von Ansible (/etc/ansible/ansible.cfg) wird so angepasst, dass standardmäßig das oben erzeugte SSH-Private-Key-File beim Verbindungsaufbau genutzt wird.

Die Installation der benötigten Betriebssysteme und Ansible sind nicht Gegenstand dieses Artikels.

Geplante Vorgehensweise

Um eine Vorgehensweise zu erarbeiten, orientiere ich mich an dem Artikel Testinstanz für einen WordPress-Blog erstellen. In diesem habe ich bereits beschrieben, wie ein Blog auf einem weiteren System als Testsystem aufgesetzt werden kann. Die Vorgehensweise ist ähnlich, mit dem Unterschied, dass sämtliche Schritte nun durch Ansible orchestriert werden sollen.

Danach ergibt sich folgende (vorläufige) Reihenfolge:

  1. Vom Produktivsystem benötigte Dateien holen
  2. Sicherstellen, das alle benötigten Pakete auf dem Zielsystem installiert sind
  3. VirtualHost erstellen
  4. DocumentRoot aus Backup-Datei erstellen
  5. Datei-Attribute und Zugriffsrechte korrekt setzen
  6. Eine .httpasswd-Datei erzeugen/ausbringen
  7. Datenbank aus Backup wiederherstellen
  8. Datenbankbenutzer erstellen
  9. Troubleshooting

Mit hoher Wahrscheinlichkeit ist die obige Liste noch nicht vollständig. Daher werde ich diese im Laufe des Projekts anpassen, sobald weitere Erkenntnisse vorliegen.

Als Quelldaten für den Blog liegen das DocumentRoot meines Blogs als Tarball6 vor. Von der Datenbank wurde ein logisches Backup7 erstellt. Auf diese Datensicherung wird zurückgegriffen, um den Blog auf einem neuen Ubuntu-Server auszubringen bzw. wiederherzustellen.

Der erste Versuch

Im ersten Anlauf habe ich eine Ansible-Rolle8 mit folgendem Aufbau erstellt:

/etc/ansible/roles/
└── deploy-my-blog
    ├── files
    │   ├── backup-documentroot.tar.bz2
    │   ├── dh_params.pem
    │   ├── db_dump.sql.bz2
    │   ├── my-it-brain.vhost
    │   └── php-fpm-pool.conf
    ├── handlers
    │   └── main.yml
    ├── tasks
    │   └── main.yml
    └── vars
        └── main.yml

5 directories, 8 files

Unterhalb von files wurden Dateien abgelegt, welche vom aktuellen Produktivsystem stammen und für das Deployment auf einem neuen Server benötigt werden.

Im folgenden werde ich zuerst auf die eingesetzten Module eingehen und anschließend das Playbook zum Deployment des Blogs vorstellen.

Verwendete Module

ModulStatusVerwendung
aptstableinterfaceVerwaltet APT-Pakete
unarchivepreviewEntpackt Archiv-Dateien und kopiert sie ggf. vorher auf das Zielsystem
copystableinterfaceKopiert Dateien auf entfernte Rechner
filestableinterfaceErstellt Dateien, Verzeichnisse, symbolische Links und setzt deren Attribute
mysql_dbpreviewHinzufügen von MySQL-Datenbanken (aus Backup)
mysql_userpreviewHinzufügen (und Entfernen) von Benutzern in MySQL-Datenbanken

Die in der Spalte Status angegebenen Werte stableinterface und preview lassen Rückschlüsse auf die Stabilität der Schnittstellen eines Moduls zu.

So garantieren die Entwickler bei einem stableinterface, dass es in Zukunft keine Änderungen geben wird, die nicht abwärtskompatibel sind. Auch wenn sich keine explizite Angabe findet, wie lange diese Garantie gilt, kann man davon ausgehen, dass man seine Playbooks bei Verwendung dieser Module nicht so schnell aufgrund von Updates anpassen muss. Für Module mit dem Status preview wird genau dies hingegen nicht garantiert. Hier kann es von Version zu Version Änderungen geben, welche Anpassungen an Playbooks erforderlich machen, welche diese Module verwenden. Dadurch entsteht ggf. ein erhöhter Testaufwand, bevor man seine Ansible-Installation aktualisieren kann.

Das Playbook

Den Inhalt der Datei /etc/ansible/roles/deploy-my-blog/tasks/main.yml habe ich unter dem Namen deploy-blog-playbook.yml als Gist veröffentlicht. Um es in diesem Artikel anzeigen zu können, müsst ihr JavaScript in eurem Webbrowser aktiveren.

Die Zeilen 2-11 sorgen dafür, dass die benötigten Pakete auf dem Zielsystem installiert werden. Da es sich dabei um einen Ubuntu-Server handelt, verwende ich das Modul apt.

Die Zeilen 13-16 stellen das DocumentRoot und die SSL-Zertifikate aus dem Dateibackup auf dem Zielsystem wieder her.

In meiner aktuellen Konfiguration verwende ich PHP-FPM mit einem eigenen Pool, welcher in meinem VirtualHost referenziert wird. Um diese Konstellation auch auf dem neuen System nutzen zu können, stelle ich entsprechende Konfiguration mit den Zeilen 18-47 her. Vermutlich können die Zeilen 39-47 entfallen, da PHP-FPM das Logfile automatisch erstellt. Weitere Tests müssen dies noch zeigen. Ich habe diese Zeilen während des Troubleshootings eingefügt. Ursache für den Fehler wird vermutlich das fehlende Log-Verzeichnis gewesen sein, welches ich in den Zeilen 29-37 erzeuge.

Der NGINX auf meinem Produktivsystem verwendet die Datei dh_params.pem, welche ich in den Zeilen 49-57 auch auf den neuen Host kopiere. Anschließend wird in den Zeilen 59-66 die vHost-Datei auf das Zielsystem kopiert und durch die Zeilen 68-77 verlinkt und damit aktiviert.

Die letzten Zeilen kümmern sich um die Einrichtung der Datenbank. Zuerst wird die Dump-Datei auf das Zielsystem kopiert und dort anschließend in die neue Datenbank db_my_it_brain eingespielt. Zum Schluss wird noch der benötigte Datenbank-Benutzer erstellt.

In Zeile 94 und 95 habe ich Variablen eingesetzt, welche in vars/main.yml definiert wurden. Dort habe ich auch eine Variable für den Namen der Datenbank definiert, welche ich gern in Zeile 96 genutzt hätte. Leider ist es mir nicht gelungen, da sowohl priv: '"{{ DBNAME }}".*:ALL' als auch priv: "{{ DBNAME }}".*:ALL zu Fehlern führten. Falls hier jemand eine Idee hat, freue ich mich, wenn ihr mir die korrekte Syntax mitteilt.

Erstes Fazit

Das ging leichter als gedacht. Die benötigten Module waren schnell gefunden und ihre Anwendung aufgrund der hinreichend guten Dokumentation nicht schwierig.

Da die aktuell genutzten Variablen sensible Informationen beinhalten, möchte ich diese zukünftig mit Ansible Vault schützen.

Stand heute bin ich jedoch erstmal in der Lage meinen Blog aus der Datensicherung heraus erneut deployen zu können.

Jörg Kastning

26. Dezember 2016

Mein WordPress-Blog „My-IT-Brain“ ist bis auf Weiteres auf einen neuen Server umgezogen.

Die Migration verlief nahezu reibungslos. Es mussten lediglich ein paar Plugins entfernt werden, die auf dem neuen Server ihre Arbeit verweigerten.

Falls ihr beim Besuch meiner Seite auf Fehler stoßt bzw. Dinge entdeckt die nicht (mehr) funktionieren, freue ich mich, wenn ihr diese über das Kontaktformular meldet.

Frohe Weihnachten
Der Webmaster

Testinstanz für einen WordPress Blog erstellen

Um Änderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu können, möchte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe benötigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.

Voraussetzungen

Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich über ein Kundencenter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.

Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.

Daten sichern

Um die spätere Testinstanz mit den Daten des Live-Blogs füttern zu können, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.

Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.

Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.1 Mit diesem Werkzeug kann man über eine einfach zu bedienende Weboberfläche ein Backup seiner Datenbank erstellen. Dieses Backup wird anschließend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.

Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.2

Serverkonfiguration

Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX.3

Für meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:

example.org/
├── logs
│   ├── access.log
│   └── error.log
└── public
    └── index.html

2 directories, 3 files

So wird für jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public. Die Datei index.html stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.

Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public abgelegte Seite auch ausliefert.

Um die spätere Testinstanz über die gleiche URL aufrufen zu können, wie den Live-Blog, wird ein Eintrag in die /etc/hosts eingefügt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.

Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begrüßt.

Zugriff beschränken

Während man eine neue Konfiguration testet, können Fehler passieren. Diese können zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. Für gewöhnlich ist nicht gewünscht, dass ein Benutzer dies sieht. Evtl. möchte man auch einfach nicht, dass Neuerungen zufällig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog überführt wurden.

Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschränken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.

Dazu eignet sich für NGINX-Benutzer das Modul ngx_http_auth_basic_module.4 Nutzer von Apache können .htaccess-Dateien5 verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.

Zuerst wird die .htpasswd-Datei erstellt, welche Benutzernamen und Passwort für die Authentifizierung enthält.

sudo touch /etc/nginx/conf.d/.htpasswd

Um das Passwort in verschlüsselter Form speichern zu können wird das Paket apache2-utils benötigt. Dieses enthält das Programm htpasswd, mit welchem Benutzername und Passwort erzeugt werden.

:~$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd BENUTZERNAME
New password: 
Re-type new password: 
Adding password for user BENUTZERNAME

Der Benutzer, unter dessen Kontext der Webserver (NGINX) läuft, muss Zugriff auf die .htpasswd erhalten.

:~$ sudo chown www-data:www-data /etc/nginx/conf.d/.htpasswd

Nun öffnet man die Konfigurationsdatei für die Testseite, welche für gewöhnlich unterhalb von /etc/nginx/sites-available/ liegt. Hier ist folgende Konfiguration zu integrieren:

location / {
    auth_basic           "Authentifizierung erforderlich!";
    auth_basic_user_file conf.d/.htpasswd;
}

auth_basic aktiviert die Überprüfung von Benutzername und Passwort. auth_basic_user_file gibt den Pfad an, wo die .htpasswd-Datei liegt, gegen die geprüft wird.

Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler überprüfen und bei Bestehen der Prüfung die Konfiguration neu laden.

:~$ sudo service nginx configtest 
 * Testing nginx configuration                    [ OK ] 
jkastning@rs212997:~$ sudo service nginx reload
 * Reloading nginx configuration nginx            [ OK ]

Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.

Daten einspielen

Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als nächstes die Daten aus dem Live-Blog eingespielt.

Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll genutzt.

DocumentRoot

Die gesicherten Dateien und Verzeichnisse, müssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis /var/www/example.org/public/. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.

sudo chgrp -R www-data /var/www/example.org/public

Die Datenbank

Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.

Wer hierbei Hilfe zur Syntax benötigt, kann im Artikel „Häufig verwendete MySQL-Befele“ nachlesen.

Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.

mysql -u root -p db_name < db_sicherung.sql

Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl überprüfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.

mysql -u db_benutzer -p db_name

Fertig. Mein Testblog läuft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. :-)

Update vom 24.12.2016

Bei der gestrigen Aktualisierung der Testinstanz musste ich feststellen, dass zwar die Startseite des Blogs geladen wird, jedoch alle Artikelaufrufe in einen 404-Fehler laufen.

Die Ursache für diese Fehler liegt darin begründet, dass ich mit Nginx einen anderen Webserver verwendet, als mein Webhoster. Dieser behandelt die Permalinks von WordPress anders, als z.B. ein Apache-Webserver mit dem Modul mod_rewrite.

Eine Lösung für dieses Problem habe ich ziemlich schnell in der Nginx Library6 gefunden. Es wird die try_files-Direktive7 verwendet, um aufgerufene URLs zur weiteren Behandlung an die index.php von WordPress weiterzuleiten.

Die Einrichtung ist relativ einfach. Das Vorgehen unterscheidet sich, je nach dem ob WordPress direkt im Wurzelverzeichnis einer Domain oder in einem Unterverzeichnis installiert ist. Im Folgenden werden beide Fälle betrachtet.

WordPress im Wurzelverzeichnis

Liegt die WordPress-Installation im Wurzelverzeichnis der Domain z.B. unter http://www.example.com, sucht man in der Konfigurationsdatei der Seite nach dem Block location /. Diesem Block wird folgende Zeile hinzugefügt:

try_files $uri $uri/ /index.php?$args;

Der vollständige Block sollte anschließend wie folgt aussehen:

location / {
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

WordPress in einem Unterverzeichnis

Liegt die WordPress-Installation in einem Unterverzeichnis der Domain z.B. unter http://www.example.com/wordpress, muss der Konfigurationsdatei ein Block nach dem Muster location /wordpress/ hinzugefügt werden, welcher wie folgt aussieht:

location /wordpress/ {
  try_files $uri $uri/ /wordpress/index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

The_Excerpt in Twenty Twelve mit Child-Theme

Dieser Artikel beschreibt die Anpassung des Standartthemes “Twenty Twelve”. Es wird ein sogenanntes “Child Theme” erzeugt und so angepasst, dass auf der Startseite und den Kategorieseiten nur Auszüge der Artikel angezeigt werden und nicht der komplette Artikel.

Child Theme

Ein WordPress Child Theme ist ein Theme, welches die Funktionalität eines anderen Themes, des sogenannten Parent Themes übernimmt und um eigene Anpassungen ergänzt. Die Verwendung eines Child Themes bietet sich an wenn man ein Theme anpassen/verändern möchte. Diese Anpassungen sollten nicht, im Standardtheme vorgenommen werden, da sie bei einem Update des Themes überschrieben werden und verloren gehen. Lagert man die Änderungen in ein Child Theme aus bleiben sie bei einem Update des Parent Themes erhalten.

Die Themes liegen im Pfad /wp-content/themes eurer WordPress Installation. In diesem Verzeichnis kann man nun ein neues Unterverzeichnis für das Child Theme anlegen. Ein Child Theme benötigt mindestens eine style.css.  In der style.css des Child werden die Einstellungen des Parent Theme importiert und um die eigenen Änderungen ergänzt. Wird das Child Theme aktiviert ersetzt die style.css des Child die style.css des Parent.

Hier ist ein Beispiel für eine entsprechende style.css:

/*
Theme Name: Twentytwelve Child
Description: Child theme for the twentytwelve theme 
Author: Your name here
Template: twentytwelve
*/

@import url("../twentytwelve/style.css");

Hier folgt die Erklärung was der obige Code macht:

  1. /* öffnet den Header des Child Theme.
  2. Theme Name: definiert den Namen des Child Theme.
  3. Description: Eine Beschreibung des Themes. Diese ist optional und kann entfallen.
  4. Author: Name des Autors. Angabe ist optional und kann entfallen.
  5. Template: Definiert das Parent Theme.
  6. */ schließt den Header des Child Theme.
  7. Die Regel @import importiert die Einstellungen aus der style.css des Parent Theme

Damit haben wir alles was wir für das Child Theme brauchen und können dieses im WordPress Backend unter Design -> Themes aktivieren. Noch sehen wir keine Veränderung, da wir ja bisher nur die Einstellungen des Parent Themes importiert haben. Nun passen wir das Theme weiter an.

The_Excerpt

Auf der Startseite des Blogs, den Kategorie Seiten und den Suchergebnisseiten sollen nicht die vollständigen Artikel angezeigt werden, sondern nur Auszüge.

Dazu kopieren wir die Datei content.php aus dem Parent Verzeichnis in das Child Verzeichnis. Diese öffnet man mit einem Editor und geht zur Zeile 33, welche wie folgt aussehen sollte.

<?php if ( is_search() ) : // Display Excerpts only for Search ?>

Diese Anweisung bewirkt, dass die Artikelauszüge nur auf den Suchergebnisseiten angezeigt werden. Um sie auf den Kategorieseiten und der Startseite ebenfalls anzuzeigen ändern wir die Zeile wie folgt ab.

<?php if ( is_search() || is_home() || is_category() ) : // Display Excerpts for Search, Category and Home ?>

Nachdem die Datei gespeichert wurde aktualisiert man die Browseransicht und die Artikel werden nicht mehr komplett sondern nur noch auszugsweise dargestellt. Aber wir können noch mehr tun.

Normalerweise endet ein Auszug mit […]. Wir können statt dessen jedoch auch einen Link mit
einem Benutzerdefinierten Text anzeigen lassen.

“Weiterlesen…” Link hinzufügen

Um die benötigten Änderungen vornehmen zu können erstellen wir im Verzeichnis des Child eine leere functions.php und fügen folgenden Code ein.

 <?php
/**
 * Twenty Twelve functions and definitions.
 *
 * Sets up the theme and provides some helper functions, which are used
 * in the theme as custom template tags. Others are attached to action and
 * filter hooks in WordPress to change core functionality.
 *
 * When using a child theme (see http://codex.wordpress.org/Theme_Development and
 * http://codex.wordpress.org/Child_Themes), you can override certain functions
 * (those wrapped in a function_exists() call) by defining them first in your child theme's
 * functions.php file. The child theme's functions.php file is included before the parent
 * theme's file, so the child theme functions would be used.
 *
 * Functions that are not pluggable (not wrapped in function_exists()) are instead attached
 * to a filter or action hook.
 *
 * For more information on hooks, actions, and filters, see http://codex.wordpress.org/Plugin_API.
 *
 * @package WordPress
 * @subpackage Twenty_Twelve
 * @since Twenty Twelve 1.0
 */

// Remove ... from excerpt and change the text
function change_excerpt_more()
{
  function new_excerpt_more($more)
    {
    // Use .read-more to style the link
     return '<span> <a href="' . get_permalink($post->ID) . '">[Weiterlesen...]</a></span>';
    }
  add_filter('excerpt_more', 'new_excerpt_more');

}
add_action('after_setup_theme', 'change_excerpt_more');

Damit werden die […] hinter dem Auszug entfernt und durch unseren eigenen
Text ersetzt. Das Ergebnis kann man hier auf meinem Blog betrachten.

Permalinkstruktur geändert

Seitdem ich mich ein wenig mehr mit dem Bloggen im allgemeinen und meinem Blog im speziellen beschäftigt habe gefiel mir meine alte Permalinkstruktur im Format http://www.my-it-brain.de/wordpress/archive/123 nicht mehr.

Aus der Wahl der „richtigen“ Permalinkstruktur kann man dabei gewiss eine Wissenschaft machen. Das habe ich hier jedoch nicht vor. Ich möchte lediglich bereits von der URL auf den Inhalt des Artikels schließen können. Darum habe ich die Struktur auf http://www.my-it-brain.de/wordpress/%postname% geändert.

Stellt man die Struktur der Permalinks einfach im Backend um, so hat dies zur Folge, dass alle vorhandenen Links auf einen 404-Fehler laufen. Um dies zu verhindern ist eine 301-Weiterleitung in die .htaccess-Datei einzufügen. Um mir das Leben so einfach wie möglich zu machen habe ich dazu einfach folgenden Generator benutzt.

Man gibt hier die Daten seines Blogs und der bestehenden Permalinkstruktur ein und generiert den Code für den Redirect. Diesen fügt man nun in die .htaccess-Datei ein, welche auf dem Webserver im gleichen Verzeichnis wie der Blog liegen sollte. Falls es noch keine solche Datei gibt legt man sie an. Wichtig: Zur Bearbeitung der .htaccess Datei sollte man keine Textverarbeitung wie MS Word oder LibreOffice verwenden. Am besten eignet sich ein Texteditor wie gedit, vim oder notepad++.

Bei mir hat es zuerst nicht funktioniert. Doch der Fehler war schnell gefunden. Da der Redirect Generator für eine englischsprachige WordPress Installation geschrieben wurde verwendete er als alte Permalinkstruktur http://www.my-it-brain.de/wordpress/archives/123. Darin ist aber ein „s“ zu viel, da die Struktur einer deutschsprachigen Installation wie folgt aussieht.

http://www.my-it-brain.de/wordpress/archive/123

Damit funktioniert die 301-Weiterleitung nun tadellos und ich habe schöne Links. :-)

Quellen:

The_Excerpt() – Auszug aus Artikel anzeigen

Wie bereits unzählige WP-Nutzer vor mir habe auch ich mich gefragt was ich anstellen muss um auf der WP-Startseite nicht die vollständigen Artikel, sondern nur Auszüge aus diesen, anzeigen zu lassen.

Um mir die Suche beim nächsten Mal zu ersparen und Leidensgenossen da draußen im Web zu unterstützen kommt hier ein kurzes Tutorial was man anstellen muss.

Ich verwende das Standard-Theme Twenty Eleven und habe das Tutorial auch nur mit diesem Theme getestet. Um die hier beschriebenen Änderungen vorzunehmen wird eine Konfigurationsdatei (content.php) mit einem Editor bearbeitet. Wir nicht sicher ist was er da tut sollte sich diese Datei unbedingt vorher sichern, bevor er irgendwelche Änderungen daran vornimmt. Nach diesem kurzen Warnhinweis legen wir mal los.

  1. Meldet euch im Backend eurer WP-Installation an und navgiert über das Menü auf der linken Seite zum Menüpunkt Design und wählt dort den Editor aus.
  2. Um die gewünschten Änderungen vorzunehmen ist die Datei content.php zu bearbeiten. Diese findet ihr wenn ihr auf der rechten Seite eures Fensters ein wenig nach unten scrollt.
  3. Im Editorfenster sucht ihr nun mittels STRG+F nach dem String the_content. Dabei solltet ihr folgende Zeile
    <?php the_content( __( 'Continue reading <span>&rarr;</span>', 'twentyeleven' ) ); ?>

    finden. Dies ersetzt ihr durch die Zeile

     <?php the_excerpt(); ?>
  4. Ich möchte das auch auf den Archivseiten nur ein Auszug der Artikel angezeigt wird. Dazu suche ich noch nach der Zeile
    <?php if ( is_search() ) : // Only display Excerpts for Search ?> 

    und ändere sie wie folgt

    <?php if ( is_archive || is_search() ) : // Only display Excerpts for Search ?>
  5. Mit einem Klick auf den Button „Datei aktualisieren“ werden die Änderungen in die aktive Konfiguration übernommen.

Zur Kontrolle hier noch ein Screenshot wie der entsprechende Abschnitt in der content.php aussehen sollte.

Der geänderte Code