Das Frontend hat nur noch eine leere Seite ausgegeben, Das Backend sah so aus:

Der Apache lief also noch. Es sah ganz stark nach ein Problem mit PHP aus.

Der Hintergrund zu diesem Problem war, dass statt PHP 5 nun PHP 7 nun bei Ubuntu Standard ist. Anscheinend ist da bei der Zusammenstellung der Pakete etwas schief gegangen.

Dank des Forums Ubuntuusers gab es aber sehr schnell Hilfe für das Problem.

Zuerst müssen die fehlenden Pakete nachinstalliert werden.

sudo apt-get install php-mbstring php7.0-mbstring php-gettext

Dann muss nur noch der Apache neu gestartet werden.

sudo service apache2 restart

Schon funktioniert alles wieder wie gewohnt.

Für den Webmaster ist die interne Suche eine wichtige Informationsquelle. Sie gestattet es, die Besucher näher kennen zu lernen und die Seite entsprechend zu optimieren.

Absicht des Suchenden erkennen

Wenn der Benutzer meiner Seite die interne Suche benutzt, dann sagt mir das zwei Sachen:

1. Er hat die gesuchte Information nicht auf der Seite gefunden.
2. Er vermutet aber, dass zu seinem Thema Informationen auf der Seite sein müssten.

Werkzeuge für die Analyse

Ein gutes Werkzeug für die Analyse der Suchanfragen ist Google Analytics. Hier habe ich schon mal gezeigt, wie man damit die Suchbegriffe herausfinden kann.

Es gibt aber noch ein viel effektiveres Werkzeug für die Analyse der internen Suche. Das ist das WordPress-Plugin Relevanssi. Mit einem Mausklick habe ich alle relevanten Informationen zur internen Suche.

Ich bekomme gleich angezeigt, für welche Suchbegriffe keine Antworten gefunden wurden.

Was tun?

Wenn Informationen zu dem gesuchten Thema auf der Seite vorhanden sind, der Nutzer aber trotzdem danach sucht, dann kann das verschiedene Ursachen haben.

Es kann sein, dass der Besucher einfach keine Lust hatte, sich die Seite näher anzuschauen und nur möglichst schnell zu den gewünschten Informationen kommen möchte. Solche Suchanfragen kann man getrost ignorieren.

Die passende Seite ist vielleicht so tief in der Navigation versteckt, so dass der Nutzer sie nicht gefunden hat. Kommt so etwas öfter vor, dann ist es Zeit, sich die Struktur der Seite mal näher anzuschauen. Ist die Seitenstruktur wirklich logisch aufgebaut und kann die Logik auch wirklich vom Besucher schnell erfasst werden.

Möglicherweise ist auch einfach nur die Usability der Navigation schlecht. Vielleicht schaut man einfach mal einem Nutzer seiner Seite über die Schulter.

Es kann auch sein, dass die Informationen, die der Nutzer gefunden hat, für ihn einfach nicht ausreichend sind. Der Artikel könnte dann vielleicht überarbeitet und mit mehr Informationen angereichert werden. Doch Vorsicht dabei. Nutzer haben ganz unterschiedliche Bedürfnisse. Manche wünschen nur oberflächliche Informationen zu einem Thema, andere wollen tiefer gehen. Diejenigen, die nur oberflächliche Informationen haben wollen, schreckt eine ausführlicher, allumfassender Artikel eher ab. Wenn man sich in der Wikipedia so umschaut, dann findet man dafür einige Beispiele. Eine Taktik, die ich gerne verwende ist, dann im ersten Teil des Artikels zunächst eine allgemeine oberflächliche Erklärung schreibe. Weiter unten können dann Hintergrundinformationen, Herleitungen und so weiter folgen.

Wenn ein entsprechender Artikel auf der Seite fehlt, dann kann man den ergänzen. Doch nicht gleich los schreiben! Erst einmal muss man entscheiden, ob dieser Artikel auch wirklich zum Thema der Seite passt. Ist das nicht der Fall, dann ist es besser, die Finger davon zu lassen. Es ist keine gute Idee, durch Themen zu allen möglichen Sachgebieten das Profil einer Seite zu verwässern.

Beispiel: Auf meiner Seite vergleichsspannung.de gibt es immer wieder Suchanfragen, bei denen es um elektrische Spannung geht und nicht um mechanische Spannung. Natürlich könnte ich da einen Artikel dazu schreiben aber der wäre ein Fremdkörper in der Seite, in der es um Probleme der Festigkeitslehre geht. Das Themengebiet einer Seite kann man ausweiten. Aber dann nur auf angrenzende Gebiete.

Fazit

