Archiv für das Jahr: 2015

WordPress WooCommerce Shop Titel „Produkte Archiv“ ändern

WordPress WooCommerce Titel Produkte Archiv anpassen

WooCommerce: Seitentitel "Produkte Archiv" anpassen - Foto: T.Bortels/cpu20.de

WordPress mag vielen vor allem als Blog Tool bekannt sein. Mit WordPress lassen sich inzwischen aber auch ganz andere Sachen bauen – zum Beispiel lassen sich mithilfe des kostenlosen WordPress Plugins WooCommerce Online Shops erstellen. Die Kombination aus WordPress und WooCommerce steckt mittlerweile sogar sogar hinter ca. einem Drittel aller Online Shops. Das WooCommerce Plugin ist zunächst einmal kostenlos – und lässt sich relativ einfach installieren. Wenn es dann an Detailfragen geht, kann es schnell etwas kompliziert werden. Wir picken uns mal ein Detail heraus: den Seitentitel der Shop Seite.

Bei einem neu eingerichteten WooCommerce-Shop wird als Seitentitel der ‚Startseite‘ des Shops häufig zunächst der Standardtitel „Produkte Archiv“ angezeigt. Das fällt dem ambitionierten Webshop-Betreiber vielleicht erstmal gar nicht weiter auf – immerhin lässt sich der Titel der Seite, der auf der Seite angezeigt wird, direkt anpassen. Der Seitentitel, der später in den Suchergebnissen zum Beispiel bei Google oder DuckDuckGo zu sehen ist, wird häufig erstmal übersehen. Vielleicht wissen auch viele Shop Betreiber gar nicht, dass sie den Seitentitel relativ einfach ändern können – und das der Seitentitel ein ganz wichtiges Detail sein kann, das über Erfolg oder Misserfolg eines Online Shops entscheiden kann? Langfristig ist der generische Seitentitel „Produkte Archiv“ jedenfalls keine gute Wahl. Vermutlich gibt es hunderte oder sogar tausende Standard WooCommerce Installationen mit genau demselben Titel, der absolut nichts über den Shop aussagt. Das hat einerseits einen negativen Einfluss auf das SEO-Ranking – und andererseits hilft es potentiellen Kunden nicht, wenn sie die Seite in den Suchergebnissen sehen. Wer den Seitentitel nicht anpasst, verschenkt SEO-Potential.

WooCommerce Shop Titel „Produkte Archiv“ mit Yoast ändern

Grundsätzlich sollte sich jeder Shop-Betreiber früher oder später Gedanken über Suchmaschinenoptimierung machen. Wer seinen Shop in der Kombination WordPress+WooCommerce betreibt ist mit dem SEO-Plugin Yoast auf jeden Fall schon mal ganz gut beraten. Und mithilfe von Yoast lässt sich der Seitentitel eines WooCommerce Shops zum Glück auch relativ einfach so anpassen, dass er zum Shop bzw. zu den angebotenen Produkten passt. Gut für die Kunden, gut für SEO, gut für den Shop.

WordPress WooCommerce Shop Titel Produkte Archiv mit Yoast aendern

Screenshot: Shop Titel „Produkte Archiv“ mit Yoast aendern

Um den Seitentitel nun zu bearbeiten geht man wie folgt vor:

  • Zunächst in der Menuleiste (links) über den Link „SEO > Titel & Metas“ die Seite mit den Voreinstellungen für Seitentitel und Meta-Tags aufrufen.
  • Dann wählt man oben den Seitenreiter „Artikeltypen“ aus. Ganz unten sollte dann der Bereich „Archive von Artikeltypen“ zu sehen sein.
  • Hier kann man dann den gewünschten Shop-Titel direkt in das Feld „Titel“ eintragen. Und fertig ist die Laube.

Update: Manche WP-Themes scheinen sich dem oben aufgeführten Trick zu widersetzen. Beim WP-Theme Explore zum lässt sich zum Beispiel zwar der Seitentitel anpassen, oben in der Browserleiste zu sehen ist – die Überschrift der Shop-Seite bleibt aber hartnäckig bei dem Begriff „Archiv„. Aber auch dieses Detail lässt sich mit einem Griff in die Plugin-Trickkiste anpassen: mit dem kostenlosen Übersetzungs-Plugin „Loco Translate“ lassen sich im Prinizip alle vom Theme verwendeten Begriffe übersetzen – und vorhandene Übersetzungen ändern. Und so kann man dann auch der Shop-Seite einen eigenen Titel bzw. eine eigene Überschrift geben, die zum Shop und zu den angebotenen Produkten passt.

siehe auch:

WordPress als CMS: Seiten-Management (CPT)

WordPress CMS - Seiten Management Plugins

WordPress CMS - Seiten Management Plugins - Photo/Montage: T.Bortels/cpu20.de

