Bis zu meinem Start als Blogger hab ich all mein Wissen über Internet, HTML & Co. aus dem Netz geholt. Es war an der Zeit, etwas davon wieder zurückzugeben – denn wenn niemand Wissen ins Netz stellt, dann gibts dort keins. Und vor Social Media war es eine gute Möglichkeit, sich mit Menschen zu vernetzen – Blogfreundschaften über Ländergrenzen hinweg, man las und kommentierte gegenseitig und wenn sichs ergab, dann traf man sich auch im echten Leben (z.B. wenn ich mitgekriegt hab, dass jemand in Wien urlaubte). So hab ich im Lauf der Zeit europaweit viele Kontakte geknüpft, die teilweise bis heute bestehen.

Es sind seither über 2000 Beiträge geworden (zugegeben: nicht unbedingt alle mit hohem Bildungswert), die allesamt noch online sind. Denn bei jedem Wechsel auf ein neues Blogging-Tool ist es mir gelungen, die alten Beiträge mit auf das neue System zu übersiedeln. Der erste Schritt war die Umstellung auf Greymatter – ein selbstgehostetes Perl-Script mit Flat-File-Datenbank, das Blogposts und Archivseiten als statische Seiten gerendert hat (und bei jeder Änderung eines Beitrags dann ewig gebraucht hat, um all das neu zu erstellen). Im Jahr 2002 dann der Umstieg auf Sunlog: ein Open-Source-Tool auf Basis php/mySQL, das vom Schweizer Andreas Ahlenstorf entwickelt wurde. Nach seinem Ausstieg aus dem Projekt wurde die Codebasis nicht mehr gepflegt, außerdem wurden in dieser Zeit Spamkommentare zunehmend zum Problem, daher musste ich mich 2006 nach etwas Neuem umsehen.

Also installierte ich alle damals verfügbaren Blogging-Systeme auf meinem Server und hab versucht, die alten Beiträge aus Sunlog möglichst schmerzfrei zu übernehmen. Textpattern, Serendipity, Movable Type und WordPress hab ich damals ausgiebig getestet. Und letzteres erschien mir eine gute Wahl. Diese Bauchentscheidung war offenbar eine gute – denn WordPress entwickelte sich in den Folgejahren zum Marktführer, nicht nur für Weblogs sondern auch für viele andere Arten von Websites, selbst Webshops lassen sich heutzutage damit gut umsetzen.

Anfangs gings hier am Weblog um alle möglichen Themen, von Musik übers Reisen bis hin zu Rants gegen Firmen, Institutionen oder gesetzliche Regelungen. Mit Anfang 2020 war es Zeit, die älteren Artikel in ein Archiv zu verschieben – zum Löschen sind sie zu schade, passen aber großteils nicht mehr ins Profil dieser aktuellen Firmenwebsite. Hier sind nur mehr die Artikel zu finden, die Bezug zu meiner Passion als Nerd & WordPress-Pannenhilfe haben.

Mit dem Aufstieg von Social Media und meiner Nutzung von Facebook, Twitter, Instagram & Co. wurden die Beiträge hier weniger, dennoch ist das Weblog immer noch meine bevorzugte Basis, um selbst erstellten Content zu verbreiten. Denn in über 22 Jahren in der Branche hab ich viele Dienste kommen und wieder gehen gesehen, aber diese Website hier gibts noch immer. Passenderweise gibts auch einen Blogpost dazu: „Plötzlich ist alles weg: das geborgte Internet“, wo ich genau das empfehle: verwendet als Homebase immer die eigene Website – alles andere ist irgendwann nicht mehr da!

Weiterhin wirds hier regelmäßig Artikel zu Themen geben, die mich im Job aktuell beschäftigen und/oder wo ich häufig von Kunden danach gefragt werde – halt wie immer nicht täglich, sondern wenn grad Zeit ist oder der Anlass passt. Und weiterhin freu ich mich über Kommentare, Hinweise und Ideen für neue Blogposts.

Danke, Internet. Schön wars – auf weitere (mindestens) 20 Jahre :-)

Also Umstellung der URLs auf ein Format, das Google mehr mag.
Man kann bei WordPress unter „Einstellungen -> Permalinks“ die URL-Struktur ja recht einfach ändern: einfach statt /%year%/%monthnum%/%postname%/ nur mehr /%postname%/ eintragen. Leider laufen dadurch ALLE links von Google vorerst ins Leere, es geht also nicht ohne Nacharbeit. Netterweise hat Joost de Valk (der Autor des SEO-Plugins Yoast) dazu einen Artikel geschrieben: How to change your WordPress Permalink structure – und dort findet sich ein Tool namens Permalink Helper, mit dem man automatisiert die entsprechende Zeile für die .htaccess erzeugen lassen kann, die dafür sorgt, dass die „alten“ URLs mit Datum zuverlässig auf die „neuen“ URLSs umgeleitet werden. Diese Zeile kopiert man ganz an den Anfang der .htaccess, damit die Umleitung schon greift, bevor die WordPress-eigenen Umleitungen zu wirken beginnen.

