Sieht man aber genauer unter die Oberfläche, merkt man dann doch den einen oder anderen Unterschied – um nur einige zu nennen:

• Wie elegant lassen sich komplette Umänderungen im Layout und den Anwender-Funktionalitäten durchführen
• Welche komplexen Möglichkeiten sind bereits in der Admin-Oberfläche untergebracht, ohne Eingriffe in den PHP-Skripts oder CSS-Dateien erforderlich zu machen
• Wie rasch wird die Seite an den Besucher ausgeliefert (soll auch für das Google-Ranking relevant sein)
• Gibt es ein relative hohe Wahrscheinlichkeit (100%-ige Sicherheit wird es nie geben), dass das Theme auch für zukünftige WordPress-Versionen weitergepflegt wird
• Und nicht zuletzt: Wie bzw. wie rasch erhält man professionellen Support bei spezifischen Detailfragen (insbesondere für Geschäftssites unumgänglich)

Insbesondere wegen des letzten Punktes hatte für mich eine deutschsprachige Entwicklung Vorrang – die Suche nach geeigneten Premium Themes gestaltete sich aber anfänglich gar nicht so einfach.

Während es am englischsprachigen Markt (den ich natürlich nie gänzlich ausschließen würde, wenn meine sonstigen Qualitätsanforderungen erfüllt werden würden) massenhaft Premium Themes – auch relativ preisgünstige (hoffentlich nicht billige) – gibt, scheint die deutschsprachige WordPress-Entwicklergemeinschaft eine kleine, aber wohl feine und eingeschworene Gemeinschaft zu sein, da hier sehr gerne untereinander verlinkt wird.

Die für mich letztlich beste Ausgangsadresse fand ich bei „Perun“ (Vladimir Simovic), von dem ich auch ein WordPressbuch besitze.

Und dann ging das Demo-Schauen, Testen und Vergleichen erst richtig los.

Am Ende habe ich mich für folgende 3 Anbieter entschieden:

1. DER PRiNZ – Michael Oeser
2. xTreme One – Framework
3. ThemeShift – Simon Rimkus

Welche Themes im einzelnen ich bei diesen Anbietern gekauft habe sowie über meine ersten Eindrücke und Erfahrungen werde ich in einem späteren Artikel berichten.

Schöne Grüße – Christian

Zumal ich nach dem Wühlen in meinen (nicht allzu zahlreichen) alten Einträgen doch den einen oder anderen guten Tipp entdeckte, der mir in der Zwischenzeit schon wieder entfallen war.

Ich habe ja schon des Öfteren über meine Suche nach einem idealen CMS berichtet – und was habe ich da in der Vergangenheit nicht schon alles getestet (Joomla, Typo3, DotNetNuke). Aber richtig warm wurde ich mit keinem dieser Systeme.

Ich möchte mich nicht erst wochenlang eingehend mit technischen Belangen herumschlagen / ärgern.

Mir geht es in erster Linie um das Schreiben selbst – nicht zum Selbstzweck, sondern um Dinge später wieder halbwegs rasch zu finden.

Ein Content-Management-System (CMS) also nicht wegen der unübertroffenen Fülle an Spezialfunktionen oder wegen seiner genialen Designbarkeit wegen, sondern als einfach handhabbares Redaktionssystem zum systematischen, strukturierten und geordneten Sammeln und Verwalten meiner Daten, Gedanken, Ideen, Erfahrungen und Informationen – zum rascheren Generieren und Abrufen von Wissen.

Und bei der Suche nach einem Tool, welches mich bei diesem Vorhaben möglichst effizient unterstützen konnte, stieß ich eben wieder auf WordPress – ein Software-Werkzeug, welches ich bereits seit einigen Jahren sehr gerne zum Bloggen verwende (u.a. in AlpenYetis Wanderblog oder auf Wanderprofi.at).

Und ebendieses WordPress hat sich in den letzten Jahren Dank des bemerkenswerten Einsatzes vieler – häufig freiwilliger – Entwickler zu einem respektablen CMS entwickelt.