Die interne Suche eine Seite ist eine wichtige Informationsquelle. Die Suchanfragen können helfen, die Besucher seiner Seite näher kennen zu lernen und fehlende Themen zu ergänzen.

Update 6.11.2016:
Aus Perun hat Vladimir einen Artikel zum gleichen Thema veröffentlicht. Er geht darin auf das Plugin Search Meter ein, dass im Funktionsumfang Relevanssi änlich sein dürfte.

• Fast Secure Contact Form
• Bulletproof Security
• Blubrry PowerPress podcasting plugin
• Form Manager version
• WordPress Files Upload
• Crony Cronjob Manager 0.4.4

Quelle: wordfence.com

Schließlich benutzt Google diese in den meisten Fällen in den Snippets der SERPs. Damit steht dem Webmaster ein Mittel zur Verfügung, direkten Einfluss auf die Anzeige in den Suchergebnissen auszuüben.

Nun stellt Martin Mißfeldt diese jahrelange Praxis in Frage. Er sagt, dass Google das besser als der Webmaster kann. Er hat festgestellt, dass abhängig von der Suchanfrage Google einen anderen Text im Snippet ausliefert. Diese generierten Texte wurden von Google automatisch auf die Suchanfrage optimiert. Er belegt das sehr schön an einem Beispiel.

Das ist eine sehr interessante Erkenntnis. Allerdings finde ich, dass man nun nicht grundsätzlich auf Meta-Descriptions verzichten sollte. Das automatische Optimieren der Snippets kann nur dann funktionieren, wenn viele gleichartige Suchanfragen zu diesem Thema gestellt werden. Das ist bei Nischenthemen in der Regel nicht der Fall. Da sind die von Google generierten Snippets manchmal doch nicht so optimal.

Deswegen sollte jeder Betreiber einer Nischenseite regelmäßig ein Blick in die Search Console zu werfen und nach Keywords mit niedriger Klickrate suchen. Die Klickrate ist muss immer in Bezug auf die durchschnittliche Platzierung betrachtet werden. Niedrige Klickraten können viele Ursachen haben. Schlechte Texte im Snippet kann eine davon sein. In diesem Fall kann man dann manuell eingreifen und eine Meta-Description hinzufügen.

Dafür benutze ich das WordPress-Plugin All In One SEO Pack.

Damit kann man sehr komfortabel direkt im Post die Meta-Description eintragen und sieht gleich eine Vorschau, wie das Ergebnis bei Google dann aussehen würde.

Mit diesem Plugin kann man noch eine ganze Menge andere nützliche Sachen machen. Aber das ist vielleicht eine Thema für ein separates Post.

Warum Fotos bei Dienstleister hosten?

Erst mal stellt sich die Frage, warum Fotos überhaupt auf einem externen Dienst gehostet werden sollten. WordPress hat ja eine eingebaute Medienverwaltung, die durchaus brauchbar ist.

Ein offensichtliches Kriterium ist der benötigte Platz. Die Speicherplatz bei Hosting-Paketen ist manchmal etwas knapp bemessen. Im konkreten Beispiel der Vereinsseite geht es um Fotos von Sportveranstaltungen. Pro Veranstaltung kommen da schon mal ein mehrere Hundert Bilder zusammen. Die Bilder sollen ja in einer vernünftigen Größe auf der Seite dargestellt werden und die Kompression soll nicht so stark eingestellt sein, dass sie sichtbare Spuren hinterlässt. Das braucht natürlich einen gewissen Speicherplatz. Der aktuelle Speicherplatz von 1 TByte bei Flickr reicht für wirklich sehr viele Bilder aus.

Das nächste Kriterium ist der Traffic. Das Problem hat vielleicht nicht gleich jeder auf dem Schirm. Viele Hosting-Pakete haben aber eine Begrenzung der monatlichen Traffics. Im konkreten Fall sind das 10 GB. Das scheint erst mal viel zu sein, aber wenn die Seite gut besucht ist, dann kann man diese Schwelle schon mal erreichten. Es fallen dann in der Regel zusätzliche Kosten an.

Eine weitere wichtige Sache ist die Ladezeit einer Seite. Wenn man ein preiswertes Hosting-Paket hat, dann kann man in der Regel davon ausgehen, dass man sich den Server mit sehr vielen anderen Seiten teilt. Die Auslieferung der Bilder kann da schon mal im Schneckentempo geschehen.

Hostet man die Bilder extern bei einem Anbieter, der darauf spezialisiert ist, dann kann man in der Regel davon ausgehen, dass die Bilder wesentlich flotter ausgeliefert werden. Flickr, Google und Co. benutzen dafür spezielle CDN.

