Ich sitze im Zug nach Leipzig, auf dem Weg zur Meet Magento. Ich sitze und mein Fahrrad hängt. Am Vorderrad. Wenn es twittern könnte, würde es jetzt twittern, da bin ich mir sicher. Es kann dem Zugführer beim Zugführen zusehen, darf aber nicht näher an den Zugführerverfügungsraum herantreten, ebenso wenig wie Koffer. Es sah sehr etwas hilflos aus, als ich das Fahrradabteil latent hektisch verließ um vom ersten Abteil des Zuges im Halblaufschritt zum letzten Abteil zu rappeln, wo ich dann die nächsten sechs Stunden verbringen werde.

Nun habe ich also Zeit, um vom dritten Kölner Stammtisch zu berichten.

Der Kölner Stammtisch zeichnet sich ja noch ein wenig dadurch aus, dass sich noch kein Stamm gefunden hat. Aus diesem Grunde gibt’s hier auch noch keine Vorträge. Stammtisch eins war wild gemixt, Stammtisch zwei bestach durch Abwesenheit der Angemeldeten und einer hohen Präsenz von Aachenern, daher war ich doch mal sehr gespannt auf Stammtisch drei!

Er fand in einer anderen Location statt, weil ich hoffte, dass es Mitte Mai schon so warm sein würde, dass wir in dem wunderbaren Biergarten sitzen könnten. 10 Grad haben das verhindert. Im Innenraum war es verhältnismäßig laut, so dass man entweder ausschließlich Megaphone oder das Ohr des unmittelbaren Sitznachbarn nutzen konnte. Wohl einer der Gründe, warum bei der Platzreservierung das Magento M verloren ging.

Diesmal habe ich also für 6 Personen bestellt, weil 6 angemeldet waren und prompt saßen wir irgendwann zu neunt am Tisch. Neun Agentos also. Zwei davon kannte ich, die anderen waren neu. Und diesmal war kein einziger Aachener dabei! Einer hat den weiten Weg aus Dortmund auf sich genommen – vielleicht der Dortmunder Stammtischorganisator in spe? Ansonsten war diesmal tatsächlich Köln oder das Kölner Umfeld vertreten (darf man Bonn als Kölner Umfeld bezeichnen? Bei Düsseldorf darf man das ja, aber Bonn?)

Schön fand ich den Mix an Magento-Zuständen. Zwei waren ganz neu dabei, zwei schon seit 2008 infiziert und zwei haben schon wieder aufgehört mit Magento zu arbeiten.

In meinem Abteil befindet sich ein kleiner Junge, der es sehr bedauert, noch kein Handwerker zu sein, damit er im Zug Fenster einbauen kann. Vielleicht ein guter Zeitpunkt, ihn als zukünftigen Agento zu akkreditieren.

Bleibt mir nur das Schlusswort und der Ausblick:

Los Agentos, espero que la próxima reunión en Colonia. Estoy buscando un lugar tranquilo con un montón de espacio. Ahora tengo que cuidar a mis Fahrrodos. Saludos Queridos Agentos Colonia. Su Miss Magenta.

In Magento 1.6 war diese Klasse zuständig für die Navigationsaufbereitung:
Mage_Catalog_Block_Navigation
und der funktionierende Rewrite war dieser:

<global>
   <blocks>
       <catalog>
        <rewrite>
            <navigation>MeinNameSpace_MeinModul_Block_Navigation</navigation>
        </rewrite>
    </catalog>
    </blocks>
</global>

In der neuen Magento Version hat man sich also von dieser Klasse verabschiedet. Die Navigation ist nun in einem völlig neuen Block untergebracht: dem “Topmenu” innerhalb des Page-Moduls.

In der page.xml wird man also auch fündig:

<block type="page/html_header" name="header" as="header">
    <block type="page/template_links" name="top.links" as="topLinks"/>
    <block type="page/switch" name="store_language" as="store_language"
         template="page/switch/languages.phtml"/>
    <block type="core/text_list" name="top.menu" as="topMenu" translate="label">
        <label>Navigation Bar</label>
        <block type="page/html_topmenu" name="catalog.topnav"
             template="page/html/topmenu.phtml"/>
    </block>
    <block type="page/html_wrapper" name="top.container" as="topContainer" translate="label">
        <label>Page Header</label>
        <action method="setElementClass"><value>top-container</value></action>
    </block>
