Nun kann es nicht die Aufgabe eines Shopbetreibers sein, diese Datei mit Artikelinformationen, Preisen, Lagerbeständen, etc. manuell zu pflegen und aktuell zu halten. Auch das alleinige Anstoßen eines Exports nach jeder Änderung der Artikelbeschreibung, des Artikelpreises, etc. wäre zu umständlich.

Der Vorgang mußte also automatisiert werden, um die Aktualität und damit die Qualität der Daten für die Preissuchmaschine auf einen hohen Niveau zu halten. 
 

Aufgabenstellung

• Ein PHP-Skript ist zu erstellen, welches aus einer Magento-Datenbank (e-Commerce Shopsystem) die CSV-Datei für eine bestimmte Preissuchmaschine erzeugt.
   
• Dieses PHP-Skript als Cronjob in regelmäßigen Zeitabständen anzustoßen, so dass der Shopbetreiber sich keine Gedanken mehr um die Aktualität der Preissuchmaschinendatei mehr machen muss. 

Auf einem Windows-System geschrieben und getestet, lief das Skript auch wunderbar.  Beim Produktionssystem unter Linux (Suse 11.1) und Plesk (Version 8.6) erhielt ich jedoch die folgende Fehlermeldung:
 

Wie sich leicht durch eine Internetrecherche herausstellte, hatten schon viele vor mir ähnliche Fehlermeldungen. Leider gab es hierbei jedoch keine Lösung, die bei meiner Installation zum Erfolg führte.

Der Vollständigkeit halber möchte ich die gefundenen Lösungsvorschläge dennoch kurz aufführen, vielleicht führen diese ja bei einer anderen Systemkonfiguration zum Erfolg:

• Schreibweise und Existenz der Pfade prüfen
• Vorhandensein der Dateien, die nicht includiert werden konnten, prüfen (Grund: korrupte, gepackte Verzeichnisse oder Downloads)
• Richtige Schreib-/Leserechte bei den Dateien/Verzeichnisse
• PHP-Version fehlerhaft: Viele machen die PHP Version 5.2.5 für den obigen Fehler verantwortlich. Bei manchen ging nach einem Upgrade auf 5.2.6 plötzlich alles, bei anderen jedoch zeigte sich keine Veränderung.
• Plesk spezifisch: Die vhost.conf Datei um eine Eintragung erweitern

<Directory /srv/www/vhosts/deineshopdomain.de/httpdocs> (Verzeichnis kann bei anderem Linux abweichen)
php_admin_value include_path
“.:/usr/share/pear:/srv/www/vhosts/DeineShopDomain.de/httpdocs/lib:/… u.s.w. ”
</Directory>

danach ein

/usr/local/psa/admin/sbin/websrvmng -a -v

rcapache2 reload

Insbesondere dem letzten Lösungsvorschlag hatte ich große Erfolgschancen eingeräumt, zeigte doch ein phpinfo.php Aufruf, dass nunmehr der PHP include_path eindeutig die beanstandeten Laufwerke beinhaltete. 

Ein erneuter Start des Skrips

/usr/bin/php5  -f  skript.php

auf Command-Line Ebene ergab aber wieder die oben genannten Fehlermeldungen.

Lösung
Ich habe mir daraufhin die Command Line Parameter für das PHP5 Programm angeschaut und bin fündig geworden. 

Usage: php [options] [-f] <file> [--] [args...]

  -a               Run interactively
  -c <path>|<file> Look for php.ini file in this directory
  -n               No php.ini file will be used
  -d foo[=bar]     Define INI entry foo with value 'bar'
  -e               Generate extended information for debugger/profiler
  -f <file>        Parse and execute <file>

Die include-path Einweisung im Skriptprogramm wird ignoriert, die  include-path Anweisung in der Plesk-Vhost.conf Datei wird ignoriert, aber durch den Parameter "-c [/pfad/php.ini]" kann man PHP5 anweisen die php.ini Datei zu verwenden und plötzlich ging die Sonne auf, die Welt war wieder in Ordnung und das Skript lief sofort wieder fehlerfrei durch.   