Wie sich die Auslagerung der Fotos aus SEO-Sicht auswirkt, ist mir momentan noch nicht ganz klar. Vom Gefühl her würde ich sagen, dass die Auslagerung gewisse Nachteile bringt, weil die URLs der Bilder ja nicht identisch mit der URL der Seite ist. Anderseits ist auch die Geschwindigkeit des Seitenaufbaus ein Ranking-Signal. Wie sich das Auslagern wirklich auswirkt, das werden ich versuchen in einem Test zu ermitteln. Darüber werde ich dann zu gegebener Zeit hier berichten.

Wenn man einen eigenen gut angebundenen Server für seine Seite zur Verfügung hat, dann ist es nicht notwendig, Bilder bei einem Dienstleister zu hosten. In allen anderen Fällen lohnt es sich darüber nachzudenken, ob das Auslagern der Bilder nicht doch Vorteile bringt.

Mein Workflow

Jetzt möchte ich ganz ausführlich beschreiben, wie ich vorgehen, um die Bilder auf einer Vereinsseite zur Verfügung zu stellen. Diese Seite läuft mit WordPress. Aber auch auf Seiten mit anderen CMS kann man sicherlich ganz ähnlich vorgehen.

Einbinden in die lokale Bilderverwaltung

Zuerst binde ich den lokalen Ordner meiner Bilder in meine lokake Bilderverwaltung ein. Dazu nutze ich als Linux-Anwender Shotwell. Mit diesem Programm ist es sehr einfach, die Bilder zu Flickr hochzuladen.

Natürlich ginge das auch über den Browser-Upload. Bei einer relativ langsamen Internetverbindung ist der Browser-Upload allerdings etwas fehleranfällig. Für Windows-Nutzer bietet Flickr ein Programm zum Upload an.

Album in Flickr erstellen

In der Web-Oberfläche von Flickr ist nicht viel zu tun. Ich markiere die Bilder und füge sie zu einem Album hinzu. Das Album versehe ich mit einem Namen, der das Wiederfinden vereinfacht.

Einbinden des Albums mit Awesome Flickr Gallery

Zum Einbinden von Flickr-Bildern benutze ich das WordPress-Plugin Awesome Flickr Gallery.

Einrichtung des Plugins

Nachdem das Plugin installiert ist, muss es zunächst eingerichtet werden. Es sind eine Flickr User ID und ein Flickr API Key notwendig. Das sagt nicht jedem gleich etwas. Es ist aber jeweils eine Erklärung und ein Link vorhanden. So ist die Einrichtung sehr einfach.

Dann sind noch ein paar Standard-Einstellungen für die Galerien zu treffen. Das sind aber nur Voreinstellungen und können bei jeder Galerie überschrieben werden.

Galerie erzeugen

So, jetzt kann die erste Bilder-Galerie angelegt werden. Die entsprechende Link öffnet die Eingabeseite dafür.

Als Gallery Source wähle ich Photoset aus. Damit sind die Flickr-Alben gemeint. Nach der Auswahl stehen alle in Flickr definierten Alben in einen Dropdown-Liste zur Verfügung.

Jetzt können noch die Voreinstellungen für die Darstellung der Galerie überschrieben werden.

Sind alle Eingaben abgeschlossen, dann klickt man auf Add Gallery und das im oberen Bereich wird ein Shortcode für die Galerie angezeigt.

Diesen Shortcode brauchen wir gleich. Deswegen kopiert man ihn am besten in die Zwischenablage.

Galerie in Post einbinden

Das Einbinden in ein Post ist ganz einfach. Dazu wird der Shortcode einfach an der gewünschten Stelle eingefügt. Fertig!

Fazit

Das einzige Manko ist, dass die eingebundenen Bilder nur eine maximale Breite vom 500 Pixel beträgt. Das scheint eine Einschränkung von Flickr zu sein. Beim Klick auf das Bild wird es aber in voller Größe angezeigt.

Mit Flickr und dem WordPress-Plugin Awesome Flickr Gallery habe ich für mich einen sehr effektiven Workflow aufgebaut, um Fotos auf einer WordPress-Seite zu veröffentlichen.

Wann habt ihr euch zum letzten Mal die Ergebnisse der internen Suche auf eurer Webseite das letzte mal angeschaut? Angeregt durch einen interessanten Podcast von Termfrequenz.de habe ich die Suche auf vergleichsspannung.de genauer analysiert.