</block>

Die neue Zuständigkeit für das Rendern der Navigation hat also die Klasse
Mage_Page_Block_Html_Topmenu
übernommen.

Und in dieser Klasse scheint es neue Events zu geben:
page_block_html_topmenu_gethtml_before
und
page_block_html_topmenu_gethtml_after
(welche bei Google noch 0 Treffer liefern, was ich hiermit ändern möchte!)

Der _after Event-Observer liefert das fertige Menu und den fertigen HTML-Code der Navigation.

Wie man mit dem _before Event das Menu beeinflusst, möchte ich kurz zeigen.

Erstmal Magento mitteilen, dass man diesen Event gerne nutzen möchte:

<frontend>
     <events>
            <page_block_html_topmenu_gethtml_before>
                <observers>
                    <meinnamespace_page_block_html_topmenu_gethtml_before>
                        <type>singleton</type>
                        <class>meinnamespace_meinmodulname/observer</class>
                        <method>topmenuGethtmlBefore</method>
                    </meinnamespace_page_block_html_topmenu_gethtml_before>
                </observers>
            </page_block_html_topmenu_gethtml_before>
        </events>
</frontend>

Dann die Observer-Klasse mit der observierenden Funktion anlegen:

class MeinNameSpace_MeinModul_Model_Observer {
   public function topmenuGethtmlBefore (Varien_Event_Observer $observer) {
        /** @var $event Varien_Event */
        $event = $observer->getEvent();

        ....
   }
}

Was im Event-Objekt nun zur Verfügung steht, kann man in der Mage_Page_Block_Html_Topmenu Klasse erfahren:

public function getHtml($outermostClass = '', $childrenWrapClass = '')
{
    Mage::dispatchEvent('page_block_html_topmenu_gethtml_before', array(
        'menu' => $this->_menu
    ));

    $this->_menu->setOutermostClass($outermostClass);
    $this->_menu->setChildrenWrapClass($childrenWrapClass);

    $html = $this->_getHtml($this->_menu, $childrenWrapClass);

    Mage::dispatchEvent('page_block_html_topmenu_gethtml_after', array(
        'menu' => $this->_menu,
        'html' => $html
    ));

    return $html;
}

Nutzt man also den page_block_html_topmenu_gethtml_before Event, so steht einem mittels

/** @var $menu Varien_Data_Tree_Node */
$menu = $event->getMenu();

das Objekt zur Verfügung, das die Navigationselemente enthält.

(bei page_block_html_topmenu_gethtml_after stünde einem noch der generierte HMTL-String des Menüs zur Verfügung mittels: $html = $event->getHtml(); )

Nun kann man das Menü manipulieren.

Man kann beispielsweise den Namen eines Menüpunkts ändern:

public function topmenuGethtmlBefore (Varien_Event_Observer $observer) {
        /** @var $event Varien_Event */
        $event = $observer->getEvent();

        /** @var $menu Varien_Data_Tree_Node */
        $menu = $event->getMenu();

        /** @var $menuCollection Varien_Data_Tree_Node_Collection */
        $menuCollection = $menu->getChildren();

        /** @var $item Varien_Data_Tree_Node */
        foreach ($menuCollection as $item) {
            if ($item->getName() == 'Alter Name') {
                $item->setName('Neuer Name');
            }
        }
    }
}

Oder man kann Menüpunkte entfernen, beispielsweise alle Unterkategorien einer Kategorie:

public function topmenuGethtmlBefore (Varien_Event_Observer $observer) {
        /** @var $event Varien_Event */
        $event = $observer->getEvent();

        /** @var $menu Varien_Data_Tree_Node */
        $menu = $event->getMenu();

        /** @var $menuCollection Varien_Data_Tree_Node_Collection */
        $menuCollection = $menu->getChildren();

        /** @var $item Varien_Data_Tree_Node */
        foreach ($menuCollection as $item) {
            if ($item->getName() == 'Alter Name') {

                $item->setName('Neuer Name');

                /** @var $childNode Varien_Data_Tree_Node */
                foreach ($item->getAllChildNodes() as $childNode) {
                    $item->removeChild($childNode);
                }
            }
        }
    }
}

