Strato – 503 Service Temporarily Unavailable

Beim Aufbauen von Online-Shops bekam ich schon häufiger die obige Meldung. Meist trat sie auf, wenn man sich beim Testen des Bestellzykluses einen neuen Test-Benutzer anlegen wollte. Im Registrierungsformular sind alle Daten eingegeben, nur noch der Klick auf “Absenden” und die nächste Seite zeigte die Meldung:

503 Service Temporarily Unavailable

Schnell gerät ein nicht laufendes PHP-Script in Verdacht, der Auslöser zu sein. Aber dem ist nicht so. Grund dafür ist der selbst lernende Spam-Filter von Strato. Aufgrund der vielen Anfragen über das Registrier-Formular “denkt” der Filter, es wäre ein emsiger Spammer am Werke und unterdrückt die weitere Verarbeitung des Registrierungsprozesses – und die obige Meldung ist der einzige Hinweis darauf, daß etwas nicht mehr funktioniert. Abhilfe schafft das Deaktivieren des Server Side Security – Filters in der Strato-Administrations-Maske:

Webhosting-Paket -> ServerSide Security -> Filter deaktivieren

Warum ich Gambio GX2 einem Magento-Shop vorziehe

Es gibt viele Systeme im Internet, um einen eigenen Online-Shop aufzubauen. Viele sind sogar bei den Webhosting-Anbietern gleich mit dabei – man braucht nur noch seine Artikel inklusive Beschreibung und Foto hochladen und fertig ist das Webangebot. Oder etwa doch nicht?

Ganz so einfach ist das nicht. Wie ich im vorherigen Blogeintrag geschrieben habe, gibt es jede Menge mehr zu tun als nur seine 10 Artikel eine vernünftige Beschreibung zu verpassen, Foto dazu, Preis Pi mal Daumen kalkuliert und fertig. Und dieses “Tun” ist der Grund, warum ich eher zu Gambio denn zu Magento tendiere. Klar, beide Shops können recht viel und Magento hat ein gefälligeres, modernes Äußeres. Wäre eigentlich ein Punkt für Magento. Der große Negativ-Punkt ist jedoch, daß es keine günstige Möglichkeit gibt, eine Warenwirtschaft an Magento anzudocken. Ich bevorzuge die JTL-Warenwirtschaft. Sie kann im Netzwerk betrieben werden, ein Server beinhaltet die SQL-Datenbank und mehrere Clients können gemeinsam an den Artikeln/Bestellungen usw. arbeiten. Sind Aktualisierungen getätigt, werden diese per Connector automatisch in den Gambio Shop geladen.

Diese Vorgehensweise funktioniert nicht mit Magento. Zwar sind Connectoren von JTL angekündigt, aber bislang noch nicht erschienen. Alternativen wären kommerzielle Anbieter, aber dort kostet eine Schnittstelle ab 500,- netto aufwärts. Ich denke, zu viele für jemanden, der klein anfangen will. Da ich in meinen Installationen eine Trennung von Präsentation (Onlineshop) und Datenhaltung (Warenwirtschaft) vornehme, ist dies ein sehr gewichtiges Manko, welches auch die hübscher aussehenden Oberflächen von Magento nicht wett machen können.

 

Vorteile von zwei einzelnen Installationen:

  • Die Trennung der Daten von der Präsentation hat trotz des initialen Mehraufwands der Installation massive Vorteile gegenüber einer kompletten Datenhaltung im Shop selbst:
  • Änderungen werden nicht gleich im Live-Shop sichtbar
  • Datenbackup können viel einfacher gestaltet werden
  • Firmeninterne Daten werden nicht ins Internet ausgelagert, wenn der DB-Server im eigenen Haus steht
  • Da beide Systeme unabhängig voneinander funktionieren, ist die Wahrscheinlichkeit eines Totalausfalls/Verlust von Daten geringer
  • Anpassung der Artikeldaten geschehen immer “offline” und können erst auf Knopfdruck im Produktivshop sichtbar gemacht werden

 

Warum kostest es mehr Geld als erwartet, einen Shop zu erstellen?