In dem Podcast ging es um wesentlich größer Seite als mein kleines 100-Seiten-Projekt. Es ging darum, wie beispielsweise in Shops optimale Suchergebnisse ausgegeben werden können. Das ist eine komplett andere Liga. Doch auch bei einer kleinen Seite kann man mit wenig Aufwand die interne Suche und damit die Usability erheblich verbessern. Wie ich das gemacht habe, das zeige ich hier.

Wonach wird gesucht?

Zunächst muss man erst mal raus bekommen, was die Besucher so in das Suchfeld eintippen. Das geht sehr einfach. Der Suchbegriff wird in der URL als Parameter „s“ übergeben. Also braucht man in seinem Analysetool nur danach zu suchen und bekommt die Begriffe angezeigt:

Diese kann man dann am besten in eine Excel-Datei exportieren.

Ist der Suchbegriff relevant?

In der Excel-Datei kann man dann bewerten, ob der Suchbegriff überhaupt für die Seite relevant ist.

Die Filterfunktion von Excel oder OpenOffice hilft bei dem Aussortieren unsinniger Keywords.

Habe ich eine passende Ergebnis-Seite?

Die nächste Frage ist, ob eine passende Seite vorhanden ist.

Ist der Suchbegriff relevant und hast du keine passende Seite? Herzlichen Glückwunsch! Damit hast du gerade ein Thema für eine neue Seite gefunden.

Wenn eine passende Seite vorhanden ist, dann muss analysiert werden, ob diese auch in der Suche angezeigt wird.

Analyse der Suchergebnisse

Wird die richtige Seite angezeigt, dann ist alles in Ordnung. Wenn nicht, dann muss genauer untersucht werden, warum nicht. Das könnte daran liegen, dass der Text des Artikels nicht genau das Keyword enthält. Vielleicht kannst du ja noch ein wenig am Text feilen und das Keyword in den Text aufnehmen. Wenn das nicht in Frage kommt aber der Artikel trotzdem gefunden werden soll, dann gibt es auch dafür Möglichkeiten. Wie das geht, das zeige ich weiter unten.

Was mache ich bei Vertippern?

Schauen wir mal, was Google macht. Wenn man dort nach dem Keyword „Standart“ sucht, dann sieht das Ergebnis so aus:

Google bemüht also die interne Rechtschreibkontrolle und merkt, dass im Deutschen die korrekte Schreibweise „Standard“ wäre und schlägt die Suche danach vor. Es kann aber sein, dass der Nutzer nach der bulgarischen Zeitung sucht. Deswegen fragt Google den Nutzer und ändert nicht stillschweigend den Suchbegriff in „Standard“.

Ist dieses Vorgehen auch bei der internen Suche sinnvoll? Nein! Wenn jemand nach „Wiederstandsmoment“ sucht, dann muss man den Nutzer nicht belehren, dass der richtige Suchbegriff „Widerstandsmoment“ wäre, sondern man kann gleich die passende Seite zum Widerstandsmoment anzeigen. Wenn der Nutzer wissen wollte, wie der Begriff richtig geschrieben wird, dann hätte er duden.de aufgerufen. Da er aber auf einer Seite zur Festigkeitslehre unterwegs ist, will er eine Erklärung zu diesem Begriff haben.

Wie bekomme ich jetzt aber meine interne Suche dazu, die Seite zum Widerstandsmoment anzuzeigen, wenn der Nutzer „Wiederstandsmoment“ eintippt? Natürlich kann man in den Artikel alle Vertippervarianten direkt in den Artikel reinschreiben. Dort würden die Begriffe aber nur Stören. Für Google macht das auch kein Sinn, weil durch die sehr gute Rechtschreibprüfung von Google die Seite trotzdem gefunden wird.

Ich habe es so gelöst, dass ich für jeden Artikel ein benutzerdefiniertes Feld eingebaut habe, in denen ich alle Vertippervarianten aufnehmen kann.

Jetzt muss ich die interne Suche von WordPress noch davon überzeugen, auch in diesem Feld nach den eingetippten Begriffen zu suchen. Das geht mit den Bordmitteln nicht. Ich benutze dafür das Plugin Relevanssi. Da kann ich einstellen, dass auch das benutzerdefinierte Feld durchsucht wird:

Das Plugin kann noch viele Sachen mehr. Das ist aber Stoff für einen weiteren Artikel.

Insgesamt sind es etwas über Hundert Seiten. Ich weiß, im Vergleich zu so mancher Firmenwebseite ist das verschwindend gering. Aber so ganz kleines 10-Seiten-Projekt ist es auch nicht mehr.