Es ist durchaus möglich und sinnvoll, WordPress als CMS zu betreiben. Früher oder später muß man allerdings feststellen, dass WordPress ursprünglich leider nicht wirklich dafür vorgesehen war, als Content Management System betrieben zu werden. Ein Problem bei der Sache können die statisches Seiten (Pages) sein – insbesondere, wenn man es mit vielen in ineinander verschachtelten Seiten zu tun hat. Manchmal muss man hunderte oder sogar tausende Seiten verwalten – häufig über Parent-Child-Verknüpfungen zu ganzen Seiten-Bäumen verknüpft. Für viele Webseiten macht es zudem Sinn, neben den Standard-Seiten noch eigene Seitentypen einzurichten, die sogenannten Custom Post Types (CPT). Dann wird die Sache noch interessanter.

WordPress CMS Härtetest: über 1000 CPT Seiten verwalten

Wenn man WordPress als CMS betreiben will hat man es wie gesagt häufig mit statischen Seiten zu tun. Oft spielt die Blog-Funktion dann eher eine Nebenrolle und die Pages spielen stattdessen die Hauptrolle. Je mehr Seiten oder sogar Seitenbäume man anlegt, desto schwieriger wird die Verwaltung. Das Seiten-Management läßt in vielen Punkten zu wünschen übrig.

Spätestens, wenn man es mit hunderten oder sogar tausenden Seiten zu tun hat, stößt man mit den Default-Funktionalitäten an seine Grenzen – die Bedienung wird einfach unhandlich. Kommen dann noch Hierarchien dazu, also verschachtelte Seiten, Hauptseiten und Unterseiten (Parent-Pages / Child-Pages) dann ist das Chaos buchstäblich vorprogrammiert.

In den letzten Jahren haben sich verschiedene WordPress-Entwickler dieses Themas angenommen und eine Reihe von Plugins entwickelt, die beim Seiten-Management helfen sollen. Einige machen ihren Job ganz gut, andere leider nicht. Ich habe mir 5 der besten bzw. beliebtesten und offenbar bekanntesten Plugin einmal näher angesehen, getestet und habe eine für meine Bedürfnisse passende Kombination gefunden. Hier der Überblick:

Plugin #1: Admin Collapse Subpages

Das Plugin Admin Collapse Subpages bringt mir leider keinen Mehrwert. Das Plugin fügt lediglich der Standard-Seitenansicht die Option „collapse“ hinzu, mit der sich verschachtelte Seiten etwas übersichtlicher darstellen lassen. Allerdings werden immer nur die Seiten eingeklappt, die in der gerade aktuellen Listenanischt aufgeführt werden.

Plugin #2: Advanced Page Manager

Das Plugin Advanced Page Manager sieht erstmal sehr vielversprechend aus. Allerdings stellt sich schnell heraus, dass das Plugin zurzeit leider keine eigenen Seitentypen (CPT) unterstützt. Daher kommt das Plugin zurzeit für mich nicht in Frage. Ansonsten scheint es aber recht komfortabel zu sein. Wenn man also ausschliesslich mit Ur-Seiten zu tun hat, kann man sich den Arbeitsalltag mithilfe des Advanced Page Manager vermutlich etwas leichter machen.

Plugin #3: Swifty Page Manager

Auf den ersten Blick macht der Swifty Page Manager einen sehr guten Eindruck. Die Organisation von Seiten erscheint übersichtlich. Hierarchisch geordnete Seiten/ Unterseiten lassen sich einfach ausklappen, neue Unterseiten lassen sich direkt erstellen. Und auch das Page-Template läßt sich direkt beim Erstellen wählen.

Seiten-Organisation mit swifty-page-managerFür meine Anwendung ist das Plugin aber leider zurzeit nicht geeignet Es lassen sich im Moment offenbar nur für Standard-Seiten organisieren – eigene Seitentypen (CPT) lassen sich  über Swifty Page Manager weder verwalten, noch bearbeiten. Und dies scheint erstmal auch nicht vorgesehen zu sein. Laut Entwicklern bestehen keine Pläne, Custom Post Types zu berücksichtigen „there are no plans for adding custom post types at this point“.

Ein schwacher Trost und Grund zu Hoffnung: das Plugin wird unter Open Source Lizenz vertrieben – es steht also theretisch jedem Entwickler offen, fehlende Funktionalitäten selbst einzubauen.

Plugin #4: CMS Tree Page View

Mithilfe des Plugins CMS Tree Page View  lassen sich auch komplexe Seiten-Bäume abbilden.

Seiten-Verwaltung mit cms-tree-page-viewAuch bei über tausend Seiten lädt die Übersicht schnell – die Unterseiten werden offenbar über eine entsprechende AJAX-Anfrage immer erst dann geladen, wenn die übergeordnete Seite „ausgeklappt“ wird.

Die Seiten-Übersicht erscheint insgesamt sehr reduziert und erinnert vielleicht ein wenig an Anwendungen aus den Neunzigern, wie zum Beispiel „Windows Explorer“ mit dem man relativ einfach die Baustruktur von Verzeichnissen auf einem PC überblicken und organisieren konnte.

