PHP Einstellungen für Magento

Publiziert am 22. November 2010 von Tim

Magento nutzt kein externes Template System.
Das heißt der PHP Code zur Generierung der dynamischen Inhalte steht direkt in den HTML-Templates, die deswegen auch mit der Endung .phtml enden.
Beispiel:

1

<?php echo "Hier kommt PHP Code" ?>

Wichtig ist hierbei, dass der PHP code mit <?php eingeleitet wird.

Bei einigen zusätzlichen Modulen nutzen die Modulprogrammierer allerdings die verkürzte Schreibweise, die nur mit „<?“ (ohne php) beginnt, um die dynamischen Inhalte mit PHP einzufügen.
Das sieht dann z.B. wie folgt aus:

1

<? echo "Hier kommt PHP Code" ?>

Das Problem dabei ist, das PHP standardmäßig so konfiguriert ist, dass der PHP Code innerhalb der verkürzten Schreibweise nicht interpretiert wird. Das heißt der PHP Code landet direkt so im Quellcode der Webseite, da er vom PHP Interpreter nicht verarbeitet wird. Damit das geschieht, muss in der php.ini der folgende Wert auf „On“ gesetzt werden.

1

short_open_tag = On

Nach einem Neustart des Apaches funktionieren dann beide Schreibweisen, um PHP Code im HTML einzubinden.

Veröffentlicht unter Magento, PHP | Verschlagwortet mit , , , , | Hinterlasse einen Kommentar

Magento – Konfigurationsdateien

Publiziert am 31. August 2010 von Tim

Magento bietet eine unglaublich große Flexibiliät, was die Anpassung des Systems angeht. So lassen sich z.B. zahlreiche Änderungen am Layout der Seiten über einfache XML Dateien in den einzelnen Modulen realisieren. Die Dateien werden dabei im jeweiligen Modul im Ordner etc/ gespeichert. Es ist zum Beispiel auch möglich einen neuen Konfigurationswert anzulegen, der über die Adminoberfläche verwaltet werden kann, ohne eine einzige Zeile PHP zu programmieren. Das heißt alle Einstellungen für die neue Variable werden lediglich in den XML-Files gemacht. Ein kleines Beispiel dafür folgt im nächsten Artikel an dieser Stelle.

Hier aber erst mal eine Übersicht der einzelnen unterschiedlichen XML-Files und ihrer Funktionen im Magento System:

apc/etc/config.xml

In dieser Datei sind ein paar zentrale Konfigurationswerte für den Magento Shop hinterlegt, wie die Datenbankzugangsdaten, Zeitzoneneinstellungen und die Systempfade. An dieser Datei muss man in der Regel nichts manuell ändern, da dies bereits über das Installationsskript erledigt wird.

apc/etc/local.xml

Wenn mehrere Programmierer zusammen an einem größeren Magento Projekt arbeiten, ist es in der Regel üblich, dass jeder Entwickler sich lokal auf seinem Rechner eine Entwicklungsumgebung einrichtet, die aktuelle Projektversion über eine Versionsverwaltung wie z.B. SVN oder CVS auscheckt und dann lokal seine Programmierarbeiten durchführt und testet, bevor er sie dann ins Repository zurückspielt. Da die lokale Entwicklungsumgebung sich natürlich von der Umgebung auf dem Test oder Live-Server unterscheidet, kann jeder Entwickler in der local.xml seine lokalen Einstellungen vornehmen, z.B. die Zugangsdaten für seine lokale Datenbank eintragen oder den Pfad für die Session-Files anpassen. Diese Datei sollte dann natürlich nicht zurück ins Repository gespielt werden.

apc/etc/modules/Mage_All.xml

In diesem File sind alle Magento Core Module registriert. Für jedes Modul gibt es dabei einen kleinen Eintrag, der z.B. wie folgt aussieht

1
2
3
4

<mage_page>
   <active>true</active>
   <codepool>core</codepool>
</mage_page>

Alle selbst programmierten Module müssen in diesem Ordner registriert werden. In der Praxis hat es sich dabei bewährt eine einzelne Datei für alle eigenen Module zu verwenden, analog zu der Mage_All.xml könnten man diese dann z.B. MyModules_All.xml nennen.

app/code/[codepool]/[namespace]/[modulname]/etc/config.xml