Getestet – funktioniert. Danke, Joost :-)

(Und wer bei der Umstellung Hilfe braucht, der weiß, wen er fragen sollte ;-) )

Dieser tragische Fall zeigt sehr drastisch, dass es keine gute Idee ist, die eigene Online-Präsenz nur auf externe Dienste aufzubauen. Denn ganz flott ist alles weg, was man jahrelang an Zeit, Nerven und Arbeit reingesteckt hat.

Egal ob Facebook, Instagram, Twitter, Blogger, Jimdo oder Wix: sie alle waren nicht immer da und werden es sicherlich nicht ewig sein. In den 25 Jahren Internetbusiness habe ich viele Hostingdienste kommen und wieder gehen sehen, etwa Geocities (gegründet 1994) das 2009 geschlossen wurde oder Posterous, das kurz nach dem Verkauf an Twitter ersatzlos abgedreht wurde. Außerdem sperren oder löschen all diese Dienste gerne mal Websites, wenn diese gegen die Nutzungsbedingungen verstoßen. „Geborgtes Internet“ – so nannte Sascha Lobo das schon 2012 in einem Artikel auf Spiegel.de

Ein weiteres Problem: DU bist verantwortlich, dass DEINE Website gesetzeskonform ist (ECG / Mediengesetz / DSGVO!) – und wenn dein Baukastensystem z.b. Google-Fonts einsetzt oder ungefragt Tracking-Codes einbaut, so ist das zwar die Schuld des Baukastens, aber dennoch bist DU der Mensch, der die Abmahnung ins Haus kriegt!!!

Meine Empfehlung daher ganz klar: bau Deine Online-Präsenz immer rund um die eigene, selbst gehostete Website mit eigener Domain auf. Ob man dafür WordPress, Joomla, Contao, Drupal, TYPO3 oder ein anderes System als technische Basis nimmt, ist prinzipiell nicht so wichtig (diese Auswahl ist vorab nur davon abhängig, was man für Funktionen umsetzen will und womit das am Besten geht) – der Punkt ist, dass die Daten allesamt am eigenen Server liegen und man die Daten sinnvoll sichern und im Notfall problemlos wiederherstellen kann. Die eigene Domain sorgt dafür, dass einerseits die Website-Adresse sich nie ändern muss, wenn man zu einem anderen Provider wechseln mag – auch die eigene Mailadresse kann man auf diesem Wege ewig behalten, sofern diese auf den eigenen Domainnamen aufbaut (denn auch das sieht man immer wieder: Geschäftsdrucksorten / Fahrzeugbeschriftungen / Flyer / Folder um viel Geld, wo eine Mailadresse eines der bekannten Gratisanbieter wie Gm*il, H*tmail, GM*… angeführt wird – das ist hochgradig unprofessionell!)

Auf der eigenen Website veröffentlichte Texte & Bilder kann und soll man natürlich weiterhin auf sozialen Netzwerken wie Facebook, Twitter, Instagram usw. teilen – doch die zentrale Drehscheibe für allen Content sollte die Website bleiben. Eine gute Backup-Strategie ist natürlich Pflicht! So bleibt man unabhängig von Fremdanbietern und kann sich drauf verlassen, dass die Daten jederzeit woandershin transferiert werden können. In diesem meinem Weblog hab ich etwa alle Beiträge seit dem Start im August 2000(!) versammelt, da ich stets die Daten von einem System ins nächste konvertieren konnte – selbst wenn das einmal gewählte CMS nicht mehr weiter entwickelt wird, kann man die Daten weiter verwenden.

Natürlich ist es ziemlich doof von Dennis Cooper, dass er offenbar in 14 Jahren Blogger kein einziges Mal die eingebaute Backup-Funktion genutzt hat, mit der man alle Daten auf den eigenen Rechner herunterladen kann. Denn dieses Backup könnte er nun in eine selbst gehostete WordPress-Website importieren (wie auch die Backups z.B. von Livejounral, MovableType, TypePad, Tumblr…) – die Website-Adresse wäre zwar weg, aber der Schaden hielte sich wenigstens in Grenzen.

Übrigens ist JETZT der richtige Zeitpunkt, um seine Daten von Facebook, Blogger, Twitter herunterzuladen und wenigstens zu sichern. Damit nicht alles weg ist.