Die Bedienbarkeit ist vergleichsweise einfach, die Gestaltbarkeit im Gegensatz zu einer Eigenentwicklung, wie ich sie viele Jahre zuvor gepflegt hatte, um ein Vielfaches flexibler.

Die Installation ging bei einem Provider meines Vertrauens gewohnt unkompliziert, da automatisch, vonstatten.

Für 2 neue Projekte wollte ich mir dieses Mal aber ein sich von der Masse abhebendes „Kleid“ leisten – bei WordPress nennt sich dieses vom Inhalt unabhängige und getrennte Äußere „Theme„.

Tausende dieser Themes findet man kostenlos im Internet und ich habe mir eine ganze Arbeitswoche gegönnt, um einen Favoriten zu küren. Aber immer wieder klemmte es hier und da.  Kleinigkeiten in der Bedienung oder im Layout oder auch gröbere Unverträglichkeiten mit dieser oder jender Browserversion.

Also habe ich mich dazu durchgerungen, für professionelle WordPress Premium Themes einen in Summe zwar nicht mehr kleinen, angesichts der schon bald erzielbaren Arbeitsersparnisse aber durchaus angemessenen Obulus im unteren dreistelligen Euro-Bereich aufzubringen.

Der größte Aufwand war ohnehin eine weitere Arbeitswoche für die Auswahl der mir am geeignetsten scheinenden Premium-Theme-Kandidaten.

Dass ich angesichts zu erwartender Detailfragen und nervenden Spezialproblemen im professionellen Einsatz auf deutschsprachigen Support Wert legte, erleichterte die Suche nicht unbedingt.

Aber ich wurde fündig (Siehe oben: Dreistelliger Euro-Bereich ;-)) und bin teilweise auch recht bis sehr zufrieden.

Warum nur recht zufrieden?

Nun – der erwartete Ärger blieb natürlich im speziellen Einzelfall nicht aus und nun versuche ich „Workarounds“ über den Support zu erfragen.

„Nur recht zufrieden“ auch deshalb, weil man entgegen der Marketingaussagen auch nach wie vor solides Grundwissen über HTML und CSS mitbringen sollte bzw. die Mächtigkeit einiger Werkzeuge doch eine längere Einarbeitungszeit erfordert, auch wenn vorher im Beispielvideo alles so kinderleicht ausgesehen hat.

Im nächsten Artikel werde ich dann etwas näher auf die von mir erworbenen Premium Themes eingehen, die mir erlauben sollen, WordPress etwas abseits der großen Masse als CMS einzusetzen.

Bis dahin

Schöne Grüße – Christian

„Einfach“ vor allem auch deshalb, weil meine Webhoster allesamt Software-Installationsroutinen bereitstellen, mit denen man eine Vielzahl von Webprogrammen automatisiert und ohne tiefere Kenntnisse installieren kann. Ein großer Vorteil, wenn man gleich mit den Inhalten loslegen möchte. Unter Umständen aber etwas tückisch, wenn einmal etwas nicht mehr „von der Stange“ funktioniert oder eben Umzugsarbeiten anstehen.

Dann schadet es zumindest nicht, wenn man sich auch die manuelle Installation etwas näher ansieht, jenseits vom bloßen Installations-Mail, in welchem die Zugangs-Kennwörter übermittelt werden.

Wie so oft führen auch bei WordPress viele Wege nach Rom, nachfolgend beschränke ich mich aber auf eine „normale Standard-Installation auf einem lokalen Rechner“.

1.) Die Voraussetzungen – Komponenten

Für den Betrieb von WordPress benötigst Du folgende Komponenten:

a) Webserver

• Apache als Webserver
• PHP
• MySQL
• FTP-Programm

Falls Du diese Programme und Technologien noch nicht installiert hast (selbst wenn Du sie von Deinem Provider zur Verfügung gestellt bekommst, empfehle ich Dir auch eine lokale Installation auf Deinem Rechner) kannst Du sie kostenlos aus dem Internet downloaden. Hier habe ich mein XAMPP-Paket herunter geladen.