Die Basis Einstellungen für ein Modul werden in dieser Datei hinterlegt. Dazu gehören unter anderem

  • Überschreiben oder Registrieren von Models, Controllern, Blöcken, Helpern oder Widgets im Frontend und im Backend
  • Konfiguration der Router
  • Datensatzformate definieren (z.B. Felder der Kundenadresse für PDF Rechnungen definieren)
  • Setup Skripte für Datenbank Anpassungen konfigurieren
  • eigene Übersetzungsfiles für das jweilige Modul definieren

app/code/[codepool]/[namespace]/[modulname]/etc/system.xml

In dieser Datei werden die Menüeintrage eines Moduls im Backend konfiguriert. Man kann also neue Menüeintrage anlegen und Konfigurationswerte definieren. Eine genau Beschreibung dieser Mechanik folgt demnächst in einem eigenen Artikel, da das ein recht komplexes Thema ist.

app/code/[codepool]/[namespace]/[modulname]/etc/adminhtml.xml

In dieser Datei werden die Zugriffsbeschränkungen mit Hilfe der Zend Framework Komponente Zend_Acl (Access Control List) für die Menupünkte eine Moduls definiert. Es kann also genau festgelegt werden, welcher Backend User auf welche Menüpunkte Zugriff hat. Auch hier würde eine genau Erklärung dieser recht komplexen Mechanik den Rahmen diese Artikel sprengen.

Anfang ist es für Magento Einsteiger sicherlich recht verwirrend, welche Informationen in welcher Xml-Datei hinterlegt sind, wenn man das Prinzip aber erst einmal durchschaut hat, ist es durchaus ein interessante Sache, die einem sogar hin und wieder die Arbeit erleichtert.

Ein Nachteil dieser XML-basierten Konfiguration soll allerdings nicht unerwähnt bleiben. Beim Aufbau der Seite eines Magento Shops werden alle Informationen aus allen Xml-Files gesammelt und praktisch zu einer einzelnen großen Datei zusammengefügt. Diese Datei bildet dann das Gerüst des Magento Shops und wird mittels der PHP SimpleXML-Funktionen geparst und verarbeitet. Genau da liegt dann auch der Knackpunkt der Geschichte, da die XML Verarbeitung unter PHP performance-technisch nicht unbedingt zu den großen Highlights gehört. D.h. diese Vorgehensweise ist meiner Meinung nach einer der Ursachen, für die relativ schlechte Performance des Magento Systems. Mit Hilfe von Xdebug kann man z.B. sehen, dass allein die Funktion SimpleXMLElement::children über 6000 Mal beim Erstellen der Startseite des Shops aufgerufen wird.

Veröffentlicht unter Magento | Verschlagwortet mit , , , , , , | Kommentare deaktiviert für Magento – Konfigurationsdateien

Magento – Community Wunschliste

Publiziert am 24. August 2010 von Tim

Ein großer Vorteil bei Magento ist sicherlich, das es bereits über eine sehr große und aktive Community verfügt. Diese Community treibt die Entwicklung des Shop-Systems auf unterschiedliche Weise voran.
Ein Beispiel ist das Magento Feedback Forum, eine Art Wunschliste, in der sich praktisch jeder anmelden kann und seine Wünsche für Anpassungen, Optimierungun oder neue Features in zukünftigen Magento Versionen eintragen kann. Außerdem hat jeder registrierte User eine bestimmte Anzahl von Stimmen, die er auf die bereits vorhandenen Einträge verteilen kann. Somit kann man also mit seiner Stimme indirekt an der Weiterentwicklung von Magento mitwirken.
Hier gibt es das Ganze zu bewundern.

Veröffentlicht unter Magento | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

Magento – Spam Problematik bei Transaktionsmails

Publiziert am 19. August 2010 von Tim

Viele Shopbetreiber, die Magento einsetzen, haben das Problem, dass die Transaktionsmails (z.B. die Bestellbestätigung, oder die Bestätigung der Registrierung) nicht bei den Kunden ankommen, da sie im Spamfilter des jeweiligen Providers oder des lokalen Mailprogramms hängen bleiben. Um zu überprüfen, ob es sich bei einer Mail um eine Spam-Mail handelt, berechnen Spamfilter aufgrund fest definierter Regeln einen Spam Score. Je höher deser Score ist, umso höher ist die Wahrscheinlichkeit, das die Mail im Spamfilter hängen bleibt. Um den Spam Score einer Mail zu überprüfen, gibt es zahlreiche Tools. Aktuell nutze ich dafür das kostenlose Tool mailingcheck.

