Aktuelles

htmlescapeDirective
Beschreibung: Konvertiert Sonderzeichen in einem String in die entsprechenden HTML-Entities
Beispiel: {{htmlescape var=”ich&du”}} oder {{htmlescape var=$customer.name}}

Synonym:

Mage::helper('core')->escapeHtml('ich&du');

Parameter:
var: die Ausgangszeichenfolge
allowed_tags: (optional) kommaseparierte Aufzählung mit erlaubten Tags

protocolDirective
Beschreibung: Steuert den Aufruf übergebener URLs via HTTP/HTTPS
Beispiel: {{protocol url=”www.muenster-webdesign.net”}}

Parameter:
store: optionale Angabe einer Store-Id oder eines Store-Codes
url: URL ohne Protokollangabe; Magento entscheidet dann anhand des gewählten Protokolls der aktuellen Seite, ob die eingebundene URL ein HTTP oder HTTPS-Prefix bekommt

ODER

http und https: Vollständige URL mit Protokollangabe; abhängig vom Protokoll der aktuellen Seite wird entweder die via “http”-Parameter oder die via “https”-Parameter spezifizierte URL ausgegeben

varDirective
Beschreibung: kann ausschließlich innerhalb von E-Mail-Templates eingesetzt werden, um Werte von Template-Variablen respektive Objekten und deren Methoden auszugeben.
Beispiel: {{var store.getFrontendName()}} oder {{var customer.name}}

Besonderheit: Neben Template-Variablen besteht die Möglichkeit, zusätzlich “Modifier” aufzurufen, um die Rückgabewerte der Template-Variablen zu modifizieren. Dazu stehen analog zu den Template-Variablen zuvor übergebene Modifier zur Verfügung wie beispielsweise “nl2br” oder “escape”. Ein entsprechener Aufruf sieht dann wie folgt aus:

{{var Variablenname|Modifier_1:Parameter_1:Parameter_2|Modifier_2….}}

Dabei gilt, dass das erste an den Modifier übergebene Argument automatisch der Wert der angegebenen Variablen respektive Rückgabewert der angesprochenen Methode ist. Der erste mit einem Modifier spezifizierten Parameter wird also tatsächlich an zweiter Position aufgerufen.

configDirective
Beschreibung: kann genutzt werden, um Werte aus der Store-Konfiguration auszulesen.
Beispiel: {{config path=”trans_email/ident_custom2/email”}}

Synonym:

Mage::app()->getStore()->getConfig('trans_email/ident_custom2/email');

customvarDirective
Beschreibung: Zugriff auf die im Admin-Bereich angelegten “Eigene Variablen”
Beispiel: {{customvar code=”test”}}; gibt den Wert der Variablen “test” aus der Datenbank zurück. Abhängig vom gewählten E-Mail-Template erfolgt die Rückgabe als “Plain Text” respektive “HTML”-formatiert.

Synonym:

Mage::getModel('core/variable')->setStoreId()->loadByCode('test');

includeDirective
Ermöglicht es, innerhalb von E-Mail-Templates weitere Templates einzubinden.
Beispiel: {{include template=mein_template}} (der Template-Code ist ohne Anführungszeichen anzugeben)

ifDirective
Ermöglicht es, innerhalb von E-Mail-Templates einfache If-Else-Konstrukte zu erstellen.
Beispiel: {{if meineVariable}}Der Wert der Variable ist ungleich ”{{else}}Die Variable repräsentiert einen leeren String oder ist nicht definiert{{/if}}

Der “else”-Teil ist optional. Geprüft wird lediglich, ob die in der If-Bedingung spezifizierte Varibale einen leeren String zurückgibt oder nicht. Zudem wird nur auf Wertgleichheit (==) geprüft, nicht auf Typgleichheit (===), sodass auch eine nicht gesetzte Variable den “else”-Teil der Bedingung auslösen würde.

Statt einer Variablen kann auch ein Methodenaufruf in der If-Bedingung angegeben werden.

