In diesem Post wird erklärt, wie man eine vollständige Migration aller Produkte von einem Magento-Shop in einen anderen durchführt.

Es werden dabei die relevanten Datenbanktabellen aus der einen Magento-Datenbank exportiert und in die andere wiederum importiert, damit folgende Informationen übertragen werden:

• Attribut-Struktur
• Attribut-Sets
• Produkte
• Attribute der Produkte

Vorsicht: Diese Methode wurde nicht für Multi-Shops geprüft. Ebenso wenig wurde getestet, ob diese Art der Datenmigration auch reibungslos funktioniert, wenn individuelle Produktoptionen angelegt sind. Außerdem funktioniert dieser Import-Export nur, wenn es sich um eine neue Magento-Datenbank handelt, in der die Produkte importiert werden sollen.

Für schon bestehende Shops mit vorhandenen Artikeln ist die Datenmigration etwas anspruchsvoller, weil die Attribute dann an das jeweilige Attributset angepasst werden müssen.

1. Folgende Tabellen müssen aus der alten Datenbank exportiert werden. Dies geht am einfachsten via PhpMyAdmin oder einem Programm wie Sequel Pro:
   •  Tabellen beginnend mit “eav_attribute” (6 Tabellen)
     • eav_attribute
     • eav_attribute_group
     • eav_attribute_label
     • eav_attribute_option
     • eav_attribute_option_value
     • eav_attribute_set
   • Die Tabelle “eav_entity_attribute”
   • Alle Tabellen beginnend mit “catalog_product” (dies sind insgesamt über 60 an der Zahl. Die Anzahl kann variieren, je nach dem ob flat-Tables verwendet werden.)
   • Die Tabelle “catalog_eav_attribute”
   • Falls die Bestände (für Lagerverwaltung) übertragen werden sollen: Alle Tabellen, die mit “cataloginventory” beginnen. (5 Tabellen)

   Insgesamt müssen also ca. 70 Tabellen exportiert werden

2. Als nächstes müssen diese dann in die neue Datenbank (ebenfalls über ein Hilfsprogramm oder auch über die Shell) importiert werden.

Und schon ist die Migration erledigt!

Will man per FTP Dateien oder Verzeichnisse direkt von einem Server auf den anderen kopieren, eignet sich am besten wget, weil dies oft auf einem Linux-Server zur Verfügung steht (z.B. bei einem managed Server).

Wie man das macht?

1.) per SSH auf dem Server einloggen, auf dem die Dateien kopiert werden sollen.

2.) Folgendes in die Shell eingeben:

Das -r  steht für recurively, d.h. alle darunterliegenden Verzeichnisse und Dateien werden nun kopiert.

Wohin wird das ganze kopiert? Im Verzeichnis, wo man sich gerade auf dem Server befindet. Von da aus kann man die Ordner/Dateien wieder an den gewünschten Zielort kopieren.

Einführung und Grundlegendes Git:

• Git-Repositories sind nichts anderes als (versteckte) Dateien mit dem Namen “.git”
• In diesen werden der Stand und die Veränderung (Deltas) des jeweiligen Ordners gespeichert. Normalerweise liegt die “.git”-Datei in dem Projektordner.
• Im Terminal kann man zum Projektordner navigieren. Wenn das Repsoitory angelegt ist, findet man mit dem Befehl
  ls -a -l
  alle Dateien, auch die versteckten, d.h. hier kann man einfach herausfinden, ob “.git” existiert.
• Commit bedeutet, dass die Änderungen in dem lokalen Repository gespeichert werden.
• Push bedeutet, dass die Änderungen vom lokalen Repository in das Repository des Servers hochgeladen werden

Starte das Git Repository (git init):

• Mache eine Sicherungskopie des Projektordners. (Das beruhigt, falls du bedenken hast, dass du irgendetwas kaputt machen könntest)
• Navigiere in den Projektordner, zu dem ein Repository angelegt werden soll und gebe folgenden Befehl ein:
  git init
  Dadurch wird ein leeres Repository angelegt.
• Nun kannst du Dateien zu diesem Repository hinzufügen:
  git add <filename>
  Falls du alle Dateien im Projektordner hinzufügen möchtest:
  git add *
  Je nach Größe des Projektordners kann das ein Weilchen dauern.

Änderungen lokal speichern (commit):

• Jetzt kannst Du Änderungen in dein lokales Git “commiten”, d.h. dass die Änderungen, die du als letztes Durchgeführt hast, auch im Repository gespeichert werden:
  git commit -m "First Commit"

Repository auf dem Server starten:

• Um ein Repository auf dem Server zu speichern, musst du als erstes das erstelle Git-Repository auf den Server hochladen. Hierfür benötigst du als erstes eine Kopie der Datei “.git”, die du lokal am besten über das Terminal erstellst. Falls Du immer noch im Projektordner bist, gebe ins Terminal folgenden Befehl ein:
  git clone --bare .git projectname.git
• Als nächstes lädst du diesen auf den Server hoch. Das geht auch im Terminal mit dem Befehl scp (siehe auch: Dateien per ssh von Mac auf Server kopieren):
  
  1 2 3

  scp -r projectname.git user@meinserver.de:/home/meine-git-repositories/

• Der Vollständigkeit halber, kannst du nun das lokal-kopierte Git-Repository entweder im Finde oder aber direkt über das Terminal löschen:
  rm -rf projectname.git