Man kann natürlich hier auch Menüpunkte hinzufügen. Und verschieben. Und was sonst noch, muss ich noch herausfinden. Aber dafür ist Magento ja da.

Es gibt keine Möglichkeit eine abstrakte Klasse (hier nennen wir sie Foo) in Magento zu überschreiben. Wenn andere Klassen (nennen wir sie Bar und Pub) von Foo abgeleitet sind, und man möchte nun eigentlich Foo erweitern, damit sowohl Bar, als auch Pub über neue oder geänderte Methoden verfügen, so geht das nur, indem man Bar und Pub überschreibt.

In diesem Beitrag soll es aber nicht um eine abstrakte Klasse gehen, sondern um ein anderes Phänomen am Beispiel der Klasse:
Mage_Payment_Block_Form_Container

Diese Klasse ist nicht abstrakt, sondern eigentlich eine nette, normale Blockklasse, der man zum Beispiel begegnet, wenn man die Payment-Methods im Checkout bearbeiten möchte.

Diese Klasse kann man nicht überschreiben. Das glaubt man nun zunächst nicht… und starrt hinlänglich auf xml, das einfach nur korrekt aussieht.

<blocks>
 <paymentmethods>
  <class>NameSpace_ModulName_Block</class>
   </paymentmethods >
    <payment>
     <rewrite>
      <form_container>
      NameSpace_ModulName_Block_Form_Container
      </form_container>
     </rewrite>
  </payment>
 </blocks>

Mir ging es im Speziellen um das Überschreiben der Methode getMethods(), weil ich bestimmte Payment-Methoden aufgrund bestimmter Produkte im Warenkorb ausschließen wollte.

public function getMethods()
    {
        $methods = $this->getData('methods');
        if (is_null($methods)) {
            $quote = $this->getQuote();
            $store = $quote ? $quote->getStoreId() : null;
            $methods = $this->helper('payment')->getStoreMethods($store, $quote);
            $total = $quote->getBaseSubtotal();
            foreach ($methods as $key => $method) {
                if ($this->_canUseMethod($method)
                    && ($total != 0
                        || $method->getCode() == 'free'
                        || ($quote->hasRecurringItems() && $method->canManageRecurringProfiles()))) {
                    $this->_assignMethod($method);
                } else {
                    unset($methods[$key]);
                }
            }
            $this->setData('methods', $methods);
        }
        return $methods;
    }

Der Grund:

Der Block Mage_Payment_Block_Form_Container wird bereits von der Klasse Mage_Checkout_Block_Onepage_Payment_Methods beerbt.

class Mage_Checkout_Block_Onepage_Payment_Methods
        extends Mage_Payment_Block_Form_Container

Magento berücksichtigt beim Aufbau des Checkouts daher nicht direkt den Block Mage_Payment_Block_Form_Container auf, sondern Mage_Checkout_Block_Onepage_Payment_Methods, daher nützt das Überschreiben des From_Containers auch nichts.

Die Lösung daher:
Überschreiben des Blocks Mage_Checkout_Block_Onepage_Payment_Methods und dort die Methode getMethods() einfügen und nach seinen individuellen Bedürnissen anpassen.

Und der Vollständigkeit halber: der Aufruf der Methode erfolgt im Template-Block:

/app/design/frontend/default/meintheme/template/checkout/onepage/payment/methods.phtml
 ($methods = $this->getMethods();)

Gibt es das Wort “Rekursionen” – im Laufe dieses Beitrags werde ich es nachschlagen und Ihr müsst bis zum Ende lesen, bevor ich das Nachschlageergebnis zum besten geben werde.

Solange rede ich halt vom Kategorieimport.

Der Kategorieimport ist denkbar simpel – auf den ersten Blick.

Im ersten Adventskalendertürchen im Magento-Webguys-Adventskalender-2010 (Türchen 01: Eine Kateogrie anlegen) steht’s geschrieben:

$category = Mage::getModel('catalog/category');
$category->setPath( '1/2' );
$category->setName( $name );
$category->save();