Ich verwende für dieses Projekt WordPress. Das steht ja in dem Ruf, ein System für Weblogs zu sein. Genau dafür wurde WordPress ja auch ursprünglich entwickelt. Mittlerweile sind immer mehr Funktionen hinzugekommen, die den Anwendungsbereich ausweiten. Mittels der sogenannten „Seiten“ können auch Projekte umgesetzt werden, die keinen Blog-Charakter haben. Genau so ein Projekt ist meine Vergleichsspannungsseite. Es besteht aus statischen Seiten, die in einer Hierarchie angeordnet sind.

Will man solch ein Projekt mit WordPress realisieren, dann wird man bald auf ein Problem stoßen. Die Übersichtlichkeit der Seitenliste lässt sehr zu wünschen übrig:

Die Tabelle mit der Seitenauflistung ist nicht optimal und maximal bis zu 20 Seiten brauchbar.

Wenn man eine Seite an eine andere Stelle in der Hierarchie verschieben möchte, dann muss man die Bearbeitungsansicht der Seite öffnen und dann in einer unübersichtlichen Liste eine neue Elternseite auswählen. Dann muss man noch mittels einer Zahl die richtige Reihenfolge der Seiten definieren. Sehr umständlich!

Mit den Bordmitteln von WordPress hätte ich bei diesem Projekt schon lange die Übersicht verloren.

Ein kleines Plugin hilft, die Übersicht zu behalten. Mit CMS Tree Page View werden die Seiten in einer Baumstruktur dargestellt.

Es gibt Funktionen, neue Seiten an genau definierten Stellen im Baum zu erzeugen.

Vorhandene Seiten können per Drag & Drop an andere Stellen verschoben werden.

Es ist sofort ersichtlich, welche Seiten der Baumstruktur noch im Review- oder Entwurfsstatus sind.

Aus dem Baum heraus kommen die Seiten im Bearbeitungsmodus geöffnet oder in der Vorschau angezeigt werden.

Mit diesem kleinen Plugin ist es möglich, auch bei größeren Projekten die Übersicht zu behalten.

Die einzige Voraussetzung ist, dass in einem Artikel die Überschriften auch wirklich korrekt als Überschriften gekennzeichnet sind. Aber das dürfte sowieso klar sein.

Es macht natürlich keinen Sinn, auf wirklich jeder Seite in Inhaltsverzeichnis einzufügen. Nur dann, wenn auch wirklich mehrere Überschriften vorhanden sind, dann ist es hilfreich.

Man kann dem Plugin auch mitteilen, dass spezielle Inhaltstypen komplett von der Erzeugung von Inhaltsverzeichnissen ausgenommen werden.

Vielleicht ist es sinnvoll, auf Formularen grundsätzlich kein Inhaltsverzeichnis einzufügen.

Möchte man verhindern, dass auf einer speziellen Seite ein Inhaltsverzeichnis eingefügt wird, dann kann man es mit dem Shortcode im Artikel explizit verbieten. Andersherum geht es auch. Mit wird die Erstellung erzwungen.

Das Inhaltsverzeichnis kann auf- und zugeklappt werden.

Auf Wunsch kann mit diesem Plugin auch eine Sitemap erzeugt werden.

In den Einstellungen zum Plugin ist eine deutschsprachige Hilfe-Seite vorhanden.

Die Einstellung sind in Haupteinstellungen und Experteneinstellungen untergliedert, wobei die Experteneinstellungen zunächst verborgen sind. Ähnlich funktioniert die Hilfe-Seite. Die Informationen für Entwickler sind in einem Abschnitt zusammengefasst und zunächst ausgeblendet. So geht Usability!

Dieses Plugin arbeitet unauffällig im Hintergrund und nimmt mir sehr viel Arbeit ab. Für jeden, der etwas längere Texte in WordPress verfassen möchte, ist das absolut zu empfehlen.

Oft hat heute Webspace diese benötigte Ausstattung, aber nicht immer. Dieser Webspace, auf dem mein Blog liegt, kann nichts mit PHP anfangen und hat auch keine Datenbank

Für einen Webserver gibt es nichts Einfacheres,  als eine statische HTML-Seite auszuliefern. Bei WordPress muss der PHP-Code ausgeführt werden, der dann noch einige Datenbankabfragen startet. All das kostet Zeit. Die Antwortzeit eine Webseite ist inzwischen auch ein Ranking-Faktor bei Google…

WordPress ist (vollkommen zu Recht) ein sehr populäres System. Dadurch ist es natürlich auch ein beliebtes Angriffsziel. PHP hat immer mal die ein oder andere Sicherheitslücke. Auch Programmierfehler in WordPress selber oder den Themes können die Webseite verletzlich machen.

Zum Bearbeiten meldet man sich mit Benutzername und Passwort am Backend an. Ist die Verbindung nicht mit https abgesichert, dann lassen sich Benutzername und Passwort unterwegs abfangen und der Webspace damit kapern.