Das Plugin unterstützt Custom Post Types – ein Punkt, der mir sehr wichtig war.

Die Sortierung von Seiten und Unterseiten per Drah’n’Drop kann ein bischen schwierig sein. Will man eine Seite verschieben, werden unter Umständen andere Seiten in der Nähe der „Abwurfstelle“ aufgeklappt. Gegebebenenfalls muss ein ein bisschen vorsichtig sein und nachträglich kontrollieren, wohin man die betroffene Seite nun wirklich gerade verschoben hat.

Plugin #5: Nested Pages

Die Benutzeroberfläche von Nested Pages ist vorbildlich übersichtlich. Und mit dem Plugin lassen sich auch CPT-Seiten verwalten. Das sind zwei Pluspunkte, die mich zunächst dieses Plugin nutzen ließen.

wp-nested-pagesAusserdem zeigt Nested Pages das SEO-Ranking des Plugins Yoast direkt in der Übersicht an – ein Feature, das ich gerne nutzen würde.

Allerdings hat Nested Pages einen entscheidenden Nachteil: die Seiten-Übersicht wird von vornherein komplett geladen, es werden aber nur die Parent-Seiten angezeigt. Bei über 1000 Seiten kann die Seiten-Übersicht daher entsprechend langsam laden. Ein Verschieben per Drag’n’Drop ist zwar auch dann noch möglich, aber sehr zäh.

WordPress als CMS – Seiten-Management Plugins Zusammenfassung

Wenn Nested Pages die Unterseiten über AJAX laden würde, wäre es für mich vermutlich das perfekte Plugin zum Verwalten von komplexen Seiten-Bäumen. In der aktuellen Version wird es mit zunehmender Seitenzahl aber leider immer unbrauchbarer.

Zur Verwaltung meines CPT-Seitenbaums verwende ich nun das Plugin CMS Tree Page View. Beide Plugins lassen sich offenbar aber auch parallel betreiben. Also werde ich erstmal auch Nested Pages noch weiter nutzen, um mir hin und wieder einen Überblick über den SEO-Status der Seiten machen zu können.

Abschliessend noch ein Hinweis: alle Plugins ließen sich beliebig aktivieren und deaktivieren. Im Zweifelsfalls kann man also die hier aufgeführten Plugins einfach mal selbst ausprobieren.

WordPress Version herausfinden leicht gemacht

WordPress Version herausfinden

WordPress Version - Montage: T.Bortels/cpu20.de

Manchmal muß man einfach schnell mal wissen, welche WordPress Version man eigentlich gerade verwendet. Gründe dafür gibt es viele – zum Beispiel um abschätzen zu können, ob  eine halbwegs aktuelle WordPress Version installiert ist und wie weit man ggf. von der aktuellen WordPress Version entfernt ist. Oder man möchte die Kompatibilität eines Plugins oder eines Themes im voraus prüfen. Oder man hat einfach nur eine technische Frage hat und will die WP-Version gleich mit der Frage angeben. Viele technische Fragen und Fehlermeldungen lassen sich einfacher nachvollziehen, wenn die verwendete Version bekannt ist. Insbesondere in Hilfe-Foren sollte man daher am besten immer auch gleich die verwendete WordPRess-Version sowie ggf. auch die Versionen der beteiligten PlugIns und Themes angeben.

WordPress Version im Administrationsbereich finden

Am einfachsten läßt sich die installierte WordPress Version herausfinden, wenn man im Administrationsbereich angemeldet ist. In früheren Versionen wird die Versionsnummer unten rechts angezeigt – in aktuelleren Installationen ist die Version im Dashboard unter „Auf einen Blick“ angezeigt – also zum Beispiel “ Version 4.9.8″.

WordPress Version mithilfe von readme.html / liesmich.html herausfinden

Es gibt aber auch Möglichkeiten, die WordPress Version herauszufinden, wenn man nicht angemeldet ist. Bei deutschen WordPress-Installationen gibt es im Stammverzeichnis die Datei „liesmich.html“ die man einfach direkt im Browser aufrufen kann: meinedomain/liesmich.html – und je nach Version kann diese Datei auch Informationen zur Version beinhalten und preisgeben.

Wordpress Version herausfinden

WordPress Version in liesmich.html

Wenn es sich nicht um eine deutsche WordPress-Installation handelt, sollte wenigstens folgende Datei im Stammverzeichnis zu finden sein, die quasi bei jeder Installation unabhängig von der Sprache mitinstalliert wird: readme.html. Auch diese Datei läßt sich direkt im Browser aufrufen: meinedomain/readme.html

