• 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

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.

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.