Fragen, Anmerkungen und Deine Meinung zum Thema – ab in die Kommentare! Und natürlich helfe ich gerne, eine zukunftssichere Webpräsenz aufzubauen oder die Daten von woanders zu übernehmen.

Nachdem ich bereits einige Jahre gebloggt hatte, begann die damals verwendete Blogsoftware Sunlog an ihre Grenzen zu stoßen. Eines der Hauptprobleme war, dass zu dieser Zeit Kommentarspam begann, ernsthaft zu einem Problem zu werden. Ich musste manuell 20, 30, manchmal 50 Kommentare pro Woche händisch löschen (aktuell sinds auf diesem Blog 400, die automatisch gefiltert werden – pro TAG!).  Weiters wurde die Datenbank immer fetter, das Blog wurde immer langsamer. Als schließlich der Entwickler von Sunlog die Weiterentwicklung endgültig einstellte, war ich auf der Suche nach einer Alternative. Die pragmatische Lösung war, alle damals verfügbaren Kandidaten (ich erinnere mich an WordPress, MovableType, Textpattern und Serendipity) auf meinem Server installiert und probiert, wo die bisherigen Sunlog-Einträge am elegantesten zu importieren wären. Dass es WordPress wurde, war aber letztlich eine Bauchentscheidung. Nach einigen Wochen Herumprobieren, bis ich die Template-Logik halbwegs begriffen hatte, habe ich am 22.2.2006 mein altes Weblog mit Sunlog vom Netz genommen und WordPress freigeschaltet.

Lange Zeit blieb allerdings das Weblog der einzige Bereich meiner Website, der mit WordPress betrieben wurde – die Kundenprojekte gingen halt immer vor. Im Laufe der Jahre lernte WordPress neue Dinge, für viele davon bin ich ziemlich dankbar. Etwa den Menü-Editor – es war am Anfang etwas umständlich, Menüs in den Seitenvorlagen zu definieren. Und bei mehreren Menüs wars überhaupt ziemlich mühsames Gefrickel. Auch die automatischen Updates des WordPress-Kerns haben anfangs nicht immer reibungslos funktioniert und führten zu weißen Websites – sonst wurde nix mehr angezeigt. Mittlerweile kann man sich ruhig trauen, diese Funktion eingeschaltet zu lassen, denn wenn es tatsächlich Sicherheitsupdates gibt, werden diese so automatisch installiert. Ich hatte seither nie mehr(!) Einbrüche in WordPress-Websites, die über Lecks im Kern stattgefunden haben! Dafür, dass manche Plugin-Entwickler Blödsinn verzapfen, kann WordPress nix ;-)

Mittlerweile sind es weit über 200 WordPress-Websites, an denen ich arbeiten durfte: als Komplettdienstleister, als Programmierer, als Webdesigner oder auch als Pannenhelfer nach Einbrüchen oder Server-Crash. Die besten Ideen, was man mit WordPress alles machen kann, kamen von meinen Kunden – herzlichen Dank dafür. Durch eure Anregungen und Ideen bin ich tief in die Eingeweide von WordPress abgetaucht, mittlerweile gibts kaum eine Herausforderung, die ich damit nicht lösen könnte (mit Ausnahmen – siehe FAQ).

Ich freue mich auf DEINE Anfrage: Frag mich, vielleicht gehts!

Editthispage war quälend langsam, bereits im Mai 2001 folgte daher der Umzug auf den eigenen Server. Die dafür verwendete Software hieß Greymatter und war ein Open-Source-Sammelsurium an Perl-Scripts, die alle Seiten des Weblogs als statische Seiten renderte. Beim Speichern eines Beitrages musste man daher auch die Archivseiten neu erstellen lassen – mühsam und zeitaufwändig. Die alten Beiträge aus editthispage-Zeiten habe ich allerdings nie in Greymatter importiert oder übernommen. Anfang 2002 wurde die Weiterentwicklung von Greymatter eingestellt, es folgte die Umstellung auf Sunlog – erstmals ein System auf Basis von php und mySQL-Datenbank. Dafür habe ich im Lauf der folgenden vier Jahre einige Erweiterungen und Hacks beigesteuert, aber der Entwickler hat irgendwann auch die Arbeit daran eingestellt.

