mod_rewrite (Apache2-Server)

Dieser Artikel widmet sich dem Thema mod_rewrite, zu dem vielleicht bei dem ein oder anderen hin und wieder die selben Fragen auftauchen.

Was ist “mod rewrite” oder mod_rewrite?

Erstens: mod_rewrite ist eine Einstellung des Apache-Servers. D.h. mod_rewrite ist entweder an (enabled) oder aus (disabled).

Zweitens: Wenn mod_rewrite an ist, so können URLs umgeleitet werden. D.h. die folgende URL …

 

… wird durch die Einstellungen von mod_rewrite umgeformt zu:

Wie stelle ich fest, ob mod_rewrite aktiv ist?

Ganz einfach: Erstelle eine leere php-Datei mit dem Inhalt:

Rufe diese auf dem Browser auf und suche mit der Suchfunktion des Browsers nach “mod_rewrite”. Wenn du einen Eintrag findest, wie im Screenshot dargestellt, so ist mod_rewrite an.

mod_rewrite_enabled_phpinfoEine andere Möglichkeit ist, einfach in der Shell den Befehl php -info einzugeben und dann zu schauen, ob mod_rewrite unter der Rubrik “Loaded Modules” auftaucht.

Wie aktiviere ich mod_rewrite, wenn es nicht aktiv ist?

Ich möchte hier zwei Möglichkeiten vorstellen, mod_rewrite zu aktivieren. (Es gibt noch eine dritte, sehr einfache Variante, die manchmal am Effektivsten ist: Nämlich einfach den Hoster anzufragen, ob er mod_rewrite aktivieren kann. Manchmal ist dies auch nötig, denn bei bestimmten Hostern sind die Rechte für die Apache-Cofing-Datei beschränkt und man hat gar keine andere Möglichkeit)

1. Die schnelle Variante, mod_rewrite zu aktivieren:

Gebe in der Shell von Linux einfach folgenden Befehl ein:

Dann musst Du noch den Apache-Server neustarten:

Falls dann in der Shell folgendes auftreten sollte …

… versuche es mit Möglichkeit 2:

2. mod_rewrite in apache-Config-Datei anschalten

Das ist etwas kniffliger: zuerst musst du die Datei apache2.config finden, was allerdings sehr einfach über folgenden Shell-Befehl geht:

Hierdurch findest du Einträge wie:

Dann gibst du folgenden Befehl ein:

Und du solltest als Ausgabe sehen, wo die HTTPD_ROOT-Directory ist und wie das SERVER_CONFIG_FILE heißt:

nun weißt du, wie der Pfad zur Datei lautet und kannst diese mit beispielsweise nano (oder alternativ auch per FTP) editieren:

Folgende Zeile muss in der Datei enthalten sein:

Nun muss nur noch der Apache-Server neu gestartet werden …

Und mod_rewrite sollte aktiviert sein.

 

 

 

Git Repository lokal erstellen und dann auf den Server uploaden (Mac)

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):
  • 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:

Ä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 kopieren mit dem Terminal auf dem Mac (SCP)

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:

 

 

Magento 404-Error auf Unterseiten (z.B. nach Serverumzug) Lösung

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:
change a little part in the .htaccess file:

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 bleibt noch die Chance, die Zugriffsrechte zu verändern:

 

Umziehen von einem Magento-Shop auf einen anderen Server

Da ich mir die Informationen aus irgendwelchen Quellen zusammensuchen musste, gebe ich hier eine kurze und knappe Übersicht der Hauptpunkte, die bei einem Umzug von Magento zu einem anderem Server beachtet werden sollten:

1. Kopieren der Dateien
Kopieren aller Dateien auf das gewünschte Verzeichnis des neuen Servers. Das kann man am einfachsten per FTP machen. Z.B. mit FileZilla, wobei man aufpassen sollte, dass wirklich alle Dateien kopiert werden. Bei Filezilla gibt es unten ein Tab, indem die fehlerhaft übertragenen Dateien aufgelistet werden. Diese sollte man anschließend nochmals in die Warteschleife setzen (per Rechtsklick). Außerdem ist es empfehlenswert, bei dem FTP-Programm einzustellen, dass mehrere Dateien gleichzeitig übertragen werden können.
Anschließend läd man den gesamten Ordner auf den neuen Server ins gewünschte Verzeichnis.