Leider haben die Mails, die von Magento verschickt werden, von Hause aus einen relativ hohen Spam Score. Die Ursache des Problems ist die relativ schlampige Umsetzung der Mail-Versand Mechanik in Magento. So kann man z.B. entweder nur reine Textmails, oder nur HTML Mails verschicken. Wenn bei einer HTML Mail die reine Text Alternative fehlt, führt das auf jeden Fall zu einem höheren Spam Score. Außerdem haben einige Kunden eventuell den Empfang von HTML Mails komplett deaktiviert, so dass sie dann im schlimmsten Fall nur eine Mail ohne Inhalt bekommen. Weiter Probleme sind eine zu hohe Zeilenlänge, das Fehlen von HTML Tags am Anfang und Ende der Mail und unnötige TBODY Tags innerhalb der Mails.

Viele Shopbetreiber nutzen deshalb zum Versand der Newsletter und teilweise auch zum Versand der Transaktionsmails externe Mailsystem wie z.B. Cheetahmail oder Mailchimp. Grad wenn die Anzahl der Empfänger beim Newsletter eine gewisse Anzahl erreicht, sollte man zumindest beim Newsletterversand auf solche externe System umsteigen, damit während eines Massenversandes der Webserver, auf dem der Shop läuft, nicht zu sehr belastet wird und im schlimmsten Fall der Shop in der Zeit nicht mehr funktioniert. Da man als Shopbetreiber beim Ein- oder Umstieg auf Magento aber sicher erst mal genug mit dem eigentlichen Shopsystem zu tun hat, sollte man es vermeiden zu schnell zu viele externe System anzubinden.
Es gibt ein paar einfache, aber effektive Maßnahmen, um das Spam-Problem ein wenig zu entschärfen und den Spam Score zu verringern.

  1. Jede HTML Mail muss von Html Tags umschlossen sein. Also einfach bei allen Templates am anfang ein <html> und am Ende ein </html> einfügen, und schon sinkt der Spam Core der Mails
  2. Alle <tbody> Tags aus den Mails entfernen
  3. Aus dem Subject der Bestellbestätigungs-Mail die Bestellnummer entfernen
  4. Keine zu kleinen Schriftgrößen in CSS Styles nutzen z.B. 
    body,td { font:11px/1.35em }

    Die Angabe font: 1.35 em kommt fast in allen Standard Mail Templates von Magento vor und sollte entfernt werden. Die Größenangabe 11px reicht vollkommen aus.

  5. In der Datei /app/code/core/Zend/Mime.php die Zeilenlänge der Mails anpassen 
    const LINELENGTH = 75;

    Achtung: bei jedem Magento Update wird diese Datei überschrieben, deswegen muss man die Anpassung dann leider jedes Mal erneut machen !

Mit diesen einfachen Tipps, sollten die Magento Mails bei den meissten Kunden nicht mehr im Spam-Ordner landen.

Eine genau Anleitung, wie man Magento dazu bringt auch Multipart Mails zu verschicken, erscheint demnächst an dieser Stelle. Momentan überlege ich, eine Magento Extension zu programmieren, die dann jeder Shopbetreiber einfach bei sich installieren kann, um dann korrekte Multipart Mails verschicken zu können.

Veröffentlicht unter Magento | Verschlagwortet mit , , , , | Hinterlasse einen Kommentar

Magento Basics – Registry

Publiziert am 13. August 2010 von Tim

Um Daten innerhalb von Magento global zur Verfügung zu stellen, stellt Magento die Registry Klasse bereit, die als Singleton Pattern implementiert ist. So ist es z.B. möglich in einer Block Klassen auf Daten zuzugreifen, die z.B. im Controller verarbeitet wurden. Dazu müssen die Daten nur im Controller in der Registry gespeichert werden. Folgendes Beispiel zeigt eine einfache Anwendung der Registry Mechanik:

// Daten in Registry speichern
Mage::register('store_id', Mage::app()->getStore()->getId());
// Daten aus Registry auslesen
echo Mage::registry('store_id');
Veröffentlicht unter Magento | Verschlagwortet mit , , | Hinterlasse einen Kommentar

Magento Basics – Storeview, Stores und Website

Publiziert am 11. August 2010 von Tim