dependDirective
Ermöglicht es, innerhalb von E-Mail-Templates die Ausgabe von Text an den Wert einer Template-Variablen respektive an den Rückgabewert einer Methode zu knüpfen.
Beispiel: {{depend meineVariable}}Der Wert der Variable ist ungleich ”{{/depend}}

Darüber hinaus gelten die weiteren Anmerkungen der ifDirective.

Magento: CMS-/E-Mail-Template-Syntax in Magento 1.6.2.0 (Teil 1)

Magentos CMS-Syntax basiert auf den Methoden der Klassen Mage_Core_Model_Email_Template_Filter, Mage_Widget_Model_Template_Filter und Varien_Filter_Template. Im Folgenden haben wir uns angesehen, welche Syntax-Konstrukte in der aktuellen Magento Version 1.6.2.0 zur Verfügung stehen:

blockDirective
Beschreibung: Anzeigen eines statischen oder per “type” definierten Blocks
Beispiel: {{block id=”footer_links“}} – Anzeigen eines statischen Blocks; als ID kann wahlweise der Block-Code oder die Block-ID übergeben werden
{{block type=”newsletter/subscribe” template=”newsletter/subscribe.phtml”}} – Anzeigen des unter “type” spezifizierten Blocks

Synonym:

Mage::app()->getLayout()->createBlock('cms/block')->setBlockId('footer_links')->toHtml();
Mage::app()->getLayout()->createBlock('newsletter/Subscribe')->setTemplate('newsletter/subscribe.phtml')->toHtml();

Parameter:
id: Block-Code oder Block-ID
type: Blockklasse
jeder weitere Parameter wie z.B. template=”…” oder name=”…” wird per Setter auf das Blockobjekt übertragen: setTemplate(), setName()

layoutDirective
Beschreibung: Fügt dem Layout-Objekt das angegebene Layout-Handle hinzu und führt die dort angegebenen Layout-Anweisungen aus
Beispiel: {{layout area=”frontend” handle=”my_layout_handle”}}

Synonym:

$html = Mage::app()->getLayout->getUpdate()->load('my_layout_handle')->generateXml()->generateBlocks();
echo $html->getOutput();

Parameter:
area: kann “frontend” oder “adminhtml” sein
handle: das entsprechende Layout-Handle
jeder weitere Parameter wird an jeden im Layout definierten Block weitergegeben

skinDirective
Beschreibung: Gibt den absoluten Pfad zum angegebenen Skin-Theme-Ordner zurück unter Berücksichtigung der Theme-Fallbacks. Beispielsweise, um Grafiken oder Skripte aus dem Skin-Theme-Ordner in CMS-Seiten einzubinden
Beispiel: {{skin url=”images/camera.gif”}}

Synonym:

Mage::getDesign()->getSkinUrl('images/camera.gif', $weitereParameter);

Parameter:
url = relativer Pfad zur Datei oder auch leer
_type, _default: keine weitere Bedeutung erkennbar
_area: mögliche sinnvolle Werte sind “frontend” oder “adminhtml”
_package: altenatives Design-Package
_theme: alternatives Theme

mediaDirective
Beschreibung: Gibt den absoluten Pfad zum media-Verzeichnis zurück
Beispiel: {{media url=”catalog/product/test.gif”}}

Synonym:

Mage::getBaseUrl('media) . 'catalog/product/test.gif';

Parameter:
url = relativer Pfad zur Datei oder auch leer

storeDirective
Beschreibung: Gibt Shop-URLs gemäß der angegebenen “Route/Controller”-Konfiguration zurück; ermöglicht auch die Erstellung benutzerdefinierter Shop-URLs
Beispiel: {{store url=”catalog/category/view” _query_id=5}}

Synonym:

Mage::app()->getStore(Mage::getDesign()->getStore())->getUrl('catalog/category/view', array('id' => 5));

Parameter:
url: URL (ohne Base-URL und per “?” angehängte Parameter); die angegebene URL wird durch Magentos Routing-System verarbeitet, sodass auch URLs mit Platzhaltern möglich sind, wie beispielsweise “*/*/*”. Diese Platzhalter werden dann wie gewohnt durch die jeweils aktuelle Route/Controller/Action-Kombination ersetzt. Es können auch Parameter in Magento-Manier mit übergeben werden wie z.B: “*/*/*/id/572″. Die erzeugten URLs enden stets mit einem Slash.
direct_url: die URL (ohne Base-URL) wird ohne Verarbeitung durch Magentos Routing-System ausgegeben. So ist es möglich, bestimmte Dateien im Magento-Verzeichnis direkt zu referenzieren oder auch Parameter direkt anzuhängen. Beispiel: “hallo_welt.html?a=b”.
_query_: (bei “url” & “direct_url” Parameter möglich) ermöglicht das Anhängen von Parametern an die URL. Beispiel: _query_a=”test” wird zu http://…?a=test
_fragment: (bei “url” & “direct_url” Parameter möglich) ermöglich die Angabe von Ankern z.B. _fragment=”kapitel2″ wird zu http://……..#kapitel2
_escape: (bei “url” & “direct_url” Parameter möglich) wirkt auf alle per “_query_” übergebenen Parameter; wenn “_escape” auf “true” gesetzt ist, werden die Parameter URL-codiert zurückgegeben. Aus “a=überschall” wird so “a=%26uuml%3Bberschall”.
_use_rewrite: (nur “url” Parameter möglich) falls auf “true” gesetzt, werden Route/Controller/Action-Kombinationen durch die entsprechenden Pfade aus der Rewrite-Tabelle ersetzt. Aus “/catalog/category/view/” wird so zum Beispiel “hosen/jeans.html”
_store_to_url: (nur bei “url” Parameter möglich) kann “true” oder “false” sein. Falls “true”, wird der URL ein Store-Query-Parameter angehangen wie z.B. http://…page.html?___store=default
_store: (nur bei “url” Parameter möglich) kann entweder einen Store-Code enthalten oder eine Store-ID. Setzt voraus, dass “_store_to_url” auf “true” gesetzt ist
_forced_secure: (nur bei “url” Parameter möglich) Wenn auf “true” gesetzt, wird stets eine https-URL zurückgegeben
_secure: (nur bei “url” Parameter möglich) Wenn auf “true” gesetzt, wird eine https-URL zurückgegeben, wenn in der XML-Konfiguration für die Seite, auf der der Link eingebunden ist, eine sichere Verbindung konfiguriert ist (siehe XML-Pfad: config/frontend/secure_url/)
_type: (nur bei “url” Parameter möglich) Art der URL. Möglich sind hier “link”, “direct_link”, “web”, “skin”, “js” und “media”. Falls nicht gesetzt, wird standardmäßig “link” angenommen. Für alle anderen URL-Typen werden die in der Systemkonfiguration für den jeweiligen Typ eingetragenen Verzeichnisse in die URL eingefügt.
_current: (nur bei “url” Parameter möglich) sofern auf “true” gesetzt, werden die Parameter der aktuellen Route der generierten URL angehangen, sofern diese nicht durch benutzerdefinierte Parameter überschrieben werden (siehe “_query_”).

Magento: CMS-/E-Mail-Template-Syntax in Magento 1.6.2.0 (Teil 2)

Gelegentlich sind die Bezeichnungen im Magento-Backend zu knapp um zu verstehen, was eine bestimmte Option im Detail bewirkt. So erging es uns mit der Option “Apply To Products”, die im Reiter “Eigene Gestaltung” in der Kategorieverwaltung zur Verfügung steht. Ein Blick in den Code hilft da weiter.

Ist die Option “Apply To Products” aktiviert, wirkt sich dies wie folgt auf die Produkteinzelansichten der dieser Kategorie zugeordneten Produkte aus:

• sofern für ein Produkt individuelle Theme- oder Page-Layout-Anweisungen hinterlegt sind, werden diese gegenüber den entsprechenden Kategorieeinstellungen priorisiert bzw. überschreiben diese.
• sofern für ein Produkt keine individuellen Layout-Anweisungen hinterlegt sind, werden die Anweisungen (Theme-, Page-  und Update-XML-Anweisungen) der Kategorie übernommen. Dies kann unter anderem dazu führen, dass eine vormals zweispaltige Produkteinzelansicht (Standardeinstellung) zu einem dreispaltigen Layout mutiert, wenn die Kategorie-Listenansicht entsprechend konfiguriert ist.
• Update-XML-Anweisungen für die Kategorie und das Produkt werden in jedem Fall zusammengeführt, wobei zunächst die Kategorie- und dann die Produkt-XML-Anweisungen abgearbeitet werden

Gelegentlich ergibt sich bei Magento das Problem, das gleichlautende Methoden in verschiedenen Kontexten verschiedene Parameter erwarten und letztlich auch Verschiedenes tun. Ein Beispiel ist die _init()-Methode wie sie in den (Entity-)Models, Resource- und Collection-Models zum Einsatz kommt.

_init() im Entity-Model-Kontext:
Im Entity-Model Kontext dient die _init()-Methode dazu, ein Entity-Model mit einem bestimmten Resource-Model zu “verknüpfen”. Der mittels der _init()-Methode übergebe String wir später über die config.xml des Moduls auf die entsprechende Klasse gemappt und per Mage::getResourceSingleton() instantiiert. Die _init()-Methode erwartet dementsprechend den in der config.xml definierten Model-Group-Name gefolgt vom Dateifpad zur zugehörigen Resource-Model-Datei. Beispielsweise also:

protected function _construct()
{
   $this->_init('sales/order');
}

Hier würde Magento in der config.xml nach dem Model-Group-Name “sales” suchen, dann das zugehörige Resource-Model-Classname-Prefix auslesen und schließlich die angegebene Pfadangabe auf das Dateisystem umsetzen.

_init() im Resource-Model-Kontext:
Im Resource-Model-Kontext wird der _init()-Methode hingegen eine Entität gefolgt von der Angabe der Tabellenspalte übergeben, die die Entitäts-ID beinhaltet. Die zu einem Modul zugehörigen Entitäten sind wiederum in der config.xml im Pfad global/models/resource_model_group_name/entities/name_der_entität festgelegt. Ein entsprechender Aufruf lautet also:

protected function _construct()
{
   $this->_init('sales/order', 'entity_id');
}

_init() im Collection-Model-Kontext:
Im Collection-Model-Kontext wird der _init()-Methode das zugehörige Entity-Model bekannt gemacht. Später wird dann für jedes ausgelesene Tupel ein Model-Objekt der entsprechenden Klasse instantiiert und die Werte per setData() auf das Objekt übertragen. Ein Aufruf entpsrechend unseres Beispiels sieht wie folgt aus:

protected function _construct()
{
   $this->_init('sales/order');
}

Magento-Entwickler, die ihre Extensions per TDD (Test-Driven-Development) entwickeln und dazu die Magento-PHPUnit-Extension von EcomDev nutzen, haben vielleicht schon Probleme mit dem Laden von Fixtures über die entsprechende “@loadFixture”-Annotation gehabt.

Sofern in der Testklasse eine eigene Setup-Methode definiert ist, gelingt das Laden der Fixtures nur, wenn am Ende die Eltern-Methode aufgerufen wird. In ihr werden die nötigen Fixtures überhaupt erst geladen. Eine mögliche Setup-Methode sieht daher wie folgt aus:

public function setUp()
{
 // eigener Setup-Code ...
 parent::setUp();
}

Die CSS-Klasse im Body-Tag verrät die aktuelle Modul-Controller-Action-Kombination. Hier: cms/index/index

Bedingt durch Magentos URL-Rewriting im Frontend ist es meist nicht auf den ersten Blick ersichtlich, welche Modul-Controller-Action-Kombination für die aktuelle Ausgabe verantwortlich ist.

Tipp: Ein Blick in die CSS-Klasse des Body-Tags im HTML-Quellcode verrät meist die aktuelle Modul-Controller-Action-Kombination.