Per FTP dauert sowohl das Herunterladen also auch der Upload eine halbe Ewigkeit (mehrere Stunden)!! Also viel Zeit einplanen!

2. Magento Datenbank kopieren
Das geht etwas fixer!
– in PHPmyAdmin: die Datenbank anwählen, in der die Magento-Daten gespeichert sind.
– Alle Tabellen die mit “log_” beginnen, können problemlos geleert (nicht gelöscht!) werden. Das macht die Datenbank etwas kleiner.
– In den erweiterten Optionen für den Export: Fremdschlüsselüberprüfung deaktivieren. (Ansonsten lässt sich die Datenbank nicht mehr richtig importieren)
– Export als Dateiname.sql

Auf den neuem Server am besten auch mit PHPmyAdmin arbeiten, Hier:
– Import der .sql-Datei, also der Tabellen in die gewünschte Datenbank.
Wenn es bei diesem Schritt Probleme gibt, nochmal überprüfen, ob beim Export auch wirklich nur die Tabellen (nicht die komplette Datenbank) exportiert wurde und ob die Fremdschlüsselüberprüfung für den Export deaktiviert worden ist.

3. Datenbankeinstellungen von Magento
– Folgendes File muss angepasst werden: app/etc/local.xml
– Hier muss der Name, Username und PW der neuen Datenbank hin, damit Magento darauf zugreifen kann.

4. Domainadresse für Magento ändern.
Oft kommt es vor, dass man den Shop auf einer Test-Domain zuerst einmal ausprobieren möchte, bevor man den kompletten Umzug vollzieht. Das ist natürlich auch sinnvoll! Ein andere Möglichkeit ist, dass man komplett auf eine andere Domain umziehen möchte.
In diesen beiden Fällen muss man die URL im System von Magento manuell ändern. Normalerweise wird die URL im Admin-Panal in der Konfiguration des Magento-Backends festgelegt, falls wir das aber Manuell machen möchten, so müssen wir wieder mit PHPmyAdmin auf die Datenbank.
Genauer gesagt:
– In der Tabelle: core_config_data
– In Zeile mit path=”web/unsecure/base_url” im Feld “value” die neue (Test-)URL eintragen.
-In Zeile mit path=”web/secure/base_url” ebenfalls im Feld “value” die neue (Test-)URL eintragen.

Fertig!
Nun kann man den Shop unter der neuen URL testen. Sollte alles problemlos funktionieren, so kann man auf der alten URL eine IP-Weiterleitung auf das Verzeichnis des neuen Servers einstellen. Und los geht’s!!!

Testen ob der Magento Cron funktioniert

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.

CMS-Content mit XML-Layout in Magento ändern.

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:

Magento-XML-Layout

In Magento ein Attribut im Nachhinein ändern (Einzeiliges Textfeld zu Mehrzeiligen Textfeld ändern)

Wenn man im Magento-Shop-System ein neues Attribut erstellt und im Wert “Katalog Eingabe-Typ für den Shopbetreiber” einzeiliges Textfeld eingibt, so lässt sich dieser Wert im Nachhinein leider nicht mehr verändern.

Dies kann dazu führen, dass man im späteren Betrieb die Feststellung macht, dass die Zeichenlänge bei einem einzeiligen Textfeld, die auf 256 Zeichen beschränkt ist, nicht mehr ausreicht.

Abhilfe verschafft eine relativ einfache Veränderung in der Datenbank, für die ich allerdings etwas suchen musste. Deswegen sei sie hier erklärt:

  1. In der Magento-Datenbank die Tabelle eav_attribute öffnen.
  2. Zeile mit dem richtigen Attribute-Code (Spaltenname ist eav_attribute) aufrufen.
  3. Änderung von den folgenden beiden Einträgen:
    backend_type –> in text (anstatt varchar) ändern.
    frontend_input –> in textarea (anstatt text) ändern.

Das alles lässt sich über die Shell auch sehr einfach mit folgendem mySql-Befehl erledigen:

 

my_attribute_code ist natürlich der Attribute-Code von dem Magento-Attribut, dessen maximale Anzahl von Zeichen im Textfeld verändert sein sollen.