Für viele Magento Neulinge ist die Unterteilung in die drei unterschiedliche Ansichten Storeview, Store und Website mitunter recht verwirrend. Wenn man das Prinzip aber erst einmal durchschaut hat, macht diese Unterteilung durchaus Sinn und bietet dem Shopbetreiber viele Möglichkeiten, die andere Shopsystem nicht von Hause aus bieten.
Hier mal ein paar Beispiele, wofür die einzelnen Ansichten genutzt werden können:

  • Storeview
    • Ein Shop mit den gleichen Kategorien und Produkten in unterschiedlichen Sprachen. Jede Sprachversion wird durch eine eigene Storeview umgesetzt. Man kann sogar z.B. für den Jede Sprache ein eigenes Layout definieren
    • Gleiche Produktdaten, gleiche Kundendaten, gleicher Checkout, gleicher Warenkorb
  • Store
    • Mehrere Shops (Multistore) mit unterschiedlichen Kategorien und Produkten
    • Unterschiedliche Produktdaten, gleiche Kundendaten, gleicher Checkout, gleicher Warenkorb. Das heißt, der Kunde kann Produkte aus unterschiedlichen Shops in den Warenkorb legen und über einen gemeinsamen Checkout Prozeß bestellen. Außerdem muss er sich nur einmal zentral registrieren.
  • Website
    • Mehrere Shops (Multistore) mit unterschiedlichen Produkten, d.h. die Shops haben außer der gemeinsamen Datenbank im Hintergrund nichts miteinander zu tun. Der Vorteil für den Shopbetreiber ist dabei, dass er alles Shops trotzdem über ein Backend verwalten kann.
    • Unterschiedliche Produktdaten, unterschiedliche Kundendaten, unterschiedlicher Checkout, kein gemeinsamer Warenkorb

Ein ausführliche Beschreibung dieser Thematik mit anschaulichen Beispielen gibt es auf der Magento Homepage (in englisch).

Veröffentlicht unter Magento | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

Magento – Modul neu installieren

Publiziert am 11. August 2010 von Tim

Um bei einem vorhandenen Modul die Installationsroutine erneut ausführen zu lassen, muss in der Datenbank in der Tabelle core_resource der Eintrag für das Modul gelöscht werden. Wenn das Modul z.B. im Pfad meinnamespace/meinmodul hinterlegt ist, so muss der Eintrag mit dem code meinnamespace_meinmodul_setup in der Tabelle gelöscht werden. Entweder per Shell oder phpMyAdmin.

delete from core_resource WHERE code = 'meinnamespace_meinmodul_setup'
Veröffentlicht unter Magento | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

Magento – Admin Passwort zurücksetzen

Publiziert am 11. August 2010 von Tim

Falls man mal das Passwort des Magento Admin Users vergessen hat, kann man es wie folgt zurücksetzten, sofern man noch Zugriff auf die Datenbank per Shell oder phpMyAdmin hat:

UPDATE admin_user
SET password = md5('neuespasswort')
WHERE username = 'name_des_adminusers';
Veröffentlicht unter Magento | Verschlagwortet mit , | Hinterlasse einen Kommentar

Magento Basics – Konfigurationswerte auslesen

Publiziert am 9. August 2010 von Tim

Bei Magento werden die Konfigurationswerte an mehreren Stellen gespeichert. Zum einen werden bestimmte Konfigurationsparameter, die zum Teil über die Admin Oberfläche verwaltet werden können, in der Datenbank gespeichert. Zum anderen werden sie in den config.xml Dateien der einzelnen Module hinterlegt. In der Datenbank werden sie in der Tabelle ‚core_config_data‘ gespeichert. Der Name des Paramters steht in Spalte ‚path‘, der Wert in der Spalte ‚value‘. Um aus der Anwendung auf einen Konfigurationsparameter zuzugreifen, reicht folgende kleine Code-Zeile:

Mage::getStoreConfig('web/unsecure/base_url');

Dabei ist es egal, ob der Paramter in der Datenbank oder in einer XML Datei hinterlegt ist.

Veröffentlicht unter Magento | Verschlagwortet mit , , | Hinterlasse einen Kommentar

Favicon Generator

Publiziert am 5. August 2010 von Tim

Falls sich jemand schon immer gefragt hat, wie man sich sein eigenes Favicon erstellt, hier gibt es die Antwort. Einfach ein passendes Bild hochladen, Favicon erzeugen lassen, abspeichern und auf den eigenen Webspace hochladen. Und das alles für umsonst.

Veröffentlicht unter Allgemein | Verschlagwortet mit | Hinterlasse einen Kommentar