Statische HTML-Seiten minimieren alle Sicherheitsprobleme.

Wie kann man nun die Vorteile des Komforts von WordPress mit den Vorteilen statischer HTML-Seiten unter einen Hut bringen? Ich möchte hier einen möglichen Weg aufzeigen.

Die Idee

Ursprünglich wollte ich für diese Seite hier gar kein WordPress verwenden. Ich habe zunächst nach einem System gesucht, mit dem die Texte in einem einfachen Texteditor wie gedit geschrieben werden können, eventuell in Markdown. Aus den Textdateien sollten dann per Skipt alle HTML-Dateien sowie die anderen notwendigen Dateien erzeugt werden.

Ich wusste, dass es speziell für Podcaster so ein System gibt, Mikrowelle-OS. Das System ist in Python geschrieben. Mangels Python-Kenntnisse kam aber eine Anpassung für mich nicht in Frage. Also machte ich mich auf die Suche nach einem ähnlichen Systems, das für Blogs ausgelegt ist.

Da bin ich auf Letterpress gestoßen. Das ist war eigentlich genau das, wonach ich gesucht hatte. Der einzige Haken war, dass ich es auf meinem Computer nicht richtig zum Laufen gebracht habe. Für mich unverständliche Fehlermeldungen und fehlende Python-Kenntnisse standen dem im Weg. Die Informationen zu Letterpress im Web waren auch sehr begrenzt.

Also bin ich doch wieder bei WordPress gelandet. Ich dachte mir, dass es vielleicht ein Plugin gibt, das statische Seiten generiert. Really Static ist so eins. Auf meiner lokalen WordPress-Installation wollte es allerdings aus unerfindlichen Gründen nicht richtig laufen. Bevor ich mich auf die lange Fehlersuche machte, überlegte ich, ob es eigentlich nicht viel einfacher ging. Ich benutze einen Computer mit Linux und dieses Betriebssystem verfügt über eine Kommandozeile mit sehr vielen leistungsfähigen Befehlen. Einer dieser Befehle ist wget. Ich wusste, dass man mit diesem Tool ganze Seiten crawlen und diese lokal speichern kann. Das war mein Ausgangspunkt.

Ich überlegte mir diesen groben Ablauf:

1. Schreiben der Artikel in meiner lokalen WordPress-Installation.
2. Crawlen meiner lokalen Webseite mit wget und Abspeichern als statische HTML-Seiten.
3. Notwendige Korrekturen in den HTML-Dateien durchführen.
4. Upload per ftp auf meinen Webspace.

Auf das automatisierte Hochladen verzichte ich vorerst. Erst wenn ich mir sicher bin, dass alles fehlerfrei läuft, werde ich auch das mit in das Skript aufnehmen.

Die Umsetzung

Lokale WordPress-Installation

Zunächst muss eine lokale WordPress-Installation her. Dafür sind folgende Voraussetzungen nötig:

• Webserver Apache2
• Datenbankserver MySQL
• PHP5

Auf diese Voraussetzungen möchte ich gar nicht weiter eingehen. Es gibt dafür genügend gute Anleitungen im Web, z. B. im Ubuntu-Wiki:

• Apache
• MySQL
• PHP5

Dann muss noch WordPress installiert werden. Auch dafür gibt es genügend gute Anleitungen, wie dieses hier, so dass ich das hier nicht weiter beschreiben möchte.

Ist das alles erfolgreich absolviert, dann ist das WordPress-Backend im Browser erreichbar, bei mir unter http://localhost/blog/wp-admin. Hier können nun wie gewohnt die Artikel verfasst werden.

Umwandeln in statische Seiten

Als Vorbereitung wird zunächst ein Arbeitsordner angelegt, z. B. /home/MeinName/Blog/.

In diesem Ordner wird ein Shellskipt angelegt. Es wird eine Textdatei erzeugt. Ich habe sie bei mir wp2html.sh genannt. Diese Datei muss aufführbar gemacht werden:

Mit #!/bin/bash in der ersten Zeile der Datei teilt man dem Betriebssystem mit, dass es sich hier um ein Shellskript handelt.

Mit dem folgenden Befehl werden die dynamischen Seiten als statische HTML-Seiten abgespeichert:
wget -r -k -E -l 8 http://localhost/blog

Die Option -r bewirkt, dass wget jedem Link nachgeht und das verlinkte Dokument ebenfalls abspeichert.

Wichtig ist die Optione -k. Damit werden in den lokal gespeicherten Dokumenten alle externen Links zu internen konvertiert. Aus http://localhost/blog/index.html wird dadurch ./index.html. Im Internet würde eine Verlinkung auf http://localhost/blog/index.html ja keinen Sinn machen.