b) WordPress

Das WordPress-Installationspaket samt umfangreicher Hilfestellung gibt es u.a. auf http://wordpress-deutschland.org/

Ich habe mich gleich für die erweiterte deutschsprachige Version entschieden. Die Datei liegt im gezippten Format vor und hatte beispielsweise bei der aktuellen Version 2.9.2 eine Größe von knapp über 2,5 MB. Die entpackten Dateien (in Summe 82 Verzeichnisse und 763 Dateien) werden später eine Größe von knapp über 8 MB haben.

c) Tools

Entpack-Programm zum Entzippen der WordPress-Datei.

2.) Der Webserver

Ich gehe hier davon aus, dass der Webserver bereits installiert ist und läuft.

Da ich mein XAMPP-Paket auf einem Windows-Rechner betreibe, hatte ich zunächst Probleme, weil ich standardmäßig den Internet-Information-Server IIS aktiviert hatte und bei Aufruf von localhost erhielt ich deshalb zunächst nicht das gewünschte Ergebnis.

Also mußte ich erst einmal den IIS stoppen: Aufruf je nach Betriebssystem und Konfiguration.

Einstellungen => Systemsteuerung => Verwaltung => Internetinformationsdienste-Manager.

Rechte Maustaste auf den Rechner => Beenden

Danach Start des Apache-Webservers, der MySQL-Datenbank und des FTP-Dienstes FileZilla über das XAMPP Control Panel.

XAMPP_Control-Panel

Der Aufruf von localhost im Browser liefert jetzt gleich ein anderes (nämlich das gewünschte) Ergebnis.

 3.) Die Datenbank-Installation

Wenn Du im Webbrowser localhost aufrufst (vorausgesetzt es läuft der Apache-Webserver) hast Du links in der Menüleiste einen Abschnitt „Tools“ und darunter das Programm phpMyAdmin.

phpMyAdmin: Tool zum Verwalten von MySQL-Datenbanken

(Benutzername und Passwort wurden bei der Installation von XAMPP festgelegt bzw. können vom externen Hosting-Provider bezogen werden).

Anlegen einer neuen MySQL-Datenbank:

4.) Die WordPress-Installation

a) Entpacken

Zunächst gilt es, die runtergeladene WordPress-Datei zu entzippen.

Danach haben wir folgende Verzeichnisstruktur vor uns:

3 Ordner und eine Reihe von Dateien im Root-Verzeichnis.

b) Konfigurationsdatei

Im nächsten Schritt müssen wir die Konfigurationsdatei erstellen. Dazu kopieren wir die im WordPress-Root-Verzeichnis liegende Beispieldatei wp-config-sample.php auf den Namen wp-config.php und öffnen sie mit einem einfachen Texteditor wie Notepad (kein Textverarbeitungsprogramm wie Word verwenden, da hier Steuerzeichen eingefügt werden könnten).

Hier ersetzen wir die Dummy-Einträge durch unsere eigenen Angaben für folgende Datenbank-Zugangswerte:

• Datenbankname
• Datenbank-Benutzer
• Benutzer-Passwort

c) Upload

Als nächstes werden diese Verzeichnisse und Dateien per FTP auf den Webserver upgeloadet. Da wir uns hier aber auf eine lokale Installation beschränken wollen, genügt es, die Dateien in das „XAMPP-Verzeichnis“ zu kopieren, und zwar unter das Unterverzeichnis htdocs (wirklich herrlich einfach).

d) Installationsstart

Danach starten wir den eigentlichen Installationsvorgang, in dem wir im Browser die Datei install.php aufrufen.

Diese befindet sich ausgehend von „WordPress-Root“ im Verzeichnis wp-admin.

Also beispielsweise: http://localhost/wordpress/wp-admin/install.php)