Man sollte allerdings anmerken, dass manche Experten diese readme-Dateien für ein potentielles Sicherheitsrisiko halten und daher empfehlen, diese Dateien nach erfolgreicher Installation zu löschen. Angreifer könnten über diese Datei erfahren, welche WordPress Version installiert ist und geziehlt eventuell vorhandene Sicherheitslücken für Angriffe nutzen. Ich halte diese Argumentation aus zwei Gründen aber für undramatisch: Erstens sollte man grundsätzlich seine Wodpress-Installation aktuell halten und so dafür sorgen, dass eventuell vorhandene Sicherheitslücken schnellstmöglich geschlossen werden. Und zweitens gehe ich davon aus, dass die meisten WordPress-Angriffe sowieso automatisiert sind und sich kaum ein Hacker die Mühe machen wird, die readme-Datei aufzurufen.

Ein Blick in die Datei wp-includes/version.php

/**
 * The WordPress version string
 *
 * @global string $wp_version
 */
$wp_version = '3.8.4';

WordPress Version im Quellcode ablesen

Im Quellcode (HTML) lässt sich die aktuell installierte Version gleich an mehreren Stellen ablesen. In den meisten Standard-Installationen wird die WordPress Version als „Cache Breaker“ oder „Cache Buster“ z.B. an den Pfad von CSS-Dateien gehängt.

Daneben gibt es aber auch das Meta Tag „Generator“, das explizit die aktuell verwendete Version anzeigt – soweit diese Anzeige nicht durch ein Plugin unterdrückt wird. Das sieht dann zum Beispiel so aus:

<meta name="generator" content="WordPress 4.8.3" />

WordPress Version per PHP bzw. WordPress-Funktion herausfinden

WordPress bringt die Funktion get_bloginfo() mit, die viele verschiedene Details über die verwendete  WordPress-Installation verrät. Das kann vor allem für WordPress-Entwickler interessant sein – zum Beispiel, wenn man dynamisch die WordPress Version herausfinden möchte um sie entweder direkt anzeigen zu lassen, oder um beispielsweise die Kompatibilität eines Themes oder eines Plugins zu testen.

Die Funktion sieht prinzipiell wie folgt aus:

 <?php $bloginfo = get_bloginfo( $show, $filter ); ?> 

Dabei bestimmt $show was angezeigt werden soll und $filter wie es angezeigt werden soll. Für eine einfache Abfrage der WordPress Version wäre folgender Code ausreichend:

<?php 
    $wordpress_version = get_bloginfo('version'); 
    echo("Wordpress Version: ".$wordpress_version);
?> 

Wenn man diesen Code-Schnippsel beispielsweise in eine Template-Datei einfügt, zeigt WordPress die aktuell verwendete Version an.

Mehr zu der Funktion get_bloginfo(); hier im Codex:
https://codex.wordpress.org/Function_Reference/get_bloginfo

Social-Media-Buttons-Nutzen – oder nicht nutzen?!

Vor kurzem bat mich ein Kunde, doch bitte noch ‚diese kleinen Knöpfe‘ in seine Webseite einzubauen, bevor diese dann freigeschaltet werde. Ich rat ihm davon ab – er reagierte zunächst etwas verdutzt.

Ich mußte ihm meine Empfehlung, auf Social-Media-Buttons zu verzichten, natürlich erst mal etwas genauer erläutern. Das war zuerst nocht ganz einfach. Aber letztendlich ist die Frage, warum man keine Social-Media-Buttons nutzen möchte, ähnlich schwierig zu beantworten, wie die Frage nach dem Sinn und Zweck: Was bringen Social-Media-Buttons eigentlich? Und wem bringen sie was? Was sind die Vorteile – und was sind die Nachteile?

Social-Media-Buttons Nutzen

Beliebte Social-Media-Buttons mit Zähler

Zuerst muß man anerkennen, daß Social-Media-Buttons sehr populär sind. Wenn man sich im Internet umsieht, kann man den Eindruck bekommen, dass so gut wie jede Webseite wenigstens drei bis vier Schaltflächen anbietet, über die die Besucher die Inhalte ‚ganz einfach teilen‘ können: Twitter, Facebook und Google+ gehören fast schon zur Standardausstattung. Und der vermeintliche Nutzen ist ja auch verlockend: mit einem Klick kann ein Artikel direkt weiterempfohlen werden, neue Leser erreichen, Klicks generieren. Und der Preis dafür? Grundsätzlich ist die Einbindung von ‚Like-Buttons‘ erstmal kostenlos.

Social-Media-Buttons sind mir zu teuer

Aber beim Wort ‚kostenlos‘ gehen bei mir schon die Alarmglocken an – erfahrungsgemäß zahlt man immer einen gewissen Preis. Als erstes fällt mir dazu ein, dass man wenigstens einen Teil der Webseite mit den Social-Media-Buttons ‚belegt‘. Das wäre vielleicht erstmal nicht weiter schlimm, aber es handelt sich bei den Knöpfen ja in der Regel um Miniaturen des jeweiligen Firmenlogos. Egal, ob jemand den Knopf klickt oder nicht – das Firmenlogo ist in jedem Falle sichtbar. Man verschenkt also im Printip Werbefläche, ohne dass man sich darüber wirklich bewußt ist.