Die Option -E sorgt dafür, dass die gespeicherten Seiten mit .html enden.

Mit -l 8 wird die Rekursionstiefe begrenzt. Es würde wahrscheinlich auch ohne diese Option gehen, ich wollte nur sicher gehen, dass wget nicht versucht, das gesamte Internet auf meiner Platte zu speichern.

Der Befehl wget ist ein extrem leistungsfähig. Einen kleinen Einblick, was man noch so alles damit anstellen kann, ist im Ubuntu-Wiki nachzulesen.

Nachdem wget ausgeführt wurde, liegt der komplette Inhalt des Blogs auf der Platte. Ein kleines Problem gibt es noch. Es existieren u. a. Dateien mit solchen Namen:

index.html?p=31.html

Lokal macht das nichts, diese Datei kann trotzdem im Browser aufgerufen werden. Anders sieht es jedoch auf dem Zielwebserver aus. Alles was hinter dem „?“ kommt wird als Argument interpretiert. Wenn ich im Browser also http://example.com/index.html?p=31.html aufrufe, dann wird http://example.com/index.html angezeigt und p=31.html wird der Seite als Argument übergeben. Damit kann diese Seite nichts anfangen.

Würde ich die Dateien so unbearbeitet auf den Zielwebserver hochladen, dann würde immer nur die Startseite des Blogs richtig angezeigt werden. Ein Klick auf einen Link zu einem Artikel würde wieder nur die Startseite aufrufen.

Deswegen müssen alle Dateien umbenannt werden, die ein „?“ im Namen haben. Damit nicht genug. Die Links in den lokalen Dateien, die auf Dateien mit einem „?“ im Namen zeigen, müssen ebenfalls geändert werden.

Fangen wir mit dem Umbenennen der Links an. Das „?“ möchte ich durch „_“ ersetzen. Das Fragezeichen speichert wget in den Links als _ ab. In einem Texteditor wäre es überhaupt kein Problem, mittels der Funktion Suchen und Ersetzen alle Vorkommen von _ durch _ zu ersetzen. Aber man möchte nicht wirklich mehrere hundert Dateien nacheinander im Editor öffnen und mittels Suchen und Ersetzen bearbeiten. Dafür gibt es den Befehl sed.

Die komplette Zeile im Skript sieht so aus:

find localhost -type f -print0 | xargs -0 -n 1 sed -i -e "s/_/_/g"

Mit sed -i -e "s/_/_/g" wird in einer Textdatei jedes Vorkommen von _ durch ein _ ersetzt.

Die Option -i sorgt dafür, dass die Datei überschrieben wird und das Ergebnis nicht an der Standardausgabe ausgegeben wird.

Mit -e wird ein Skript übergeben, das in diesem Fall nur auch "s/_/_/g" besteht. Das ist ein regulärer Ausdruck, der _ durch _ ersetzt.

Wie überzeuge ich aber nun sed, das für alle Dateien zu tun?

Dazu werden zunächst erst einmal alle Dateien aufgelistet. Das macht man mit find localhost -type f -print0.  Der Befehl find unter Unix und Linux unterscheidet sich vom find, das viele vielleicht von Windows her kennen. Hier eine Beschreibung dafür.

Die Option -type f sorgt dafür, dass nur Dateinamen und keine Ordnernamen aufgelistet werden. Mit -print0 werden die vollständigen Dateinamen ausgegeben mit einem Null-Zeichen als Trenner.

Über eine Pipe wird die Ausgabe von find an xargs übergeben. Dieser Befehl sorgt nur dafür, dass sed immer wieder mit der Ausgabe von findaufgerufen wird.

Damit ist das Korrigieren der Links in den Dateien erledigt. Es müssen nun noch die Dateien mit einem „?“ im Dateinamen umbenannt werden. Das passiert nach genau dem gleichen Schema:

find localhost -type f -print0 | xargs -0 -n 1 rename -v 's/\?/\_/' *

Der einige Unterschied zum Umbenennen der Links ist, dass jetzt statt sed jetzt rename aufgerufen wird.

Hier mein komplettes Skript:
#!/bin/bash
echo HTML-Seiten abspeichern
wget wget -r -k -E -l 8 http://localhost/blog/
echo #########################################
echo Links in den Dateien berichtigen
find localhost -type f -print0 | xargs -0 -n 1 sed -i -e "s/_/_/g"
echo #########################################
echo Dateinamen berichtigen
find localhost -type f -print0 | xargs -0 -n 1 rename -v 's/\?/\_/' *