(Solltest Du die WordPress-Struktur direkt nach htdocs gespielt haben, würde der Aufruf folgendermaßen lauten: http://localhost/wp-admin/install.php).

Folgende Maske wird geöffnet:

Der Blogtitel kann später jederzeit geändert werden, ist also derzeit nicht so wichtig. Wichtig hingegen ist die E-Mail-Adresse, da dorthin die Zugangsdaten versendet werden. Sie werden aber auch bei der abschließenden Erfolgsseite (Siehe weiter hinten) auch am Bildschirm angezeigt.

Das abschließende Kästchen „Blog in Suchmaschinen bekannt machen“ wählen wir für die Test-Installation nicht aus.

Nach wenigen Augenblicken erscheint bereits (hoffentlich) die Erfolgsmeldung: Notiere Dir die Zugangsdaten zum Blog (User admin und Zufallspasswort).

Klicke auf die Schaltfläche „Anmelden“, gib die zuvor notierten Zugangsdaten ein und schon befindest Du Dich im Administrationsbereich von WordPress.

Oben erscheint in roter Warnfarbe die Empfehlung, das Passwort zu verändern, was wir auch sofort machen wollen.

5.) Datenbank-Hintergrund

Obwohl es (vorerst) nicht so wichtig ist, wollen wir dennoch einen kurzen Blick auf die Datenbank werfen.

Welche Tabellen wurden durch die Installation im Hintergrund erstellt:

6.) Einloggen

a) Administrationsbereich

In den Administrationsbereich kannst Du auch später jederzeit gelangen, indem Du an die WordPress-Adesse wp-admin anhängst: http://localhost/wordpress/wp-admin

b) Benutzersicht

Der „normale“ Internet-Besucher ruft den WordPress-Pfad auf (also z.B. http://localhost/wordpress)

7.) Bloggen

Glückwunsch !

Dem Verbreiten Deiner geistigen Ergüsse in Form eines Weblogs steht nun nichts mehr im Wege.

Ich wünsche Dir viele gute Ideen und zahlreiche Leser.

Schöne Grüße – Christian

Irgendein angenehmes, beschauliches und vor allem konstruktiv-produktives Thema wie

• „Datenbank-Entwicklung: Vom Access-Anwender zum Navision-Programmierer“ oder
• „Die 10 besten Tipps zum Schreiben eines E-Books„.

Aber auch Themen wie

• „Wer gestaltet die besten Webseiten – der Wandel vom Designer über den Programmierer zum Redakteur“ oder noch weiter gefasst,
• „Wie sollte anwenderfreundliche Software aussehen?„

brennen mir schon lange Zeit unter den Nägeln (so sich dort nicht allzu viel Schmutz von meinen Bergtouren angesammelt hat).

Ganz zu schweigen von allgemeinen (EDV-)philosophischen Fragen wie

• „Ich sehe die Information vor lauter Daten nicht – ertrinken wir in der Datenflut?“ oder wieder etwas näher an meinem Hobby – der Naturfotografie – gelegen:
• „Soviele digitale Fotos und Videos wie noch nie – doch was wird davon bleiben?„

Aber nein: Ein anderes Problem gilt es im 1. Blogartikel zu behandeln. Seit dem Beginn meines Hosting-Provider-Wechsels am Freitag (09.10.) abend komme ich derzeit nur noch sporadisch zum Schlafen. Letzte Nacht wurde es wieder 3 Uhr früh, und am frühen Morgen ging es wieder weiter – ohne Urlaub wäre das gar nicht möglich und recht traurig bin ich über das aktuelle trübe Wetter auch nicht.

Und bei diesen Umzugsarbeiten bestätigt sich wieder einmal die 80-zu-20-Regel (Pareto-Prinzip). 80% der Umstellungsarbeiten konnte ich in vermutlich 20% der Arbeitszeit erledigen.

Die ersten 70.000 Dateien wurden problemlos auf den neuen Webspace bei All-Inkl übertragen. Nur 2 kurze FTP-Abstürze, im Vergleich zu bisherigen Erfahrungen – vor allem bei meinem vorvorigen Anbieter – ein Traumergebnis, welches eine sehr positive Zusammenarbeit für die Zukunft verspricht.