Man verschenkt aber nicht nur Fläche / Werbefläche – man gibt auch einen Teil der Gestaltung auf. Sicherlich lassen sich Social-Media-Buttons mehr oder weniger elegant ins Layout einer Webseite integrieren – aber letztendlich handelt es sich immer um Fremdkörper, auf deren Gestaltung man kaum Einfluß hat.

Ein dritter Punkt, der meiner Meinung nach gegen die Verwendung von Social-Media-Buttons spricht, ist die Sache mit der Ladezeit. Button-Befürworter mögen argumentieren, dass dieser Faktor zu vernachlässigen sei – man kann die Bilder ja auch direkt auf dem eigenen Server speicher oder auch gleich per CSS generieren – und auch bei ‚Share-Code‘ kann man sich auf eine Minimallösung beschränken. Man kann es drehen und wenden wie man möchte: zusätzlicher Code ist und bleibt zusätzlicher Code – und der muß geladen werden.

Als vierten und letzten Punkt möchte ich aber das ‚Image‘ anführen – vermutlich der wichtigste Punkt. Webseitenbesucher, die Social-Media nutzen, werden sich kaum an den bunten Knöpfen stören. Es gibt aber auch Webseitenbesucher, die gegenüber sogenannten Sozialen Medien kritisch eingestellt sind und die schon fast allergisch auf die entsprechenden Firmenlogos reagieren – sei es wegen Datenschutz-Bedenken oder einfach aus Prinzip.

Wenn jemand seinem Facebook-Freundeskreis eine Webseite oder einen Artikel empfehlen möchte, kann er/sie das natürlich trotzdem tun: einfach den Link kopieren. Und bei der Gelegenheit kann man vielleicht auch noch ein paar nette Worte dazu schreiben.

Mehr zum Thema:

Backup-Strategien zum Welttag des audiovisuellen Erbes

AM 27. Oktober wird der Welttag des audiovisuellen Erbes gefeiert – ein guter Tag, um sich mal Gedanken über die eigene Backup-Strategie zu machen.

Den Welttag des audiovisuellen Erbes gibt es bereits seit 1980 – wir feiern dieses Jahr also auch den 35 Jahrestag des Welttags des audiovisuellen Erbes.  Damals hat hat die UNESCO eine Empfehlung zum Schutz und zur Erhaltung bewegter Bilder verabschiedet. In Deutschland beteiligen sich zahlreiche Museen, Filmarchive und Stiftungen am UNESCO-Welttag. Es geht darum, das audiovisuelle Kulturerbe stärker in das öffentliche Bewusstsein zu bringen und auf die Notwendigkeit hinweisen, dieses entsprechend zu schützen, zu konservieren.

Viele Museen und Archive digitalisieren mittlerweile ihre Bestände – und inzwischen liegen viele audiovisuelle Kulturgüter digital vor. Aktuelle Filmproduktionen werden zu Teil komplett digital umgesetzt und man man spricht in diesem Zusammenhang dann eher von Backups.

Natürlich reicht es nicht, einen ehemals analog vorliegenden Film beispielsweise einmal zu digitalisieren und dann auf einem vermeintlich sicheren Datenträger zu speichern. Wer sich einmal ernsthaft mit einer Backup-Strategie beschäftigt hat weiss, die Konservierung bzw. Archivierung von digitalen Medien ist ein weites Feld. manchmal wir die Bedeutung einer funktionierenden Backup-Strategie allerdings erst dann verstanden, wenn es bereits zu spät ist.

Ein Datenverlust kann eine schmerzliche Erfahrung sein. Wenn ein Datenträger verloren geht ist häufig viel Arbeit einfach ‚weg‘. Diplomarbeiten, Filme, Interviews, Artikel, Manuskripte – als hätte es sie nie gegeben.

Bei einem einfachen Festplatten-Crash besteht immerhin die Hoffnung, dass es einen Experten gibt, der die verlorenen Daten wieder herstellen kann. Sollte ein Datenträger aber durch Diebstahl, Feuer oder ähnliche Ereignisse verloren gehen, ist am Ende alles einfach weg – es sei denn, man hat vorgesorgt.

Das Thema ‚Backup‘ ist natürlich auch für jeden Webdesigner und jeden Web-Entwickler wichtig – auch wenn häufig die wirklich wichtigen Dateien immerhin wenigstens auf einem Server als Kopie vorliegen (es sei denn, man arbeitet direkt auf dem Server). In will im folgenden kurz meine persönlichen Backup-Strategien darstellen und hoffe, damit den einen oder anderen dazu zu bewegen, eine eigene Backup-Strategie zu entwickeln – und umzusetzen.

USB-Stick