Man beachte die Stellung des Parameters -c vor dem -f, wenn man optional keine php.ini Datei angibt, weil sich diese im gleichen Verzeichnis wie die Skriptdatei befindet:

/usr/bin/php5  -c  -f  skript.php

Problem:  Wo findet sich der Sourcecode hierfür?
Eins der Probleme beim Shopsystem Magento ist die teilweise nur schwer verständliche Aufsplittung des Codes.

Zunächst einmal könnte man ja vermuten, dass die englischen Originalwörter aus der ersten Zeile des Fußbereichs irgendwo in einer Seitenvorlage, einem phtml-Template liegen.  Man durchsucht also den Sourcecode und stellt fest, dem ist nicht so.

Die nächste Vermutung wäre dann, dass die Begriffe in einer Sprachdatei *.csv flexibel hinterlegt sind. Aber auch hier wird man nicht fündig.

Lösung
Wenn aber die Zeichenstrings im Sourcecode nicht zu finden sind, was bleibt dann als Quelle für die Bildschirmdarstellung nur noch übrig?
Richtig, die Datenbank.  Im Admin Panel wird man unter CMS/Statische Blöcke fündig:

Und hierbei sieht man dann, was ich unter Aufsplittung des Codes verstehe.  Wer nun denkt, dass bei Magento die anderen Zeilen aus dem Fußbereich nach dem gleichen Schema gestrickt und auch als Statische Blöcke hinterlegt sind, der irrt, das wäre doch zu einfach.

Problem:
Magento Connect Manager -  Error: Please check for sufficient write file permissions
Your Magento folder does not have sufficient write permissions, which this web based downloader requires.

Lösung

Wechseln Sie auf dem Linuxrechner in das Verzeichnis, in welches Sie Magento installiert haben ( standardmäßig ”Magento” bzw. im Apache-DOCROOT) und setzen Sie die folgenden Befehle ab, um Ihre Zusatzmodulinstallation vornehmen zu können:

Danach müssen Sie unbedingt wieder die Zugriffsrechte zurücksetzen:

Lösungsansatz: Anpassung der E-Mail Vorlage

Die hierfür zu ändernden Dateien sind:
order_new.html und   order_new_guest.html

Nach der anfänglichen Euphorie ist im Jahr 2009 die Ernüchterung eingekehrt:

• Magento ist “out-of-the-box” nicht für den deutschen Markt, mit den von einem Onlineshop zu erfüllenden gesetzl. Bestimmungen, einsetzbar.
• Magento erfordert die Einschaltung einer Agentur zur Anpassung und Pflege des Shops. Shopbetreiber mit nur oberflächlichen PHP-Kenntnissen werden hier Schiffbruch erleiden.
• Magento mag zwar ein Open-Source Programm sein, wer dies allerdings mit kostenlos gleichsetzt, begeht seinen ersten Irrtum. Man sollte meines Erachtens mit 3000 – 5000 EUR Anlaufkosten rechnen.
• Magento setzt das PHP Zend-Framework  ein. Leider ist dies kein Garant für Softwarequalität. Die aktuelle Release ist immer noch sehr fehlerhaft.
• Magento stellt hohe Anforderungen an die Hardware, um einen Shop performant zu betreiben.
• Magento’s API für den Datenzugriff ist sehr langsam.
• Magento besitzt direkt keine Gesamtexportmöglichkeit um einen Shop leicht auf einen anderen Server zu portieren, so dass hier richtig Handarbeit und Knowhow erforderlich ist (Gesamtexport = Datenbank + individuelle Codeanpassungen + dazugenommene Plugins + hinzugefügte shopspezifischen Attribute + hinzugefügte statische Seiten + hinzugefügte Rabattregeln, Geschäftsregeln, etc + Export von mehreren Bildern zu einem Artikel, und und und …)

Erfreulich fand ich deshalb, auch einmal anderenorts eine kritsche, aber ehrliche Auseinandersetzung über Magento lesen zu können:

magento-news – 5 Fragen, die entscheiden, ob Magento Commerce das richtige Shopsystem für sie ist