Um einen Vergleich zu haben, wie es aus Datenbanksicht richtig aussieht, habe ich zunächst eine Kategorie über das Magento-Backend eingepflegt. Und eine Unterkategorie gab’s auch noch. Das sieht dann so aus:

Meine Kategorien heißen ‘Top-Categoy-Backend’ und ‘Sub-Category-Backend’.

Wenn man nun die Motorhaube einmal aufmacht, dann findet man diese Kategorien in der Tabelle ‘catalog_category_entity’ wieder:

entity_id -> ist die Entity ID der Kategorie, also quasi der Primärschlüssel.

entity_type_id -> 3 ist der Typ “Kategorie”

attribute_set_id -> ist das Attributset für Kategorien (Kategorien haben ja auch Attribute, nicht nur Produkte). Dies fehlt im obigen Beispiel. Diese ID sollte man also auf jeden Fall noch setzen.

parent_id -> ist die entity_id der Kategorie, unter der die Kategorie eingruppiert wird.

created_at und updated_at erklär ich mal nicht.

path -> Im Feld Path werden die entity_id’s beginnend mit der obersten (der Root Catalog) gesetzt, bis man bei der entity_id angelangt ist, die zur Kategorie selbst gehört.
path = 1 ist also die ID der Root-Catalog – der Container für alle Kategorie-Container, sozusagen. Den wird man nie im Frontend namentlich zu sehen bekommen…. Dann folgt in diesem Fall die ‘Default Category’, das ist der Kategorie-Container für den jeweiligen Store, der in den Manage-Store-Einstellungen zugewiesen wird. Und dann folgen schließlich die entity_id’s der im Shop sichtbaren Kategorien: 3 für die Top-Category-Backend und 4 für die Sub-Category-Backend.

Demnach hätte eine weitere Top-Category-Backend-2 mit der Entity ID 5 den Pfad: 1/2/5.
Und eine weitere Sub-Category-Backend-2 mit der Entity ID 6 den Pfad 1/2/3/6, wenn sie denn zur Top-Category-Backend gehört. Wenn sie zur Top-Category-Backend-2 gehören würde wäre es ein 1/2/5/6-Pfad.

Hausaufgaben: Pfade bauen.

Die Position erklärt sich dann schon fast wieder von selbst. Das ist die Position, die die Kategorie in ihrer jeweiligen Parent-Kategorie inne hat.

Der Level besagt, wie weit sich diese Kategorie im Baumgeäst befindet. Erste Ebene. zweite Ebene. Die ‘Default Category’ nimmt Level 1 ein. Die erste im Shop sichtbare Kategorie hat demnach Level 2.

Testfrage: Wechen Level hat die Kategorie mit dem Pfad 1/2/5/6?

Children Count gibt die Summe der Kategorien an, die sich innerhalb dieser Kategorie befinden. Die Summe aller Kategorien kann man daher in der Kategorie ‘Root Catalog’ ablesen, wenn es 200 Kategorien gibt, hat diese 200 Children. In meinem Beispiel hat die ‘Default Category’ 2 Kinder, wenn ich die beiden weiteren Kategorien gespeichert hätte, wären es vier… usw. usf.

Warum ich das alles erkläre?

Weil man sehr sehr leicht und sehr sehr schnell die Pfade vergißt… und dann würde ein

$category = Mage::getModel('catalog/category');
$category->setName( $name );
$category->save();

zu einem solchen Ergebnis führen:

Dann wäre die Kateogrie nicht zu sehen.

Unliebsam wird es dann, wenn der Kategoriebaum größer wird und man bei den Importinformationen nur den Namen der nächsten Parent-Kategorie hat, nicht aber alle IDs der übergeordneten Kategorien – sprich: was tun, wenn man nicht sicher weiß, dass man immer nur “1/2″ schreiben muss, um das Menü zu füllen.

Da gibt es dann zwei Möglichkeiten:
Laden der Parent-Kategorie und deren Pfad (z.B. 1/2/7) verwenden, um diesen als Path beim neuen Model zu setzen.

Oder:
Neue Category speichern – ohne Pfad. Und dann mittels der Methode ‘move()’ die Kategorie in die vorgesehene verschieben. Dann werden alle Pfade von Magento gesetzt:
$category = Mage::getModel(‘catalog/category’)->load($catId);
$category->move($parentCategoryId, 1);
Das geht allerdings nur, wenn die Kategorie einmal mittels ->save() gepseichert wurde, dann kann man die ID laden und für move() verwenden.