Nach dem Ausführen des Skripts liegt nun ein Kopie des Blogs auf der lokalen Festplatte, die nun auf den Webspace hochgeladen werden kann. Das Hochladen ließe sich auch noch automatisieren. Ich wollte aber vorerst noch die Kontrolle behalten, was veröffentlicht wird.

Nachteile

Es gibt auch einige erhebliche Nachteile, wenn man nur statische HTML-Seiten auf dem Server hat. Es funktioniert natürlich keine Suchfunktion. Kommentarfunktion, Kontaktformulare, Foren usw. funktionieren nicht.

Wenn die lokale Wordpess-Installation nur auf den Arbeitsplatz-PC läuft, dann können auch nur auf diesen Computer Artikel geschrieben werden. Von eine beliebigen Computer im Internet mal schnell einen Blogbeitrag veröffentliche, das geht mit dieser Methode nicht.

Eine Sache sollte man bei dieser Methode nicht ganz außer acht lassen, das ist die Laufzeit des Skripts. Es ist sicherlich keine gute Idee, eine Seite mit mehreren tausend Unterseiten auf diese Art und Weise zu erzeugen. Sie ist eher für kleinere Projekte geeignet.

Weitere Anwendungen

Für das hier vorgestellte Verfahren gibt es noch einige weitere Einsatzszenarien. Überall da, wo eine WordPress-Seite offline zur Verfügung gestellt werden soll, kann es verwendet werden. Möchte man beispielsweise den Stand einer Seite einem Kunden vorstellen und es ist dort nicht sicher eine gute Internetverbindung vorhanden, dann ist dies ein Weg.

Oder muss ein USB-Stick für Werbezwecke produziert werden, dann sind mit WordPress sehr schnell die passenden Inhalten gestaltet. Beim Anwender es USB-Sticks kann man nicht davon ausgehen, dass eine Internetverbindung besteht. Und davon, dass man auf dem Computer des Anwenders gar einen kleinen Mini-Webserver starten kann, davon kann man erst recht nicht ausgehen.

Es lassen sich sicher noch einige Anwendungen mehr finden. Auf jeden Fall soll es kleine eine Anregung zum Experimentieren sein.

Übrigens: Unter der Haube jedes Mac läuft ein Unix. Unter MacOS kann man genau so wie unter Linux ein Terminal öffnen und das hier vorgestellte Skript ebenfalls ausführen.

Früher bin ich so vorgegangen:

• Formel in LibreOffice erstellt
• Export als PNG
• PNG hochgeladen
• PNG in Artikel eingefügt.

Das war mir etwas zu umständlich. Außerdem gibt es noch den Nachteil, dass die Grafik beim Skalieren der Seite nicht verlustfrei skaliert wird. Unansehnliche Formeln waren die Folge.

Ich machte mir also Gedanken, wie ich Formeln in einem Vektor-Format darstellen könnte. Zuerst kam mir MathML in den Sinn. Ich beschäftigte mich also etwas mit dieser Auszeichnungssprache. In der Wikipedia steht dazu, dass die Sprache etwas unhandlich sein. Das kann ich nur bestätigen.

Ich dachte zunächst, dass ich die Formeln weiterhin mit LibreOffice schreibe und sie dann als MathML exportiere. Das hätte funktioniert. Aber dann schaute ich, welche Browser MathML unterstützen. Chrome und Internet Explorer unterstützen diese Sprache nicht. Damit hätte ein großer Teil meiner Nutzer Probleme, meine Seiten richtig anzeigen zu können. Das war das KO-Kriterium für MathML.

Im Druckbereich wird gerade bei wissenschaftlichen und technischen Texten häufig LaTeX als Satzsystem benutzt. Mit LaTeX können Formeln sehr einfach erstellt werden. Der Syntax ist leicht zu lernen. Ansonsten gibt es Tools wie EqualX, mit denen die Formel zusammengeklickt werden können und die daraus die entsprechenden LaTeX-Befehle generieren.

Mit E=m \cdot c^2 ergibt sich die folgende Formel:

In MathML hätte die gleiche Formel übrigens so ausgesehen:

<math xmlns=" http://www.w3.org/1998/Math/MathML"> 
  <mi>E</mi> 
  <mo>=</mo> 
  <mi>m</mi> 
  <mo>⋅</mo> 
  <msup> 
    <mi>c</mi> 
    <mn>2</mn> 
  </msup> 
</math> 

Wie kann man nun diese LaTeX-Syntax in WordPress verwenden? Dafür gibt es MathJax, was mit den Plugin MathJax-LaTeX in Worpress eingebunden werden kann.