Heutzutage ist es sehr leicht geworden einen eigenen Online-Shop aufzusetzen. Viele (oder alle?) Webhosting-Anbieter bieten neben dem Webspace auch ein Baukastensystem oder auswählbare Software, mit dem sich innerhalb von Minuten ein eigener Shop aufsetzen lässt. Ob Magento, Gambio GX2, WordPress mit WooCommerce-Plugin – alles inklusive und ohne dass der Kunde einen Cent mehr als das Webhosting bezahlen müsste. Warum sollte man also einen externen Dienstleister hinzuholen, wenn es doch alles so einfach mit ein paar Klicks zu realisieren ist.

Die simple Antwort ist: Es ist nicht einfach. Viele haben die Vorstellung, daß ein Webshop die Ansicht darstellt, die der Kunde letztendlich zu sehen bekommt, das Frontend. Dem ist nicht so, die Präsentation der Artikel aus Kundensicht ist nur die Spitze des Eisbergs. Ein ordentlicher produktiver Webshop hat mehr Anforderungen zu erfüllen, als dem Kunden eine schicke Oberfläche zum Kaufen zu bieten. Aus meiner Sicht gehören jedoch noch mehr und genau so wichtige Dinge dazu:

Einrichtung der Shopsoftware

ist ein Shop von einem Webhosting-Paket installiert, liegt er “nackt” im Internet: Es sind keine Zahlungsmodule, Versandoptionen, Kategorien, AGB, Impressum oder andere Zusatzoptionen installiert. Klar, vieles kann man schnell und einfach selbst erledigen, es wird ja auch viel Unterstützung in der Shopsoftware selbst gegeben. Möchte man jedoch nicht alltägliche Module installieren, sieht es anders aus: die Dokumentation wird spärlicher, je weniger ein Modul verbreitet ist. Bis hin zu komplett eigenen Anpassungen, siehe hier.

Verwaltung der Artikel

Wer mehr als 10 Artikel in seinen Shop präsentieren möchte, sollte sich im Vorfeld Gedanken darüber machen, wo die Artikel gepflegt werden. Soll alles online im Backend des Shops gemacht werden und wirken sich Änderungen der Artikel sofort auf die Sichtbarkeit im Shop aus? Das mag funktionieren, so lange Änderungen an Artikeln (zB. Preise werden gesenkt/erhöht, Artikelbestände ändern sich) in langen Abständen geschehen. Günstiger ist es jedoch, seinen Artikelbestand in einer eigenen Datenbank zu haben. Ist bei dieser ein tägliches Backup eingerichtet, können per Datenbank-Query alle Artikel in einem Rutsch geändert werden. Die Änderung kann geprüft und erst bei nach Freigabe im Online-Shop per Datenbank-Abgleich sichtbar gemacht werden. Das Risiko einen fehlerhaften Artikel einzustellen, ist gemindert.

Wartung und Updates

Mit der Zeit erscheinen für jede Shop-Software Updates oder Sicherheitspatches. Die Anbieter von von Hosting-Paketen werden diese Updates jedoch nicht automatisch in den eigenen Shop einpflegen, da zum einen immer das Risiko eines missglückten Updates besteht und zum anderen die Hostinganbieter individualiserte Shopanpassungen mit einem Update einfach überschreiben würden. Der Aufschrei der Shop-Betreiber wäre groß! Also muss selbst Hand an das Updaten angelegt werden und das kann manchmal ziemlich tricky sein. Geht es schief, muss meist der komplette Shop von Grund auf neu aufgesetzt werden, incl. aller Anpassungen.

Tägliche Arbeit

Für die tägliche Arbeit stellt sich folgende Frage: Wo möchte die notwendigen Dinge tun wie:

  • Artikel bearbeiten
  • Bestellungen verwalten
  • Rechnungen drucken
  • Lieferscheine drucken
  • usw.

Soll das alles in einem Browserfenster passieren, abhängig von der Geschwindigkeit mit der man im Internet surft oder wäre es geschickter dies auf dem heimischen PC zu haben und nur ein Minimum an Daten zwischen dem Shop und seinen eigenen Rechner hin- und her zusenden?