Ach – und nun hätt ich’s fast vergessen. Das Wort, worauf am End, ich kommen wollte.

Als Rekursion (lat. recurrere „zurücklaufen“) bezeichnet man die Technik in Mathematik, Logik und Informatik, eine Funktion durch sich selbst zu definieren (rekursive Definition). Wenn man mehrere Funktionen durch wechselseitige Verwendung voneinander definiert, spricht man von wechselseitiger Rekursion.

Ist das nicht hübsch? Eine Funktion durch sich selbst zu definieren.

Möglichkeit a) es gibt keine Magento-Programmierer in Köln oder sie dachten, man müsse einen Bart tragen, um am Stammtisch teilnehmen zu können. Ich hätte dazu schreiben sollen, dass es am Eingang eine Bartkiste gibt.

Möglichkeit b) man sollte einen Tag vor dem Stammtischtischeln eine Erinnerungs-E-Mail an alle schreiben, womöglich einfach mit einem Ortswechsel, wie es in Aachen der Fall war. Das mache ich beim nächsten Mal. (Notizenkritzelgeräusch).

Möglichkeit c) ich habe mich im Datum vertan und die drei anderen Bärte auch.

Dennoch war es sehr sehr nett in dieser bärtigen Runde (mit Vieren kriegt man schon ein Rund hin). Das Thema “Magento” war auch gar nicht das dominanteste des Tages. Schul- und Ortsfragen gab es auch. Denn neben den Bärten gab es eine weitere Gemeinsamkeit: alle außer mir kamen aus Aachen.

Und dann gab es ein paar Neidthemen. Andreas und ich haben ausgiebig alle beneidet, die im Oktober bei der X.commerce Innovate Conference in San Francisco dabei waren. Ich habe dann noch Andreas ausgiebig beneidet, weil er tags drauf zum Foocamp fahren wird. Und dann haben wir überlegt, wo man denn noch so hinfahren könnte. Einer am Tisch wusste noch nichts von Leipzig und der MeetMagento.

Wie frei ist man, wenn man frei arbeitet war vor allem im Hinblick auf die räumlichen und zeitlichen Freiheiten Thema. Ich bin ja sehr froh, dass mein Büro ‘inner Stadt’ liegt und ich mich aus dem Haus begeben muss, um besohlt oder bereift die Strecke zurückzulegen. (Zumal es da neuerdings in Büronähe diesen Sushi-Laden gibt…) Die @Home-Freien sind froh, schnell beim Kinde sein zu können und wegen der verlustfreien Zeit schnell zwischen Job und Privat switchen zu können. Mal mehr oder weniger von Haushaltsgeräten abgelenkt.

Meine Notizen für den nächsten Stammtisch:
* unbedingt kurz vorher einen Ortswechsel ankündigen
* dazu schreiben, dass es am Eingang Bärte gibt
* einen modularen Tisch bestellen
* vorher Damian fragen, wann er in Köln ist
* unbedingt sagen, dass, wenn man in Köln ein
“großes” Kölsch bestellt, ein 0,3 Bier kommt

Ja. Und um zu wissen, am besten sofort, am besten in genau diesem Moment, wer nach was gesucht hat und augrund dieser Suche auf meiner Homepage, Website, Page, Internetseite, ja hier halt… gelandet ist, ja, dafür braucht man Tooooools. Die gibt es. Und so weiß ich, warum jemand mich kennengelernt hat.

Da gibt es die Suchbegriffe, die hierher gehören, die hier landen dürfen/sollen/wollen/können/müssen/uswusf. “Magento Freelancer”, “Magenot Programmierer” , “Magento Experte”, “Magento Hilfe” (alles männliche Formen übrigens, ist es Ihnen aufgefallen?)…. Und je nachdem, was ich an Geschreibsel bereits von mir gegeben habe, kommt hinzu “E-Mailvorlage Magento” oder “Magento Singelton” oder “Magento Cache leeren” oder “Magento Template”, oder oder oder. Alles richtig, hier gehören Sie hin.