USB-Sticks gelten bei uns als rein temporäre Datenträger. Am besten man speichert gerade immer nur die Daten, die man gerade aktuell von A nach B transportieren möchte. Zu groß ist das Risiko, einen USB-Stick zu verlieren – zu grpß das Risiko, dass Unbefugte Zugriff auf die auf dem USB-Stick gespeicherten Daten bekommen.

Backups über ‚Time-Machine‘

Die Backup-Lösung Time Machine eignet sich vor allem, um einen bestimmten Computer schnell und unkompliziert wiederherstellen zu können. Um über Time-Machine einen Computer wiederherstellen zu können, verwendet man am besten eine dafür reservierte Festplatte. Diese sollte von der Kapazität her um einiges größer sein, als die Festplatte des zu ’schützenden‘ Computers. Man sollte sich aber darüber im klaren sein, dass die Verwendung von Time-Machine zwar eine gute Idee sein mag, aber keine wirklich wirksame Backup-Stategie darstellt. bei einem Einbruch besteht beispielsweise die Gefahr, dass ’natürlich‘ nicht nur alle Computer, sondern auch alle lokal vorhandenen Backup-Platten geklaut werden.

Lokale Backups: Computer, Festplatte, Arbeitsverzeichnissen

Bei uns gibt es eine verhältnismäßig große Backup-Platte, die ausschließlich dafür da ist, die Daten aller anderen Festplatten speichern zu können. Wir arbeiten zwar auf Mac OS – verzeichten aber bei dieser Festplatte bewußt auf die Verwendung von ‚Time-Machine‘. Stattdessen verwenden wir zurzeit (immernoch) Carbon Copy Cloner, bei dem sich einzelne Verzeichnisse auswählen lassen, die von Zeit zu Zeit gesichert werden sollen. Damit hat man eine relativ schnelle und kostengünstige Lösung, mit der sich beispielsweise gezielt Arbeitsverzeichnisse sichern lassen.

Diese Backup-Platte wird dann in größeren Abständen selbst gesichert. Alternativ kann man die beiden Backup-Platten auch einfach austauschen. Dafür haben wir eine zweite Backup-Festplatte, mit derselben Kapazität. Diese zweite Festplatte sollte unbedingt physisch an einem anderen Ort gelagert werden – nur so läßt sich Risiken wie Diebstahl, Feuer und Überschwemmung effektiv begegnen.

Backup von Webseiten und Web-Datenbanken (mySQL)

Grundsätzlich sollte man sich bei der Wahl des Webhosting-Anbieters auch nach deren Backup-Strategie erkundigen. Viele Anbieter haben inzwischen sogn. redundante Systeme installiert, bei dem die Webseiten und Datenbanken von vorneherein auf zwei Festplatten gespeichert sind. Fällt eine Festplatte aus, wird automatisch auf die andere Festplatte umgeschaltet.

Redundante Systeme sind eine gute Idee, aber noch keine Backup-Strategie. Je größer und Umfangreicher eine Webseite wird, desto wichtiger wird es, eine funktionierende Backup-Strategie einzusetzen. Bei Totalverlust haften Webhosting-Anbieter meistens nur für den materiellen Schaden. Da man den Webspace in der Regel nur mietet, beläuft sich der erstattete materielle Schaden in den meisten Fällen aber auf 0,- Euro.

Man sollte also von Zeit zu Zeit wenigstens händisch alle Dateien sowie einen Datenbank-Dump vom Server herunterladen und lokal sichern. Das mag zunächst ein wenig umständlich erscheinen, ist aber als Minimal-Lösung sehr effektiv. Für größere Webseiten dürfte diese Strategie allerdings auf Dauer unpraktikabel sein.

Automatisierte Backups für WordPress, Drupal, mySQL

Für Content Management Systeme gibt es inzwischen ein Fülle von nativen Backup-Lösungen und es würde einfach den Rahmen sprengen, in diesem Artikel die vielen verschiedenen Plugins und Add-Ons für WordPress und Drupal miteinander zu vergleichen. Stattdessen seien hier nur zwei Backup-Lösungen genannt, die ich selbst hin und wieder verwende – aber am Ende muß jeder für sich selber herausfinden, ob er mit diesen Tool umgehen möchte / umgehen kann:

  • Drupal: Backup and Migrate
    Das Drupal-Modul Backup and Migrate eignet sich wie der Name schon suggeriert zum Sichern und/oder Umziehen von kompletten, komplexen Webseiten, die mit Drupal erstelt wurden. Vom spontanen jetzt-und-hier-und-alles-Backup bis hin zu ausgeklügelten Backup-Zeitplänen von dezentral gespeicherten automatisierten Backups ist so gut wie alles möglich.
  • WordPress: WP-DM-Backup
    Das WordPress-Plugin WP-DM-Backup bzw. „WordPress Database Backup“ ist eine eher relativ rudimentäre Backup-Lösung für WordPress. Man kann das Plugin wie eine komfortable WordPress-Schnittstelle für phpmyAdmin verstehen: es lassen sich alle manuell sichern oder auch automatisch beispielsweise einmal monatlich per Email verschicken. Ich nutze bei kleineren Seiten die Automatik und nehme die Backup-Mail dann zum Anlass, Dateien direkt per FTP zu sichern. Immerhin.