Zusammenfassung

Es empfiehlt sich einen externen Ansprechpartner hinzuziehen, wenn man nur einen Teil der oben genannten Dinge selbst machen kann. Meist ist es so, daß Entscheidungen, welche zu Beginn eines Projekts falsch getroffen worden sind, immer wieder während der gesamten Projektphase nach oben kommen und dann das Leben schwer machen. Um schnell und zielorientiert einen Shop aufzusetzen, der auch für kommende Updates in der Zukunft gerüstet ist, sollte das Gesamtkonzept stimmen. Schnell mal was aufsetzen kann jeder, aber es dauerhaft mit allen Anpassungen stabil am Laufen zu halten, steht auf einen anderen Blatt.

 

 

 

Verarbeitung von CSV-Dateien

Wer einen Online-Shop mit Artikeln befüllen will, kennt das Problem: Der Lieferant gibt seine Artikeldaten per CSV- oder Excel-Datei an den Händler weiter. Auf einmal ist man damit konfrontiert, tausende Artikel in diversen Größen, Farben, Varianten usw. in seinen Shop einzupflegen. Bei der Initialbefüllung des Shops mag das noch mehr schlecht als recht funktionieren, aber wie sieht es im laufenden Betrieb aus? Ist der Artikel beim Lieferanten noch bestellbar, sind alle Größen verfügbar, sind neue Artikel hinzugekommen oder fallen andere weg, wie viele Artikel sind noch am Lager? Dieser Abgleich per Hand ist unheimlich aufwendig und dies täglich oder wöchentlich zu tun fast nicht möglich. Abhilfe schafft eine automatisierte Verarbeitung der Artikel-Liste vom Lieferanten:

2015-07-06 Schema CSV-Anbindung

Alle Schritte die normalerweise von Hand gemacht werden, können durch ein kleines Java-Programm um einiges schneller und fehlersicherer ausgeführt werden – vorausgesetzt die Programmierung stimmt. Im obigen Schema wird eine CSV-Datei vom Lieferanten so umgearbeitet und wieder ausgegeben, daß es für den Import im Webshop ohne weitere Arbeite genau passt.

Wichtiger Punkt bei diesem Schema: die Standardisierung der Eingangsdaten. Dadurch ist möglich, trotz wechselnder Eingabedatei immer das selbe Schema für die Ausgabe zu erhalten. So können zB. verschiedene Lieferanten an den Shop automatisiert angekoppelt werden oder Dienstleister können ganz einfach für Ihre Kunden einen Datenimport realisieren.

Denkbar wäre mit diesem Ablauf auch der Datenaustausch zwischen nativ nicht kompatiblen Programmen – so lange sie einen CSV-Import bzw. Export unterstützen. Durch die Schnittstelle können theoretisch beliebige Programme miteinander kommunizieren. Falls gewünscht sogar komplett automatisiert per Batch oder Cronjob.

 

Schema Aufbau eines Onlineshops

 

Wer einen Onlineshop aufbauen will, steht meist vor der Frage, wie dies am besten zu realisieren ist. Viele kennen sich zwar mit dem Produkt aus, welches verkauft werden soll, aber die Umsetzung bis zum lauffähigen Shop ist ein Buch mit 7 Siegeln. Gerade Kleinunternehmer müssen meist sehr auf die anfänglichen Investitionskosten schauen. Es wird dann bei Anbieter gesucht, welche einen komplett konfigurierten Shop zu einem monatlichen Basispreis zwischen 80,- und 100,- Euro anbieten.

Diese Sicht scheint auf dem ersten Blick vernünftig, hat man doch sehr überschaubare Kosten, meist noch eine 1-3monatige Testphase. Aber: Diese Shops laufen komplett im Internet, reagieren je nach Internetanbindung sehr langsam und den Anpassungsmöglichkeiten sind enge Grenzen gesetzt.

Als Alternative möchte ich hier grob skizzieren, wie es auch anders geht:

2015-07-01 Schema Software