Was ich aber eigentlich toll finde und zwar ungefähr sooooo toll, wie viele oooo’s in’s Wort Tooooool (gesprochen “Tuuuuuhl”) zu schreiben ist, nein sind – die Suchbegriffe, die ja so rein gar nix mit dem zu tun haben, was ich mache, die aber so herrlich eine Tür öffnen in die Welt der Wünsche, Nöte und Bedürfnisse der Suchenden. Und so habe ich mir vorgenommen sie zu sammen, die Suchen, die Suchenden, die Google hierhin geschickt hat.

Und eben, grade eben hat Google jemanden hierhin geschickt, der gesucht hat nach:

aufräumer köln

Toll, oder?

break;

Der erste Kölner Magento Stammtisch fand…. in der Sonne statt. Dies erstmal vorweg. Das war großartig, denn somit konnten wir im Biergarten des Cinenova Platz finden. Und mein mutig für 10 bestellter Tisch war dann irgendwann mit 11en befüllt. Am weitesten angereist war im Grunde genommen Andreas, weil er frisch aus der Schweiz kam, der am weitesten weg Wohnende war wohl aber Damian, der den in Köln ansässigen Tontechniker des Magento-Podcasts mitgebracht hat. Somit ist der Podcast ja quasi multibundeslandar (nur quasi, ich weiß, aber multistadtistisch klingt nicht so gut). Ansonsten waren viele bekannte Aachener da und zwei neue Gesichter von einer Agentur aus Köln, die einfach mal zu einem Xing-Event wollten (wer will das nicht mal) und einfach mal was über Magento erfahren wollten (wer will das nicht mal). Das haben sie ganz bestimmt und viele Wörter und Akronyme, die halt fallen, wenn Entwickler sich unterhalten, mitgenommen.

Puh, was waren die Themen…. Von Unterschieden zwischen den Shopsystemen (ePages, XT:Commerce, Oxid und Magento), über das Foocamp, allgemeine und spezielle Entwicklerthemen, Kunden und Unkunden, von frischgeborenen Kindern (nochmals meine herzlichsten Glückwünsche an Ralf, wie war die Nacht?), Magento-Events und wie “awesome” und lohnenswert welches Event denn wohl ist, von den Anfängen von Magento bis zur Gegenwart, über die Entstehung und die Themen des Magento-Podcasts, konsonantenlastige Nachnamen… wirklich ein breites Themenspektrum. Dabei haben wir glaube ich gar nicht über ebay gesprochen (außer der Frage von links: “Welches Shopsystem benutzt eigentlich ebay?”).

Die traditionelle Erst-Stammtisch-Buch-Verlosung aus dem Hause Galileo Computing brachte drei Buchgewinner und meine Magento-Dollars-Trostpreise warfen die Gültigkeitsdauerfrage auf und irgendwie bin ich sie nicht los geworden…

Da jede Planung ihre Fehler braucht, darf nicht unterwähnt bleiben, dass wir den Biergarten um viertel vor zehn verlassen mussten, weil dort Open Air ein Film gezeigt wurde. Ein kleiner Restkreis nahm nochmal in den Innenräumen Platz, und dann war er doch irgendwann vorbei. Der erste Kölner Magento-Stammtisch.

Es geht hier also um die Transaktions-E-Mail-Vorlagen. Also der E-Mails, die bei bestimmten Aktionen innerhalb des Shops versendet werden. Die Hallo-Willkommen-E-Mail, die an neue Kunden geht, das vergessene Passwort, die Bestellbestätigung undsoweiterundsofort. Da kommt so einiges zusammen – und wenn man diese gerne mit eigenen Texten und gar noch einer eigenen Gestaltung versehen will, geht einige Zeit ins Land, bis man sie stolz sein eigen Werk nennen darf.

Zu finden ist dieser ganze E-Mail-Haufen (“E-Mail” ist übrigens richtig geschrieben, nicht eMail oder email oder EMail.) im Backend/Administrationsbereich unter:
System->Transaktions-E-Mails

Wer MarketReadyGermany installiert hat, findet dort tatsächlich einen Haufen, alle anderen finden dort – ich glaube maximal – drei.