Wenn beispielsweise eine neue Rechnung angelegt wird, dann wird vom System automatisch eine fortlaufende Nummer erzeugt. Damit wird - auf den ersten Blick jedenfalls – die deutsche, gesetzliche Vorgabe an eine ordentliche Rechnungsnummer erfüllt. Der Haken bei der Sache ist, dass die Rechnungsstartnummer nicht durch den Shop-Administrator konfigurierbar, sondern in der Datenbank fest hinterlegt ist.  

Nun mag der eine oder andere, der schon eine MySQL-Datenbank administriert hat, sofort einwenden: "Es ist doch ein Klacks bei einer MySQL Datenbank die Autoincrement-Zahl hochzusetzen." Aber die Magento Programmierer arbeiten nach dem Motto: "Warum einfach, wenn es auch kompliziert geht, schließlich wollen wir und die Web-Agenturen ja auch was an Support verdienen".

Die Rechnungsnummer wie auch andere Nummernkreise wie z. B. die Kunden- oder Bestellnummer sind keine normalen Primärschlüssel, sondern Tabellenattribute und diese sind über mehrere Tabellen verteilt und ergeben erst in Kombination z. B. die Rechnungsnummer.  

Probleme, die die Festverdrahtung der Rechnungsnummer mit sich bringt:

1. Länge der Startrechnungsnummer: Die Rechnungsnummer eines neu aufgesetzten Magento-Shops beginnt bei 100000001. Hand aufs Herz, wer kann sofort sagen, wieviel Nullen zwischen der führenden und der abschließenden Null liegen.  Wenn der Kunde eine solche Zahl auf seine Überweisung zu übertragen hat, dann kann man sicher sein, dass man des öfteren falsche, nicht ohne manuelle Nachbearbeitung zuordenbare Überweisungen hat. (Antwort auf die Eingangsfrage: Die Rechnungsnummer ist neustellig mit sieben, eingeschlossenen Nullen am Anfang.)
2. Fortschreibung der Rechnungsnummer: Meistens möchte der Shopbetreiber ja seine Rechnungsnummer fortschreiben, also bei z.B. 303435 beginnen.  Oder er möchte für seinen Online-Shop einen eigenen Nummernkreis mit Prefix besitzen (z.B. 309-303435) besitzen, zur Unterscheidung zu seinem Ladengeschäft (dort mit Präfix 109-….).
3. Upgradeproblematik:  Die Qualität der Upgrades und Updates von Magento läßt sehr zu wünschen übrig. Es wird ausdrücklich davor gewarnt,  bei einer Produktivumgebung niemals etwas ohne eine vorherige Sicherung einzuspielen. Nicht ohne Grund, denn oft ist ein System nach dem Upgraden nicht mehr lauffähig. Wenn man jedoch eine Grundinstallation des Programm vornimmt, dann beginnt das System wieder bei der Rechnungsstartzahl 100000001! 

Das soeben geschriebene gilt natürlich in gleicher Weise auch für die Kunden- und Rechnungsnummer. Dass diese Nummern, die für einen Shop von grundlegender Bedeutung sind, nicht durch einen Administrator einfach veränderbar sind, empfinde ich deshalb als sehr ärgerlich.

Dankenswerterweise kann man bei blogtabs.de eine Anleitung finden, wie dieses Manko behoben werden kann. Es gehört aber schon etwas Fachwissen und Mut dazu, derartige manuelle Veränderungen in der Datenbank vorzunehmen.

Hinweis: Eine Änderung des Rechnungsprefix in der Datenbank entsprechend der obigen Anleitung wurde direkt bei der nächsten Bestellung umgesetzt. Die Längenänderung des Rechnungsnummernbestandteils (Tabelle eav_entity_type,  Feld increment_pad_length) wurde vom System erst nach einem Serverneustart berücksichtigt!

(Anmerkung: Dieser Artikel bezieht sich auf die am 14. Juli 2009 aktuelle Magento Version 1.3.2.2.
 Wenn in einer zukünftigen Magentoversion hier eine Abhilfe geschaffen wurde, dann bitte ich darum, dies durch einen Kommentar zu diesem Artikel mitzuteilen.)