Der Shop läuft nur auf dem Webhosting. Er dient nur dazu, die zu verkaufenden Produkte darzustellen und die Bestellungen entgegen zu nehmen. Die komplette Verwaltung der Artikel, Rechnungserstellung usw. findet jedoch in der Warenwirtschaft auf einem virtuellen Server statt. Werden Artikel in der Warenwirtschaft auf dem Server geändert, schiebt dieser diese automatisch in den Shop. Umgekehrt werden Bestellungen von Kunden direkt in die Warenwirtschaft geladen. Diese Aufteilung hat entscheidene Vorteile in der Verwaltung:

1. Änderungen an Artikeln geschehen im ersten Schritt nur auf dem virtuellen Server – es gibt kein Risiko einer ungewollten fehlerhaften Artikeleingabe, zB. ein zu niedriger VK-Preis

2. Einzelne Artikel, Artikelgruppen oder alle Artikel können in einem Zug geändert werden

3. Eine Anbindung an andere Markplätze ist möglich

4. Der virtuelle Server kann Backup-Aufgaben übernehmen: angefangen vom einfachen Datenbank-Dump bis hin zu einer kompletten Sicherung der Shopsoftware

5. Durch den Aufbau mit virtuellen Server ist es möglich, daß man nur mit der Client-Software auf seinen Laptop jederzeit eine komplette Übersicht über den Datenbestand hat

6. Der Administrator muss für Anpassungen, Updates oder Problemlösungen nicht vor Ort sein. Per RDP kann er sich jederzeit auf den Server schalten

7. Es können beliebig viele Clients an die Warenwirtschaft angeschlossen werden und alle arbeiten mit dem selben Datenbestand – ohne viel Aufwand!

8. Die monatlichen fixen Kosten für den Server und den Webspace betragen ca. 1/3 vom komplett gemieteten Shop

9. Man ist vom Hoster unabhängig. Sollte man bei einem Internet-Provider ein besseres Angebot bekommen, kann man den Shop incl. Domain ohne größere Probleme “umziehen” lassen

Nachteile bei dieser Lösung gibt es jedoch auch. Man ist komplett eigenständig dafür verantwortlich, daß man die eingesetzte Software auf dem neuesten Stand hält. Dafür ist meist ein externer Administrator notwendig.

Zusätzliches Pflichtfeld in Gambio GX2

Manchmal möchte man zusätzliche Angaben von einem Kunden wissen, für die Gambio GX2 kein Feld zur Verfügung stellt. In meinem Beispiel wollte ich wissen, woher der Benutzer meine Webseite kennt. Dies ist eine Standard-Frage für das Marketing, welcher Channel für einen Online-Shop am besten funktioniert.

Hierfür habe ich beim Erstellen des Benutzeraccounts ein weiteres Feld eingefügt:

 

Folgende Änderungen sind dafür notwendig:

In der Datenbank von Gambio habe ich eine neue Tabelle angelegt, welche die Optionen der Dropdown-Box beinhaltet. Ich habe sie reasons genannt, weil mir schlicht und ergreifend kein besserer Name eingefallen ist ;-). Achtung: Unbedingt ein Backup der Datenbank machen, es können immer Fehler passieren und das Risiko trägt immer der, der ändert! Ich weiß, das wurde schon oft geschrieben, aber man kann es gar nicht oft genug wiederholen.

Felder anlegen:

reasons_id, int(11), autoincrement -> Primärschlüssel

reasons_text, text

status, int(1), selbst definiert, 1

 

Das war einfach. Da wir wissen wollen, welcher Benutzer welche Option ausgewählt hat, muss die Information, was der Benutzer ausgewählt hat, in dessen Datenbank-Eintrag gespeichert werden. Dazu nutze ich die  Tabelle address_book. In ihr werden die Stammdaten des Kunden gespeichert, warum also nicht auch die Beweggründe auf die Seite zu kommen? Ich erweitere die Tabelle um ein Feld entry_reasons_id, int(11), selbst definiert 0, welches am Ende die reasons_id speichern soll:

So, das war’s mit den Änderungen an der Gambio GX Datenbank. Kommen wir zu den Änderungen auf Dateiebene.

Zuerst machen wir die neue Tabelle reasons für Gambio bekannt: in /includes/database_tables.php folgende Codezeile hinzufügen:

