Änderungen in der Datenbank
Aber Dateien sind ja nur die eine Hälfte von Magento. Die andere Hälfte, sprich die Datenbank, ist leider nicht so leicht zu kontrollieren und zu versionieren.
Konsequent benutzte Install-Skripte können hier einige der größten Probleme lösen. Attribute, auch solche für Produkte, sollten nur mit Skripten angelegt werden, Kategorien, Kategoriebäume, Websites, Storegroups und Stores werden auch nur mit Skripten erzeugt. Mit diesem Vorgehen hat man schon einen relativ konsistenten Stand zwischen Entwicklungsumgebung, Testsystem, Staging und Live-System. (An dieser Stelle denken wir uns beliebige andere Systeme, z.B. ein Contionous-Integration System auf dem die Tests laufen oder beliebig viele Entwicklungssysteme für die einzelnen Entwickler). Das Problem ist, dass alle Tests, ob automatisiert oder durch einen Menschen, wenig verlässlich sind, wenn die Systeme nicht gleich konfiguriert sind. Daneben bleiben noch einige Bereiche: unter anderem alles unter
System > KonfigurationDieser Blogbeitrag soll sich aber der Konfiguration widmen und eine Methode vorstellen, die euch hoffentlich in der täglichen Arbeit hilft. Ich bin noch nicht überzeugt, dass das folgende eine gute Idee ist. Ich freue mich über eine rege Diskussion in den Kommentaren.
Mage_Core_Model_Config
Die Magentokonfiguration speist sich aus vielen verschiedenen Quellen, Carmen aka neoshops hat im letzten Jahr einen tollen Beitrag zu dem Thema geschrieben, der weiter in die Tiefe geht als ich jetzt.
Konfigurationsquellen
Kurz gesagt, Magento lädt folgende Dateien:
app/etc/local.xml
app/etc/*.xml
app/etc/modules/*.xml
app/code/<codePool>/<Namespace>/<Module>/etc/config.xml
app/etc/local.xmlMan beachte hierbei, dass am Ende des Prozesses die local.xml noch einmal geladen wird. Das hat zur Konsequenz, das alles was in der
local.xmlScope
Die Konfiguration hat drei Scopes:
- Storeview
- Website
- Default
Magento bietet die Möglichkeit Konfigurationswerte, also z.B. die Base-URL, den Namen des Stores oder die verwendete Sprache auf verschiedenen Ebenen zu definieren. Die Ebenen vererben die Einstellungen an ihre Kinder.
Default
|-- DVD und Video Shop (Website)
| |-- deutscher Shop (Store Group / Store)
| | |-- deutsch (Store / Store View)
| | +-- englisch (Store / Store View)
| +-- schweizer Shop (Store Group / Store)
| |-- französisch (Store / Store View)
| |-- italienisch (Store / Store View)
| +-- schweizerdeutsch (Store / Store View)
|
+-- Shirt und Pullover Shop (Website)
...Leider hat Magento irgendwann die Bezeichnungen getautscht. So ist im Code von Website, Storegroup und Store die Rede, aber im Backend von Website, Store und Store View.
alt | neu
Website | Website
Store Group | Store
Store | Store ViewBeispiel:
Das Impressum für die beiden Websites ist gleich (default), aber beide Websites haben unterschiedliche Namen. Diese werden allerdings an alle Storeviews vererbt. Abschließend stellen wir unabhängig von Website und Default auf Storeview-Ebene die Sprache ein.
System > Konfiguration
Bei den meisten Shops läuft es so, dass jemand in das Backend geht und die Einstellungen macht. Diese werden dann in der Datenbank gespeichert. Im besten Fall, wird die Datenbank kopiert und auf die verschiedenen Systeme gespielt. Im schlimmsten Fall, "kopiert" jemand die Einstellungen manuell und vergisst dabei hoffentlich keine. Ich möchte eine Alternative dazu vorstellen.
Konfigurationsvariablen
Alan Storm hat einen langen, langen Artikel zum Thema Konfigurationsvariablen geschrieben, wer also mehr technischen Hintergrund haben möchte zu dem folgenden, einfach dem Link folgen.
Aufbau der Konfiguration
Die verschiedenen Scopes werden in der Konfiguration folgendermaßen abgebildet:
<config>
<default>
</default>
<websites>
<admin></admin>
<base></base>
</websites>
<stores>
<admin></admin>
<default></default>
</stores>
</config>Magento kümmert sich beim Laden der Konfiguration bereits darum, die Vererbung durch kopieren der Knoten zu realisieren, d.h. wenn folgende Knoten und Werte gibt
default/general/imprint/shop_name => Mein cooler Shopname
websites/admin/general/imprint/shop_name => Adminshopaber keine Knoten
websites/base/general/imprint/shop_name
stores/admin/general/imprint/shop_name
stores/default/general/imprint/shop_namekopiert Magento die Werte an die entsprechenden Stellen unterhalb der Vererbungshierarchie:
stores/admin/general/imprint/shop_name => Adminshop
websites/base/general/imprint/shop_name => Mein cooler Shopname
stores/default/general/imprint/shop_name => Mein cooler ShopnameMage_Core_Model_Config->_xml
Die Konfiguration innerhalb des Konfigurationsmodels wird auch nach dem zusammenführen aller Quellen weiter als XML behandelt. Wichtig hierbei ist, dass wir jeden Knoten innerhalb der Konfiguration aus vielen XML-Dateien beinflussen können.
local.xml, *.xml, config.xml, local.xml
Insbesondere halte ich hier die
app/etc/local.xmlapp/etc/*.xmlconfig.xmlapp/etc/modules/*.xmlconfig.xmlapp/etc/<?xml version="1.0"?>
<config>
<stores>
<de>
<general>
<store_information>
<name>Deutscher Store View</name>
</store_information>
</general>
</de>
</stores>
<websites>
<another_website>
</another_website>
<websiteA>
<general>
<store_information>
<name>Website A</name>
</store_information>
</general>
</websiteA>
</websites>
<default>
<admin>
<security>
<use_form_key>1</use_form_key>
<use_case_sensitive_login>1</use_case_sensitive_login>
</security>
<dashboard>
<enable_charts>1</enable_charts>
</dashboard>
<captcha>
<enable>0</enable>
</captcha>
</admin>
</default>
</config>Diese Konfiguration, die für alle Instanzen gelten soll, wird also in
app/etc/local.live.xmlapp/code/local.xmlTipps zum Ende
Um die Konfiguration das erste Mal in die Datei zu kriegen, kann man diese im Backend erstellen und ein kleines Script schreiben um die Datei zu erzeugen. Ich habe bisher die Datei immer von Hand erstellt, weil es mich furchtbar nervt mich durch das Backend zu klicken. Falls jemand ein kleines Script hat, einfach rein in die Kommentare.