Aber dann begann es sich zu spießen. Wobei ich aber auch dazu sagen muß, dass es sich bei den problemlosen Seiten fast ausschließlich um HTML-Seiten handelte. Hier hat sich meine Strategie, den Webauftritt programmiertechnisch so einfach wie nur möglich zu halten, voll bewährt. Diese Massen-Informationen könnte ich auch jederzeit problemlos auf DVD brennen und dann auch Offline auf einfachsten Endgeräten nutzen.

Der nächste Schritt war das Übertragen der ersten, einfach gehaltenen ASP.NET-Seiten. Der VB.NET-Code war rasch in PHP umgesetzt und die Seiten laufen ebenfalls schon.

Aufwändiger wird es natürlich dort, wo Datenbankzugriffe im Spiel sind. Diese Programm-Umstellung vom MS-SQLServer auf mySql wird sich mit Sicherheit noch etliche Wochen ziehen.

Aber das ist alles noch Zukunftsmusik. Den aktuell größten Brocken stellt derzeit der Transfer meines Wanderblogs auf den neuen Server dar. WordPress – eigentlich doch Standardsoftware. Eigentlich …

Bis gestern früh war ich mehr oder weniger zufriedener WordPress-Anwender.

Hä, hä: Wie ist dieser Satz jetzt zu lesen, wo liegt die Betonung – und daraus abgeleitet der Sinn.

• War ich Benutzer dieses Blog-Systems und bin es jetzt nicht mehr?
• War ich mehr oder weniger mit WordPress zufrieden und bin ich es jetzt weniger oder mehr?

Nichts von beidem: Ich war WordPress-Anwender und habe mich notgedrungen und unfreiwillig in den letzten 1 1/2 Tagen tiefer in die Materie einarbeiten müssen, als es mir lieb war und ist. Jetzt fühle ich mich bereits als WordPress-Halblaie.