define(‘TABLE_REASONS’,'reasons’);

Die Änderungen im Registrierformular durchführen:
Die Datei /templates/<DeinTemplate>/module/create_account.html ändern:
Nach
<tr>
<td><label>{$txt.text_email_confirm}</label></td>
<td>
<input type=”text” name=”{$INPUT_EMAIL_CONFIRM_NAME}” value=”{if !$error_mail}{$form_data.email_confirm.value}{/if}” />
{if $form_data.email_confirm.required == ’1′} * {/if}
{if $error_mail}<span>{$error_mail}</span>{/if}
</td>

folgende Code einfügen:

<tr>
<td><label>Woher kennen Sie yourwebsite.de?</label></td>
<td>
<select name=”{$form_data.reason.name}”>
{foreach key=reasons item=reason_data from=$reasons_data}
<option value=”{$reason_data.reasons_id}”{if $reasons_data.reasons_id == $form_data.reason.value} selected=”selected”{/if}>{$reason_data.reasons_text}                            </option>
{/foreach}
</select>
{if $form_data.reason.required == ’1′} * {/if}
{if $error_country}<span>{$error_country}</span>{/if}
</td>
</tr>
Folgende Ergänzungen in create_account.php durchführen:

Nach:         require_once (DIR_FS_INC.’xtc_get_country_list.inc.php’);
Einfügen:    require_once (DIR_FS_INC.’xtc_get_reasons_list.inc.php’);

Nach:        $country = xtc_db_prepare_input($_POST['country']);
Einfügen:    $reason = xtc_db_prepare_input($_POST['reason']);

Achtung, nur 1 Zeile:
Zeile:            $sql_data_array = array (‘customers_id’ => $_SESSION['customer_id'], ‘entry_firstname’ => $firstname, ‘entry_lastname’ => $lastname, ‘entry_street_address’ => $street_address,                 ’entry_postcode’ => $postcode, ‘entry_city’ => $city, ‘entry_country_id’ => $country,’address_date_added’ => ‘now()’,'address_last_modified’ => ‘now()’);
Ersetzen durch:    $sql_data_array = array (‘customers_id’ => $_SESSION['customer_id'], ‘entry_firstname’ => $firstname, ‘entry_lastname’ => $lastname, ‘entry_street_address’ => $street_address,                 ’entry_postcode’ => $postcode, ‘entry_city’ => $city, ‘entry_country_id’ => $country, ‘entry_reasons_id’ => $reason,’address_date_added’ => ‘now()’,'address_last_modified’ => ‘now()’);

Nach:        $smarty->assign(‘countries_data’, xtc_get_countriesList());
Einfügen:    $smarty->assign(‘SELECT_REASON’, xtc_get_reason_list(array (‘name’ => ‘reason’, ‘text’ => ‘&nbsp;’. (xtc_not_null(ENTRY_COUNTRY_TEXT) ? ‘<span                                 class=”inputRequirement”>’.ENTRY_COUNTRY_TEXT.’</span>’ : ”)), $selected));
$t_form_data_array['reason']['name'] = ‘reason’;
$t_form_data_array['reason']['value'] = $selected;
$t_form_data_array['reason']['required'] = 1;
$t_form_data_array['reason']['required_symbol'] = ENTRY_COUNTRY_TEXT;
$smarty->assign(‘reasons_data’, xtc_get_reasonsList());

Angehangene Dateien aus dem Zip-Achiv xtc_get_reasons.inc.php und xtc_get_reasons_list.php nach \inc kopieren.

Link: 01. Dropdownfeld in CreateAccount

Das war’s. Jetzt bekommt man beim Erstellen eines Benutzerkontos (nicht Gastkonto) die Box angezeigt, welche mit den Werten aus der Tabelle reasons gefüllt sind. Gespeichert werden die Daten in der Tabelle address_book.

Im nächsten Beitrag werde ich zeigen, wie man die gespeicherten Ergebnisse ohne SQL-Kenntnisse schnell abfragen kann. Bitte nutzt die Kommentare für Fragen, Vorschläge oder Verbesserungen.