Grundsätzlich gilt: ein Backup-Plugin ist immer nur so gut, wie das Backup, das es am Ende erstellt. Eine einfache Standard-Lösung kann einen in falscher Sicherheit wiegen, wenn man in Wirklichkeit eine hochkomplexe und individuell angepasse Webseite mithilfe von WordPress oder Drupal vorliegen hat. Oder konkret ausgedrückt: Was bringt einem ein schnelles und unkompliziertes Backup-Tool, wenn es die individuell angelegten Content Typen, Eingabefelder und Nutzerprofile nicht sichert?

Die einzige wirklich verläßliche Backup-Lösung für Webseiten, die mithilfe eines Content Management Systems erstellt wurden, erscheint mir daher nach wie vor die direkte Sicherung der eigentlichen Datenbank in Verbindung mit der direkte Sicherung der eigentlichen Dateien. Das ist natürlich etwas mühsam – aber immernoch einfacher, als nachträglich alles per Hand neu anzulegen.

Spontane Webseiten-Backup-Lösung für zwischendurch

Zu guter letzt noch eine Backup-Lösung, die eigentlich gar keine ist. Dazu zunöchst die passende Geschichte: Ein Kunde rief mich vor einer Weile spät abneds an, wegen eines Missverständnisses mit seinem bisherigen Hosting-Anbieter sei seine Domain nun gekündigt und bereits in der Lösch-Phase. Es sei damit zu rechnen, dass die Domain, der Webspace und alle Daten in den kommen 1-2 Stunden gelöscht werden würden. Ich war zu dem Zeitpunkt nicht im Büro – hatte aber meinen Rechner sowie einen mobilen Internetzugang dabei.

Ich hatte weder FTP-Zugang zu der Webseite, noch irgendwelche Datenbank-Passwörter – geschweige denn einen Login zum CMS. Stattdessen habe dann den kleinen Helfer SiteSucker gestartet und innerhalb weniger Minuten alle öffentlich zugänglichen Seiten heruntergeladen.

Der Webspace war kurze Zeit später wirklich komplett gelöscht. Die Domain konnten wir zum Glück schon am nächsten Tag reaktivieren und anschliessend das statische Backup einspielen. Das Webseite sollte sowieso rundum erneuert, das CMS dewechselt werden. Die Inhalte mußten daher sowieso mehr oder weniger komplett neu angelegt werden. Nach außen, also für die Webseiten-Besucher war die Internetseite aber immerhin nur für ein paar Stunden nicht erreichbar.

Siehe auch:

  • Alles weg“ – Artikel in der Berliner Zeitung zum Total-Verlust der SPEX-Homepage 2001

Dedicated Hosting: gute Gründe für einen Managed Server

Dedicated Hosting / Managed Server – Webserver im Rechenzentrum bei All-Inkl

Webserver im Rechenzentrum bei All-Inkl – Foto / Copyright: ALL-INKL.COM

Es ist ja kein Geheimnis: ich mag Dedicated Hosting – und daher haben wir einen sogn. Managed Server. Natürlich steht der Server nicht direkt hier bei uns in Berlin – unsere ‚Kiste‘ steht bei All-Inkl in Friedersdorf, Sachsen. Also – Serverstandort Deutschland.

Wir sind seit vielen Jahren Kunde bei All-Inkl und wir sind sehr froh darüber. Kein Stress, ein meiner Meinung nach hervorragendes Preis-Leistungs-Verhältnis, und vor allem: kein Stress.

Warum Dedicated Hosting? Webdesign ist ein bisschen wie Kochen

Ich bin zwar kein besonders guter Koch, bzw. zumindest kein rutinierter, aber der Vergleich sei trotzdem erlaubt: Webdesign ist ein bisschen wie Kochen. Die Qualität einer guten Mahlzeit setzt sich aus vielen verschiedenen Faktoren zusammen: gute Zutaten, gutes Werkzeug, ein Team, das mit den Zutaten und dem Werkzeug umgehen kann – und eine Umgebung, in der das Team gut und gerne arbeitet, weil sie auf die eine oder andere Art die Arbeit erleichtert.

Beim Kochen ist diese Umgebung die Küche, das Restaurant, der Herd – die Infrastruktur des Kochens. Bei Webdesign besteht diese Umgebung bzw. die Infrastruktur meistens aus  einem Schreibtisch, einem Computer, verschiedenen Programmen – und einem Webserver.