Daher war ich 2006 wieder auf der Suche nach einem Blogsystem. Es gab etliche Möglichkeiten für einen Umstieg, denn die Softwarelandschaft war deutlich gewachsen. So hab ich die damals am meisten verwendeten Systeme Textpattern, Movable Type, Serendipity und das relativ neue WordPress auf meinem Server installiert und getestet, wie schmerzfrei sich meine alten Sunlog-Beiträge übernehmen lassen. Angenehmerweise waren sich die Beitragstabellen von Sunlog und WordPress ziemlich ähnlich, daher war der Umstieg recht einfach möglich. Auch hat mir die Benutzeroberfläche von WordPress am Besten zugesagt, es war also eine reine Bauch-Entscheidung, dass ich damals auf den heutigen Marktführer gesetzt habe – es hätte auch ganz anders kommen können… ;-)

In diesen 15 Jahren habe ich hier knapp 2.000 Beiträge veröffentlicht. Man kann sich hier also eine ganze Zeitlang festlesen, wenn man will. Ich habe gute Kunden gewonnen, wichtige Kontakte geknüpft, unglaubliche Menschen kennengelernt und viel gelernt. Und ich habe mindestens 25 Menschen zum Bloggen animiert.

Danke, Weblog. DAS Weblog.

Einziger Punkt, der mir noch dabei gefehlt hat: wenn man position:absolute; im Stylesheet verwendet, so muss man diese Angabe durch position:static; ersetzen.

Nachdem dieses Problem nun zwei Mal kurz hintereinander bei Kundenwebsites aufgetaucht ist, die ich Facebook-fit machen sollte, habe ich mich schlau gemacht, wie man Facebook dazu bringt, diese Informationen einfach neu von der betreffenden Website abzuholen.

Das geht ganz einfach – wenn man weiß, wie:

Facebook bietet ein Tool namens „Sharing Debugger“ an (das hieß früher „URL Linter“) . Dort gibt man eine Seitenadresse ein und klickt auf „Fehlerbehebung“ – dann zeigt Facebook die für diese Seite zwischengespeicherten Informationen an. Wenn man dann auf „Erneut scrapen“ klickt, holt Facebook die Infos zur betreffenden Website frisch von deren Server ab und bietet eine Vorschau, wie die Website-Inhalte auf Facebook beim Teilen angezeigt werden.

Netterweise überschreiben die abgeholten Daten den Facebook-Zwischenspeicher – wenn also eine Seite zickt, kann man sie entsprechend umbauen, URL in den Debugger, Ergebnis prüfen – und auch alle anderen, die ab diesem Zeitpunkt die Website-Adresse teilen, kriegen die aktualisierten Daten geliefert. Die META-Description einer Website wird z.b. als Beschreibungstext verwendet, so kann man also gezielt bestimmen, was Facebook dort anzeigen soll. Wers ganz genau wissen (und gestalten) will, der kann anstatt META-Description & Co. auch die Facebook-OpenGraph-Metatags im Seitenkopf verwenden, die sich etwa mit Plugins wie All In One SEO in WordPress ziemlich einfach einbauen lassen.

Für LinkedIn gibts ein ähnliches Tool, das nennt sich dort „Post Inspector“ und funktioniert sehr ähnlich: URL eingeben, „Inspect“ klicken, die Informationen werden live von der URL abgeholt und der Link-Cache für LinkedIn wird dabei automatisch erneuert. Diese beiden nützlichen Werkzeuge (und noch viele mehr) finden sich stets aktuell auf meiner Linkliste „Online-Tools“.

Es gibt auch die Möglichkeit, mehrere Domains mit einer einzigen Installation zu bespielen. Dazu benötigt man das WordPress MU Domain Mapping Plugin und nochmal 15 Minuten Handarbeit an den Quellcodes. Die genaue Anleitung dazu gibts ebenfalls auf thingybob.de. Grade eben eingerichtet, funktioniert einwandfrei.

Der Tipp der Expertin: man sollte nur Themes aus zuverlässigen Quellen verwenden. Beispielsweise kann man auf diesen  Websites fündig werden:

• Theme Shaper
• ThemeLab
• Theme Hybrid
• Arras Theme
• Smashing Magazine

Mit den folgenden Plugins kann man Themes auf möglichen Schadcode prüfen:

• Theme Authenticity Checker
• Exploit Scanner
• Theme Check

Wenn man base64-codierte Zeilen in einem Theme entdeckt hat, kann man diese mit folgenden Tools decodieren:

• $o= Ottoâ€s decoder
• $_F=__FILE__:
• eval(gzinflate(base64_decode('...')));:
• eval(str_rot13(' ... '));
• Other codes
• Manual base64 decode

Eine sichere Quelle für dein persönliches WordPress-Theme ist die EGM-Website-Werkstatt. Denn meine Vorlagendateien sind zwar nicht kostenlos, dafür sind sie auf dich oder deine Firma maßgeschneidert und enthalten keinerlei Schadcode. Garantiert :-)