Eine neue E-Mail wird erstellt, indem man auf “(+) Neue Vorlage” klickt, in dem sich daraufhin präsentierenden Formular die Vorlage auswählt, auf der die neue E-Mail basieren soll und diese lädt, also in das Textfeld “Vorlagen-Inhalt” kopieren lässt, indem man auf tattaaaa “Vorlage laden” klickt. Hernach kann man seiner Vorlage einen neuen Namen geben (der nur intern gesehen wird), den Betreff wählen (den natürlich auch die Kunden sehen) und den Inhalt gestalten und füllen….
Im Feld “Vorlagen-Stile” können CSS Angaben gemacht werden.

Damit die Absendeadressen nicht allzu merkwürdig aussehen, muss man vorab die E-Mailadressen, mit denen Magento die E-Mails versendet, angeben. Dies kann man netterweise natürlich für alle Storeviews seperat machen unter:
System->Konfiguration->Allgemein->Store-E-Mail-Adressen

Und dann? Dann beginnt die Nadelheuhaufen suche, wo man denn welche Vorlage jetzt zuweist… Denn Magento muss jetzt natürlich noch wissen, welche E-Mail-Vorlage verwendet werden soll…

Zur Erleichterung hier ein paar Pfeile, die ich auf den Heuhaufen klebe:

Der Heuhaufen findet sich zunächst unter: System->Konfiguration. Und hier die Pfeile:

Das Kontaktformular:
Allgemein->Kontakte->E-Mail Optionen

Produktbenachrichtigungen:
Katalog->Katalog->Produktbenachrichtigungen
Katalog->Katalog->Ausführungseinstellungen für Produktbenachrichtigungen

Wenn Fehler bei der Sitemap-Erstellung auftreten:
Katalog->Google Sitemap->Einstellungen für die Erstellung

E-Mail an einen Freund:
Katalog->E-Mail an einen Freund->E-Mail Vorlagen

Gleich drei Vorlagen gibt’s zur Newsletteranmeldung:
Kunden->Newsletter->Abonnementoptionen

Die E-Mails für die Kundenkonto-Anlegen-Vorlagen finden sich unter:
Kunden->Kundenkonfiguration->Benutzerkonto anlegen Optionen

Gleich darunter, die Vorlage für das vergessene Passwort:
Kunden->Kundenkonfiguration->Passwortoptionen

Die Wunschzettel-Verteiler-Vorlage findet sich unter:
Kunden->Wunschzettel->Verteilungsoptionen

Unter Verkäufe->Verkaufs-E-Mails kann man folgende Vorlagen zuweisen:
Bestellbestätigung (auch für Gäste)
Bestellkommentare (auch für Gäste)
Rechnung (auch für Gastrechnungen)
Rechnungskommentare (auch für Gäste, Kommentare meint sowas wie “kurze Nachricht”)
Versand (ich lass das auch-für-Gäste jetzt mal weg)
Versandkommentar (auch für – ach ja)
Gutschrift (…)
Gutschriftkommentare

Wenn die Zahlung nicht geklappt hat, gibt’s auch eine E-Mail:
Verkäufe->Zur Kasse->E-Mails bei fehlgeschlagener Zahlung

Unter ->Erweitert, also da, wo man eigentlich gar nicht mehr so viele E-Mails erwartet, findet man noch zwei:
Für das vergessene Admin-Passwort:
Admin->Admin Bentuzer-E-Mails
Und für das Protokoll, wenn was schief läuft:
System-Protokoll bereinigen

Jetzt sind alle Bindestriche alle und ich bin mir immer noch nicht sicher, ob ich sämtliche Vorlagenzuweisungen gefunden habe… Wer also noch welche findet…. Kontaktdaten stehen rechts….

Die Warums werden gewälzt. Finanzielle Erwägungen, nu-abba-ma-Feierabend-Erwägungen? Der rechtzeitige Rückzug, ein Ruhephasenwunsch oder nette Verträge von denen wir alle lieber nichts wissen wollen?