Natürlich kann wohl jeder Koch auch in einer fremden Küche arbeiten – und natürlich kann ein Webdesigner / Web-Entwickler auch auf fremden Servern arbeiten, soweit die gegebenen Bedingungen dies eben zulassen. Aber wie schon das alte Sprichwort sagt: Eigener Herd ist Goldes wert. Man muss nicht rätseln und nicht suchen – man weiss einfach, wo alles ist, und wie es funktioniert. Man kann einfach machen.

Warum ein eigener Weberver? Vorteile von Dedicated Hosting

Für unsere Kunden bieten wir im Prinzip das ‚komplette Paket‘ an. In erster Linie erstellen wir natürlich Webseiten – also das Webdesign (Frontend) und ein passendes Content Management System (Backend). Daneben hat sich aber bewährt, dass wir für viele Kunden auch gerne ‚die Details‘ klären – das bedeutet, dass wir von der Domain-Bestellung über die Webserver- bzw. Webspace-Einrichtung bis hin zum Einrichten von Email-Konten und Statistik-Tools alles anbieten, was man so braucht, um eine Webseite betreiben zu können. Wer bei uns ein „Pflege- und Support-Paket“ bucht, muss sich nicht um die wohlmöglich ‚lästige‘ Technik kümmern und kann sich stattdessen voll und ganz auf seine Inhalte konzentrieren.

Im Prinzip sind wir also selbst Hosting Anbieter, wobei unser ‚Kerngeschäft‘ aber natürlich die Gestaltung und Erstellung von Webseiten ist. Als Designer verstehen uns aber auch als ‚Problem-Löser‚ – also als Dienstleister, die sich eben um ‚alles‘ kümmeren – soweit das eben gewünscht ist.

Für uns bringt es viele Vorteile mit sich, dass wir auf unserem eigenen Webserver arbeiten. Um es kurz zu fassen: wir kennen unseren Server – und unser Server kennt uns.

Beim Shared Hosting bzw. einem Shared Server teilt man sich den Server mit x unbekannten Nachbarn – oder sogar ‚Mitbewohnern‘ – also vielen unbekannten Webseiten, unbekannten Skripten. Wenn ein Nachbar ein anspruchsvolles Skript installiert, kann es bei einem Shared Server durchaus mal passieren, dass der gesamte Webserver in die Knie geht. Allerdings vermute ich mal, dass das bei All-Inkl so gut wie nie vorkommt – schon beim günstigen Hosting-Tarif „All-Inkl Privat“ teilt man sich einen Server mit maximal 100 Kunden.

Bei einem Dedicated Hosting bzw. einem Managed Server hat man hingegen Freiheiten, die in der Wohngemeinschaft eines Shared Servers einfach nicht möglich wären. Rechenpower, Speicherplatz und Bandbreite werden bei uns quasi je nach Bedarf vergeben – und wenn mal ein Spezial-Skript oder eine bestimmte PHP-Version benötigt wird, dann wird eben ein Spezial-Skript oder eine bestimmte PHP-Version installiert.

Brauche ich einen Managed Server?

Natürlich braucht nicht jeder Webseite bzw. jeder Webseiten-Betreiber gleich einen eigenen Managed Server – für die meisten Webseiten wäre das sicherlich zu viel des Guten. Und so ein Managed Server ist auch ein nicht ganz so billiges Vergnügen. Übers Jahr gerechnet kommt für die Server- und Servicegebühren ein durchaus beeindruckender vierstelliger Betrag zusammen.

Für uns hat sich aber nie die Frage gestellt, ob wir uns das leisten können – die Vorteile überwiegen ganz einfach: Unsere Kunden-Webseiten laufen auf einem zugegebener Maßen etwas überproportionierten Server, der mehr als genug Rechenpower, Speicherplatz und Bandbreite zur Verfügung stellt. Wir sind glücklich und zufrieden – und unsere Kunden sind es (hoffentlich/vermutlich) auch.

Ich kann Dedicated Hosting – und insbesondere All-Ink daher nur empfehlen! Der Support ist großartig, freundlich und zuvorkommend, und der Server läuft einfach rund. Es kommt so gut wie nie zu technischen Problemen – und wenn dann doch mal was langsam läuft, liegt es eigentlich immer an einem problematischen Skript und der Fehler ist schnell gefunden und behoben.

Ja, dieser Beitrag sollte sich eigentlich ums Hosting und die Vorteile eines Managed Servers drehen – ist nun aber ein bisschen zum Lobgesang auf All-Inkl geworden. Kein Wunder: für uns ist beides direkt miteinander verbunden. Daher erlaube ich mir  an dieser Stelle auch ausnahmsweise mal, einen Affiliate-Link zu All-Inkl zu setzen: http://all-inkl.com/?partner=507552. Wenn Sie über diesen Link bei All–Inkl ein Hosting-Paket beauftragen, wird mir eine gewisse Provision gutgeschrieben. Ach ja: natürlich laufen nicht nur unsere Rechner hier in Berlin, sondern auch die Webserver bei All-Inkl dank Ökostrom CO2-neutral.