• Intallieren neuer Systeme für Wanderblog, Fotoblog und diesen IT-Blog. Datenbank und Frontend. 
• Basis-Konfiguration der Oberfläche. Wie war das schnell noch. Was muß ich da alles einstellen? Beim letzten Mal war alles so klar, dass ich mir das sowieso nicht notieren muß. Denkste. Mein zunehmend löchriges Hirn scheint doch schon älter zu sein, als ich wahrhaben will.
• Sichten und Austesten dutzender neuer WordPress-Themes, da das Layout bei meinem bisherigen Wanderblog ja ziemlich bescheiden war. Da paßt diese Kleinigkeit nicht, dort ist jener kleine Fehler. Ganz zufrieden bin ich ohnehin noch immer nicht (vor allem mit dem Layout für diesen Blog).
• Draufkommen, dass sich die meisten Themes durch Widgets anpassen lassen.
• Nächstes Theme austesten. Wie war das noch schnell beim letzten, das hat das ja gar nicht so schlecht ausgesehen. Keine anstrengende, aber eine zeitraubende Tätigkeit. Lästig. Aber das Auge isst ja mit, also wird die Optik schon wichtig sein. Nur blöd, dass diese Weisheit noch nicht zu Google durchgedrungen ist. Hätten die diesen Designer-Marketingschmäh Ernst genommen, würde es das erfolgreichste Internet-Unternehmen aller Zeiten gar nicht geben. Aber ich weiche vom Thema ab.
• Apropos Google. Wie war das noch? Irgendwo muß ich ja meinen Code für Google-Analytics einbauen. Natürlich auch nicht aufgeschrieben. Oder zumindest kann ich es nicht spontan finden. Aber Google sei Dank einige Super-Ratschläge in den Google-Ergebnisseiten. Auch ohne „tolles Design kreativer Köpfe“ (ein Zitat, welches ich unlängst in einer Werbe- und Internetagentur gehört habe).
• Aber bleiben wir beim Thema – und den unfreiwillig tieferen Erfahrungen mit WordPress. Im Vorbeigehen habe ich feststellen müssen dass die integrierte „Backup-Funktion“ mittels XML-Export völlig untauglich ist.
• Wie macht man dann ein „richtiges Backup“. Ich weiß – ist etwas spät. Eigentlich fahrlässig. Egal.
• Backup erstellt und beim neuen System eingespielt. Hoppala, jetzt habe ich alle Tabellen im Zielsystem plötzlich doppelt. Aha, anderes Tabellen-Präfix. Du verstehst nur Bahnhof. Ging mir auch so.
• Zwischendurch wieder einmal ein neues Theme ausprobiert. Zuerst auf einem Testsystem. Achja, deren 2 bis 3 habe ich so nebenbei ja auch noch installiert.
• Da merk sich einer einmal die vielen Passwörter für WordPress-User, Datenbanken, FTP-Zugänge, …
• Themes-Testlauf OK, also einmal beim alten Wanderblog ausprobiert. Absturz – nix geht mehr. Nur gut, dass ich kurz zuvor einem Wanderkameraden einen Link zum Wanderblog geschickt hatte, wo er sich schnell aktuellste Bilder anschauen könnte. Sehr professionell …
• Keine Chance, den Blog wieder zum Laufen zu bringen. Wo steht denn der Hinweis auf das aktuelle Theme. Einige PHP-Dateien durchstöbert. Nix gefunden. In der Datenbank nachgeschaut. Wenigstens gibt es nicht allzu viele Tabellen. Die richtige ward schnell gefunden. Eintrag korrigiert. Geht noch immer nicht. Sch…ade.
• Theme-Verzeichnis im Upload-Verzeichnis gelöscht. Jetzt funktioniert es wieder.
• Wo war denn noch schnell der Punkt zum Einstellen suchmaschinenfreundlicher Beitragsnamen? Das klär ich später.
• Was man aber gleich erledigen sollte, ist die Änderung der Vorgabe-Passwörter. Oder noch besser gleich eigene User anlegen.
• Dann gab es da ja noch eine Option, dass mir nicht jeder sofort den Blog mit Spam-Kommentaren zumüllen kann.
• Jetzt aber zurück zum Fall mit den verschiedenen Tabellen-Präfixen. Könnte man das nicht irgendwo in einer config-Datei umstellen. Kann man. Allerdings funktionierte dann nichts mehr. Also wieder zurückstellen.
• OK – noch einmal von vorne. WordPress-Backup am alten System erstellt. Dieses mal mit tauglicheren Mitteln und auf Testsystem eingespielt. Testsystem läuft nicht mehr. Dafür wird bei der Fehlerabarbeitung irgendwann automatisch zum Echtsystem umgeschalten. Hoffentlich haue ich mir jetzt nichts zusammen.
• Einer der Problemfälle könnte damit zusammenhängen, dass vorher mein WordPress-System auf einem Windows-Server lief und jetzt auf Linux.
• Wieder auf Verdacht in diversen Tabellen-Einträgen herumeditiert. Und siehe da, schön langsam läuft es. Fast. Einige kleinere Ungreimtheiten. Nicht so wichtig. Soll ich mir das jetzt alles zusammenschreiben. Neeeiiiin. Das ist doch eh alles klar, das merk ich mir schon (aber eigentlich glaub ich es mir ja selber nicht).
• Also gut, ich werde doch eine kleine Dokumentation erstellen. Aber wäre es nicht sinnvoll, dass so nach und nach in einer Blog-Serie zu erfassen. Dann hätten eventuell auch andere Leidensgenossen etwas davon. Und irgendwann könnte ich es ja dann in „Schönschrift“ zusammenschreiben.

So, jetzt wisst Ihr also, wie der erste Artikel in diesem Blog zustande kam. Nur lief das Szenario in Echtzeit bei weitem nicht so „strukturiert“ ab, wie hier geschildert ;-).

Und Ihr habt auch eine grobe Vorstellung, was Euch an dieser Stelle in den nächsten Wochen erwarten wird (könnte).

Schöne Grüße – Christian