Zu den Warums gesellen sich die Was-Nu. Wird nun Magento ein 100%iges kostenpflichtiges Lizenzprodukt? Das hängt wohl in erster Linie davon ab, welche Verkaufsstrategien eBay verfolgt. Sind Gewinne über Lizenzen das Ziel oder strebt man an, sich als Zahlungsanbieter durchzusetzen und an den Bezahlvorgängen zu verdienen? Im letzteren Fall hätten sie wohl wenig Interesse daran, den Quellcode mit Schloss zu versehen, auf dem ein Preis steht. Dann würde man das Kleinvieh vergraulen. Aber Marketing ist ja nicht immer durchdacht und logisch.

Magento soll Bestandteil von X.Commerce werden, darf aber seinen Namen (und seine Eigenständigkeit, Anm. von @avstudnitz ;-]) behalten und somit sind die kleinen Pictos in den Entwickler-Twitter-Bildern erstmal nicht zu ersetzen.

Und der nächste Namens-X-Versuch, der in Deutschland nicht in die Deutschsprechköpfe will scheint nun auch geboren. Bei “Crossing” hat man nun auch verstanden, dass alle Deutschen “Xing” sagen und das mit dem Cross nicht internalisiert haben. So sieht X.Commerce XT:Commere nicht nur wahnsinnig ähnlich, so hört es sich auch noch wahnsinnig ähnlich an. Sucht (sorry: googelt) man nach X.Commerce finden sich noch allerlei XT-Treffer unter den Ergebnissen. Soviel zum Thema durchdachtes Marketing.

Ich reihe mich in die Rätselrater ein und schau mich ein wenig um, während ich weiterhin mit Magento Händchen halte.

Der Festplattenplatz

downloader/perlib/download

Hier liegen alle einmal heruntergeladenen Archive von Extensions. Wenn Erweiterungen fehlerhaft sind, wird bei “reinstall” auf dieses Archiv zurückgegriffen. Kann man – sollte man aber nicht unbedingt löschen, es sei denn man hat die Extension bereits deinstalliert, dann kann man sie hier auch löschen.

var/log

Hier liegen die Fehler- und Meldungs-Logdateien, die man (als Datenmessi) auch mal sichern und dann löschen kann. Die liegen allerdings nur hier, wenn das Fehler-Logging im Admin eingeschaltet ist.

var/backup

Hier liegen die gezippten Datenbank-Backups, die man auch mal (als Datenmessi) lokal speichern und dann löschen kann. Am besten über das Backend unter System->Werkzeuge->Sicherungen

var/session

Im Ordner Session liegen – tataaaa, die Sessionfiles, wenn Sessions auf File-Ebene und nicht auf Datenbankebene eingestellt wurde, dieser Ordner kann auch mal geleert werden – außer aktuelle Sessions… und ein Backup ist hier auch nicht nötig.

media

Hier liegen alle Produktbilder – und Magento hat eine (mir noch nicht schlüssige) Besonderheit: Bilder werden NIE gelöscht. Tauscht man ein Produktbild durch ein anderes aus, wird das erste Bild beibehalten. Diese Ordner wachsen oft riesenhaft an, erstrecht wenn der Shopbetreiber dazu neigt, leinwandgroße Bilddateien hochzuladen oder auch bei automatischen Imports, die vielleicht auch öfter mal durchlaufen…. Diese ungenutzten Bilder kann man nicht mit Magento-Boardmitteln finden, sondern man muss hierfür ein Script schreiben, in welchem abgeglichen wird, ob zu jeder Grafikdatei im Ordner media ein Eintrag in der Datenbank existiert.

Die Datenbank

Tabellen, die mit log_ anfangen (log_url, log_url_info, log_visitor, log_visitor_info, NICHT die log_summary_type) können geleert (nicht gelöscht!) werden.
Im Backend unter -> System -> Konfiguration -> Erweitert -> System ->Protokoll bereinigen kann man einstellen, dass die Logs auch mal gelöscht werden sollen. Diese Log-Dateien wachsen oft riesenhaft an und hier lohnt sich grade nach einer längeren Laufzeit des Shops ein Blick in die Log-Tabellen, da per “default” das automatische Bereinigen auf “Nein” steht…

Hab ich was vergessen? Dann freu ich mich über Mails mit Hausfrauentipps.

So. Viel Spaß nun beim Aufräumen wünscht sich den Bytestaub von den Händen klopfend…
Carmen Wingenbach.