• Nun musst Du dem lokalen Repository mitteilen, dass ein “Remote-Repository” irgendwo da draußen ist, mit es es die Änderungen abgleich soll. Das geht per ssh und über den Befehl git remote:
  
  1 2 3

  git remote add origin ssh://user@meinserver.de:/home/meine-git-repositories/projectname.git

Änderungen vom lokalen ins Server-Repository hochladen (push)

• Wenn Du alles so gemacht hast, wie oben beschrieben, kannst Du nun die Änderungen in das Server-Repository hochladen. Das nennt man “Push”:
  git push origin master

ssh dateien kopiern mac – Wie kann man Dateien per SSH vom Server auf den eigenen, lokalen Mac kopieren?

Auf dem Mac muss das Terminal geöffnet werden, auf den Server per SSH einloggen und dann:

<port> Port (normalerweise 22)

<user> SSH-Benutzer

<host> SSH-Hostname (Server)

/path/to/filename.txt –> Pfad zum Dateinamen

path/to/local/directory –> Pfad zum lokalen Server

Beispiel: Eine MySQL-Backup-Datei vom Server (www.meinserver.com) in einen neuen Ordner auf dem Desktop kopieren:

Nach dem Umzug eines Magento-Shops auf einen anderen Server kommt es des öfteren zu folgendem Fall: Die Startseite des Shops lässt sich ohne Probleme anzeigen, die Unterseiten, Kategorien und Produktdetailseiten des Magento-Shops zeigen allerdings einen 404-Error.

Folgend eine kleine Checkliste, welche die gröbsten Fehler beheben kann:

1.) Datenbank überprüfen:
In der Tabelle core_config_data müssen Einträge an folgenden Stellen angepasst werden:
path=web/unsecure/base_url
path=web/secure/base_url
Hier muss in der Spalte Value jeweils die neue Shop-Adresse angegeben werden.

2.) Außerdem ist es ratsam, folgenden SQL-Befehl auszuführen

3.) Einer der häufigsten Fehler findet sich in der .htaccess-Datei:

Hier findet sich normalerweise ein Abschnitt für die rewrite-rules, der in etwa so aussieht.

An dieser Stelle muss die Rewrite-Regel für Verzeichnisse auskommentiert werden, sprich, folgendes angepasst werden:

4.) Ist der 404-Error immer noch vorhanden, so liegt es vielleicht an den Zugriffsrechten, die folgendermaßen zu setzen sind:

Wichtig: die Zugriffsrechte sind abhängig von den Apache-Einstellungen, d.h. dies ist nur ein Vorschlag. Wenn man einen Test machen möchte, ob es daran liegt, kann man auch folgendes ausprobieren (nur für kurze Zeit, da die Ausführbarkeit aller Dateien zu Sicherheitsproblemen führt):

5.) Anpassung in der Datei index.php (im root-Verzeichnis):

Ersetzt folgende Zeile

durch:

Hat all dies nicht zum gewünschten Ergebnis geführt, so bitte ich dies zu kommentieren bzw. sagt mir, was eure Lösung gewesen ist.

Der Magento Cron Job ist folgendermaßen organisiert:

• Der Server muss so eingestellt sein, dass alle 15 min (oder alle 5 Minuten oder jede Minute) folgendes Script aufgerufen werden muss:
  http://www.magentoroot.com/cron.php
• Innerhalb der Programmstruktur von Magento sind die einzelnen aufgerufenen Methoden über die XML-Config-Dateien der einzelnen Module definiert.
• Jedesmal, wenn http://www.magentoroot.com/cron.php aufgerufen wird, geht Magento die einzelnen XML-Config-Dateien durch, führt die Methoden aus, die in der jüngsten Vergangenheit ausgeführt werden sollen und terminiert die zukünftig auszuführenden Methoden.

Wie kann mann überprüfen, ob die Servereinstellung überhaupt richtig ist?

Dafür bietet sich an, einmal in eine Config-Datei des Magento-Core-Codes zu schauen:
in app\code\core\Mage\CatalogRule\etc\config.xml definiert der XML-Handle catalogrule_apply_all eine Funktion namens:
dailyCatalogUpdate in Mage_CatalogRule_Model_Observer, was man an folgendem Code sehen kann:

Fügt man also in der Funktion dailyCatalogUpdate in Mage_CatalogRule_Model_Observer eine Log-Methode ein, z.B.

… so sollte sich innerhalb der nächsten Stunde im Verzeichnis var/log eine Datei mit dem Namen my_cron_log finden, in der “test cron” steht.

Wie verwende ich das individuelle Layout von Magento mit eigenen Templates?

Bearbeitet man eine CMS-Seite in Magento, so findet sich im linken Menu der Punkt Design. Hier kann man im Dropdown-Menu zwischen den zu verschiedenen zu Verfügung stehenden Layouts, wählen.

Diese sind in der Datei page.xml des jeweiligen Themes definiert.

Will man aber in einen bestimmten Bereich (in unserem Beispiel: content) ein bestimmtes (eigen entwickeltes) Template einsetzen, so erreicht man dies durch folgenden XML-Code, den man in das Textfeld XML für Layoutänderung einsetzt:

Im Beispiel wurde eine Suchmaske, die durch die Datei search/left.phtml definiert ist, in die Fehlerseite (404) eingesetzt, um somit Kunden die Möglichkeit zu geben, von der 404-Fehlerseite direkt im Shop zu suchen.

Hier auch der Screenshot dazu: