Mage::blog()

Ein Onlineshop kommt selten allein. Deswegen muss er in aller Regel in eine Vielzahl von weiteren Systemen eingebettet werden. Es existieren allerhand Lösungen im Magento Connect, die eine Anbindung an ein bestimmtes System versprechen. Doch worauf muss bei der Integration eigentlich geachtet werden?

Zunächst mal muss spezifiziert werden, welche Systeme angebunden werden sollen und welche Informationen wie oft ausgetauscht werden müssen. Es ist davon auszugehen, dass eine vollständige Übertragung aller Produktinformationen eher selten durchgeführt werden muss; typischerweise werden die Produktinformationen einmal pro Nacht abgeglichen.
Bestellungen hingegen sollten doch häufiger ins Warenwirtschaftssystem übernommen werden, um einen Überblick über die Verfügbarkeit von Produkten für weitere Vertriebskanäle zu behalten.
Ein beispiel für eine Grobspezifikation könnte wie folgt aussehen:

• stündlicher Export von Bestellinformationen aus Magento in die Warenwirtschaft
• stündlicher Import von Bestellstatus-Informationen & Rechnungen aus der Warenwirtschaft in Magento
• stündlicher Import von Lagerbestands- und Preisinformationen aus der Warenwirtschaft
• Manueller Import von Produktinformationen aus dem Produktinformationssystem
• Import von Kundeninformationen nach Änderungen im CRM-System (wenn dieses onSave-Trigger zulässt!)

Nachdem geklärt ist, welche Systeme beteiligt sind und welche Informationen wie oft ausgetauscht werden bzw. welche Prozesse miteinander kommunizieren müssen, ist zu prüfen, welche Kommunikationsmöglichkeiten die einzelnen Systeme anbieten (Webservices, RESTful Services, lokale Dateiablage oder Ablage via FTP, SSH, Socket-Kommunikation usw.) und welche Formate sie hierbei nutzen (meist spezifische CSV oder XML-Formate, mitunter aber auch Standards wie BMEcat).
Die meisten vorliegenden Integrationslösungen verstehen unter “Integration” eine reine Datenintegration – Austausch von Daten. Um allen Anforderungen gerecht zu werden, wird mitunter jedoch eine Geschäftsprozessintegration nötig. Als Beispiel sei der Verkauf proprietärer Software über einen Onlineshop genannt: Nach erfolgreichem Abschluss einer Bestellung muss nun der Lizenzserver kontaktiert werden, um dort einen Lizenzschlüssel zu erstellen. Nach erfolgreicher Generierung wiederum erscheint der Schlüssel im Konto des Kunden.

Doch nicht nur die Menge und Art der Systeme ist je nach Unternehmen und Onlineshop unterschiedlich, sondern meist auch die Systeme selbst. Unternehmen haben unterschiedliche Datenobjekte, die Daten der einzelnen Objekte (bspw. Produkte) werden meist um unternehmensspezifische Daten erweitert. Magento trägt dem über das EAV-Attributsystem Rechnung, doch auch die Synchronisation muss hier auf die spezifischen Eigenheiten und Anforderungen des Kunden angepasst werden können. Standardlösungen werden in aller Regel keinen vollends befriedigenden Job machen können.

Magento bietet bereits hervorragende Möglichkeiten, Kunden anzusprechen und den gesamten Onlineshop an die Besonderheiten eines Unternehmens anzupassen. Einer der momentanen Nachteile des Systems ist die unzureichende Anbindung an weitere Systeme. Dataflow reicht für erweiterte Anforderungen schlicht nicht aus, die Magento Web Services API ist in der Regel zu langsam für große Datenmengen und unterstützt keine Geschäftsprozessintegration.

Aus diesem Grund hat Flagbit eine Plattform entwickelt, die Magento um Werkzeuge einer Integration erweitert und genug Raum für spezifische Anpassungen lässt. Es ist in der Regel keine Programmierung von PHP notwendig, sondern ausschließlich Konfiguration über XML, die dem System eine Übersetzung von externen Dialekten in Magento-Sprache ermöglicht. In den kommenden Wochen werden wir die Dokumentation des Systems stark erweitern und anschließend eine Projekt-Webseite anbieten. Mehr dazu in Kürze auf diesem Kanal.

Die Flagbit-Extension-Sammlung ist wieder um eine Erweiterung reicher: Das FAQ-Modul.

Diese Erweiterung fügt dem CMS-Menü im Backend den neuen Menüpunkt FAQ hinzu. Das Modul ermöglicht das Beantworten häufiger Fragen auf der Webseite und kann so das Einkaufserlebnis (neudeutsch: shopping experience) des Kunden verbessern, da er sich gut beraten fühlt. Außerdem können sich die Supportkosten verringern, da wiederkehrende Fragen nur einmal beantwortet werden müssen. Darüberhinaus kann durch die FAQ-Einträge, da hier in der Regel automatisch wichtige Schlagwörter erwähnt werden, quasi “nebenbei” die Suchmaschinen-Indizierung für wichtige Keywords erhöht werden.

Das FAQ-Modul untersützt die HTML-Formatierung in den Einträgen und greift dabei auf den neuen grafischen Editor zurück. Außerdem kann für jeden Eintrag die StoreView-Sichtbarkeit eingestellt werden und jeder Eintrag einzeln aktiviert oder deaktiviert werden.

Wir freuen uns heute nach langer Durststrecke wieder einmal eine TypoGento-Version veröffentlichen zu können. Die neue Version trägt die Version 1.0.0 und funktioniert nun endlich mit Version 1.4.1 von Magento.

Neben der eigentlichen Kompatibilität wurde außerdem Funktionalität für Single-Sign-On hinzugefügt. So werden Backend-User von TYPO3 mit denen von Magento kombiniert und synchronisiert wie auch die FE-User im Frontend von TYPO3 mit den Kunden in Magento verbunden werden können.

Wir wünschen viel Spaß mit der neuen Version und freuen uns auf Euer Feedback.

Im Moment läuft in Leipzig die Keynote von Roy Rubin über die Entwicklung von Magento und die kommende M-Commerce-Plattform von Magento. The North Face wird der erste Magento-Shop sein, der direkt mit iPhone-App daher kommt. Sieht schon relativ überzeugend auf. Aber da kann sich wohl jeder selbst überzeugen, die iPhone-App für “The North Face” wird heute veröffentlicht! Laut Roy Rubin folgt eine Version für das iPad und eine für die Android Plattform noch dieses Quartal.

Außerdem scheint Magento direkt aus den eigenen “Fehlern” zu lernen und hat jetzt eine zentrale Person für Dokumentation, Ausbildung und Zertifizierung – danke Cara! Wir sind gespannt, wie die Zertifizierung aussehen wird.

Heimlicher (peinlicher) Höhepunkt war das typisch amerikanische Magento-Success-Story-Video: Magento ist eigentlich vom Pol des Saturns und aus einem bisher unbekannten Material, dass ab sofort auf Position 119 des Periodensystems aufgeführt wird. Ich wusste schon immer, dass Magento irgendwie außerirdisch wirkt.

Mir ist es jetzt schon 2-3 mal passiert, dass nach dem Anschalten der neuen Merging Funktion für CSS und JavaScript Dateien viele Seiten nicht mehr funktionierten, weil Magento aus unerklärlichen Gründen absolute Pfade zu den CSS / JS Dateien im Quellcode angab. Nach ein wenig googlen, fand ich viele Leute, die dasselbe Problem hatten, aber eine akzeptable Lösung hatte ich nicht gefunden. Also nahm ich die Sache selber in die Hand.

Mit einem Blick in die exception.log (Aktivierbar unter System -> Konfiguration -> Entwickleroptionen -> Log Einstellung -> Aktiviert = Ja) findet man dann schon recht schnell eine Exception, die mit einer JavaScript oder CSS Datei zu tun hat. Bei mir sah das ungefähr so aus:

exception ‘Exception’ with message ‘Warning: filemtime() [function.filemtime]: stat failed for /var/www/js/calendar/lang/calendar-en.js in /var/www/app/code/core/Mage/Core/Helper/Data.php on line 631′ in /var/www/app/code/core/Mage/Core/functions.php:245

Hier will Magento mit der Methode filemtime prüfen wann die JavaScript datei calendar-en.js das letzte mal verändert wurde. Dummerweise gab es diese Datei bei mir nicht mehr und das Merging Script verabschiedete sich mit dieser Exception. Anstatt diese Datei einfach weg zu lassen, stoppt Magento den ganzen Merging Prozess und gibt einen halbfertigen Quellcode aus. Das ganze könnte man verhindern, wenn man vorher checken würde ob die Datei überhaupt existiert. Aber da ja deutlich BETA hinter diesem Feature steht, muss man mit solchen Fehlern rechnen.

Kleines Fazit:

Die Probleme beim Merging kommen meistens von fehlende CSS /JS Dateien oder keinen Schreibrechten in /media/css/ oder /media/js/. Mit einem Blick in die exception.log kann man sehr schnell die Ursache für sein Problem finden.

Das die Suchfunktion nicht gerade zu den Stärken von Magento gehört ist kein Geheimnis. Aufgrund der Komplexität dieses Themas wird es jedoch auch bei anderen Shop-Systemen oftmals an externe Dienstleister wie FACT-Finder oder epoq delegiert. Relativ neu in diesem Markt ist der österreichische Anbieter FINDOLOGIC, der mit seinem attraktiven Preis-Leistungs-Verhältnis gerade für kleine und mittlere Shops interessant ist.

FINDOLOGIC bietet die üblichen Features der Suchanbieter, wie Singular/Plural-Erkennung und die Korrektur von Tipp- und Rechtschreibfehlern sowie sinnverwandte Zusammenhänge und intelligentes Ranking um die Suchergebnisse zu verbessern, dass die angebotenen Produkte von den Kunden auch gefunden werden. Der Such-Service wird zum Komplettpreis bereits ab 30 € im Monat angeboten – dieser Preis gilt mit Anzeige das FINDOLOGIC-Logo auf der Suchergebnis-Seite.

Die Magento-Extension um die FINDOLOGIC-Suche anzubinden wurde  von Flagbit für die Österreicher entwickelt und kostenlos in Magento-Connect veröffentlicht. Neben dem Suchergebnis wird auch die Auto-Vervollständigung von FINDOLOGIC gefüttert und sollten deren Server ausnahmsweise einmal nicht erreichbar sein, wird automatisch die normale Magento-Volltextsuche verwendet.

Wir freuen uns zwei neue Erweiterungen für Magento veröffentlichen zu können: Ein einfacher FeedReader für RSS- und Atom-News-Feeds und eine Einbindung des Google-Webmaster-Tool-Verification-Codes als Meta-Tag.

Eigentlich erstaunlich, dass es für so ein “gewöhnliches” Feature wie das Einbinden eines News-Feeds bisher keine kostenlose Extension gab. Der FeedReader basiert auf Zend_Feed – kann also alles verarbeiten, das auch Zend_Feed kann. Die Konfiguration lässt sich derzeit nur per layout.xml erledigen, da hier die größte Flexibilität gegeben ist. Eine Anbindung als Widget wäre schön, haben wir bisher aber noch nicht realisiert – falls sich jemand berufen fühlt, freuen wir uns natürlich über entsprechende Patches Auf Treppenstufenmatten.com kann man den FeedReader links unten live im Einsatz sehen.

Die Google-Extension fügt eigentlich nur ein weiters Feld zur Backend-Konfiguration hinzu und gibt dieses als Meta-Tag im HTML-Head auszugeben. Sehr simpel, aber doch deutlich angenehmer und flexibler als den Code jedes Mal im Template einfügen zu müssen oder HTML-Dateien mit kryptischen Namen im Document Root herumliegen zu haben.

Da derzeit das Error-Handling im CustomerController des Backends kaputt. Statt der Exception-Message erscheint eine andere Exception: sehr unschön und mühsam beim Debuggen:

Item (Mage_Customer_Model_Address) with the same id "1" already exist
 
#0 /var/www/virtual/mage/mage-df-1/app/code/core/Mage/Eav/Model/Entity/Collection/Abstract.php(236): Varien_Data_Collection->addItem(Object(Mage_Customer_Model_Address))
#1 /var/www/virtual/mage/mage-df-1/app/code/core/Mage/Customer/Model/Customer.php(204): Mage_Eav_Model_Entity_Collection_Abstract->addItem(Object(Mage_Customer_Model_Address))
#2 /var/www/virtual/mage/mage-df-1/app/code/core/Mage/Adminhtml/controllers/CustomerController.php(112): Mage_Customer_Model_Customer->addAddress(Object(Mage_Customer_Model_Address))
#3 /var/www/virtual/mage/mage-df-1/app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Adminhtml_CustomerController->editAction()
#4 /var/www/virtual/mage/mage-df-1/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('edit')
#5 /var/www/virtual/mage/mage-df-1/app/code/core/Mage/Core/Controller/Varien/Front.php(177): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#6 /var/www/virtual/mage/mage-df-1/app/code/core/Mage/Core/Model/App.php(304): Mage_Core_Controller_Varien_Front->dispatch()
#7 /var/www/virtual/mage/mage-df-1/app/Mage.php(596): Mage_Core_Model_App->run(Array)
#8 /var/www/virtual/mage/mage-df-1/index.php(78): Mage::run('', 'store')
#9 {main}

Ich habe den Bug als Issue erfasst, doch es dürfte wohl etwas dauern, bis Varien das Issue bearbeitet und die nächste Version veröffentlicht. Den Patch habe ich auch dem Issue im Magento-Bugtracker angehängt aber offensichtlich können Dateien von außen nicht abgerufen werden, was sehr schade ist. Daher veröffentliche ich den Patch auch mal hier:

### Eclipse Workspace Patch 1.0
#P magento-1.4
Index: app/code/core/Mage/Adminhtml/controllers/CustomerController.php
===================================================================
--- app/code/core/Mage/Adminhtml/controllers/CustomerController.php	(revision 61891)
+++ app/code/core/Mage/Adminhtml/controllers/CustomerController.php	(working copy)
@@ -107,9 +107,12 @@
         }
         if (isset($data['address']) && is_array($data['address'])) {
             foreach ($data['address'] as $addressId => $address) {
-                $addressModel = Mage::getModel('customer/address')->setData($address)
+                if (!($addressModel = $customer->getAddressItemById($addressId))) {
+                    $addressModel = Mage::getModel('customer/address');
+                    $customer->addAddress($addressModel);
+                }
+                $addressModel->setData($address)
                     ->setId($addressId);
-                $customer->addAddress($addressModel);
             }
         }

We make websites run

Als spezialisierter Dienstleister für Webtechnologien sorgen wir bei Flagbit dafür, dass die Webseiten unserer Kunden optimal zu Geltung kommen. Open Source-Systeme wie TYPO3, Magento oder das Zend Framework nutzen wir, um Webseiten, Online Shops oder individuale Webanwendungen zu erstellen, die auf unsere Kunden sowie deren Kunden maßgeschneidert sind. Gleichzeitig geben wir den Open Source-Communities durch regelmäßige Veröffentlichungen von Modulen oder Blog-Beiträgen einen Teil unserer Arbeit zurück.

Wir suchen nun Verstärkung für unser junges Team, welches sich sowohl um Kunden wie Radio FFN, Josef Seibel, das Zentrum für Europäische Wirtschaftsforschung, die Hochschule Mannheim, MSC/Gleichmann Electronics, Bosch-Rexroth, brand eins (Gemeinschaftsprojekt mit blindwerk – neue medien KG) oder Netviewer (Gemeinschaftsprojekt mit ping 24/7) als auch um eigene Produkte wie TypoGento oder die Magento Integration Platform kümmert.

Deine Aufgaben

Im Rahmen unserer Arbeit mit Magento gibt es eine Vielzahl von Arbeiten zu erledigen. In deinen Verantwortungsbereich fallen:

• Konzeption und Entwicklung von maßgeschneiderten Shop-Systemen
• Konzeption und Entwicklung von Erweiterungs-Modulen für Magento für Kunden oder die Open Source Gemeinde
• Wartung und Weiterentwicklung bestehender Systeme
• Entwicklung von Individual-Software auf Basis von Magento oder dem Zend Framework
• Diskussion, Gestaltung und Realisierung interessanter Open Source Projekte
• Schulung von Kunden oder Anwendern

Dein Profil

Zum Erledigen der Aufgabenstellungen sind einige fachliche und menschliche Anforderungen notwendig. Dass du dich mit dem Internet, dem Web und den notwendigen Geräten auskennst, setzen wir einfach mal voraus. Was du außerdem mitbringen solltest:

• Fundierte Kenntnisse in XHTML, CSS, PHP5 & MySQL
• Grundkenntnisse im Administrieren von Server-Technologien
• Möglichst bereits Erfahrungen mit dem Zend Framework und/oder Magento
• Lernbereitschaft, Motivation und Teamfähigkeit
• Selbständiges Arbeiten, freundliches, kundenorientiertes Auftreten
• Vorzeigbares Deutsch & Englisch in Wort und Schrift

Vorteilhaft wären darüber hinaus Erfahrungen in den Punkten:

• Konzeption oder Leitung von Web-Projekten
• Kenntnisse in Javascript, AJAX und Webservices
• Erfahrungen mit TYPO3
• Kenntnisse in SVN, Unit Testing oder Continuous Integration

Was dich bei uns erwartet

Natürlich soll all die gute Arbeit auch belohnt werden. Was du bei uns erwarten kannst:

• Ein junges, dynamisches, freundliches und motiviertes Team
• Eine angemessene & leistungsgerechte Bezahlung
• Ein professionelles und sehr gut ausgestattetes Arbeitsumfeld
• Flache Hierarchien & schnelle, unkomplizierte Entscheidungswege
• Flexible Arbeitsbedingungen
• Kostenfreie Getränke mit Kaffee-Flatrate
• Vielseitige und verantwortungsvolle Arbeit an interessanten Projekten

Interesse?

Wir haben dein Interesse geweckt? Dann kontaktiere uns einfach per E-Mail unter jobs@flagbit.de. Wir freuen uns auf deine Bewerbung!

Grundlegende Erkenntnisse

Magento ist prinzipiell modular aufgebaut. In Version 1.3 besteht Magento aus zirka 50 Core-Module, deren Funktionalität sich durch weitere Community- oder Local-Extensions erweitern und verändern lässt.

Das Backend ist, was dies angeht eher ein schlechtes Beispiel: Es ist nicht modular aufgebaut, wie man dies vom Frontend her gewohnt ist – die meisten Standard-Interfaces befinden sich im Modul „Adminhtml“. Für den Entwickler hat dies einige Nachteile, wie sich im Laufe der Beitragsserie zeigen wird.

Trotzdem bietet auch das Backend einige Möglichkeiten, bestehende Funktionalitäten anzupassen und zu erweitern. Wie das geht, werden wir in den kommenden Wochen mit einigen kleinen Beiträgen anhand einiger bestehender Module beschreiben. Die Möglichkeiten werden in diesen mit Sicherheit nicht ausgeschöpft – falls wir was Wichtiges vergessen haben sollten, weißt uns bitte drauf hin.

Dieser erste Beitrag beschäftigt sich mit den Teilen der Konfiguration, die für die Erstellung von Backend Interfaces interessant sind.

Die Konfiguration

Wie jedes Modul benötigen auch Backend-Module Konfigurations-Einstellungen, die über die Definitionen der config.xml eingestellt werden. Die allgemeinen Einstellungsmöglichkeiten wie die Definition von Models, Blocks oder Helpern sind nicht Bestandteil dieses Beitrags; viel mehr soll fokussiert auf die speziellen Einstellungen für Backend-Module eingegangen werden.

Der <modules>-Block

Im ersten Block werden allgemeine Informationen zum Modul definiert, wie der Name, die Version und ob das Modul aktiv ist oder nicht:

  <modules>
    <Flagbit_Glossary>
      <active>true</active>
      <codePool>local</codePool>
      <version>0.2.0</version>
    </Flagbit_Glossary>
  </modules>

Der <admin>-Block

Nachdem wir im modules-Block zunächst allgemeine Informationen über das Modul gegeben haben, bietet der zweite Block zwei wichtige allgemeine Einstellungen des Magento-Backends: die Registrierung unseres Admin-Controllers sowie die Definition unserer Adressen.

  <admin>
    <routers>
      <glossary>
        <use>admin</use>
        <args>
          <module>Flagbit_Glossary</module>
          <frontName>glossary</frontName>
        </args>
      </glossary>
    </routers>

Damit ein Modul überhaupt eigene Informationen verarbeiten kann, muss es einen oder mehrere Controller bei den Routern definieren können. (Action-)Controller sind für die Steuerung der Abläufe und Prozesse innerhalb der MVC-Architektur von Magento zuständig. Router wiederum sind Controller, die einen bestimmten Aufruf anhand der Adresse an einen Action Controller übergeben.

Innerhalb des routers-Block verstecken sich folgende Angaben (vgl. Mage_Core_Controller_Varien_Router_Standard :: collectRoutes()):

• Das XML-Tag <glossary> bestimmt den Namen der aktuellen Route. Auf diese Art und Weise wäre es möglich, bestehende Routen über ein eigenes Modul zu überschreiben.
• Im Backend ist es natürlich wichtig, dass alle Sicherheitsbestimmungen greifen und die Interfaces nicht aus dem Frontend aufgerufen werden können. Dementsprechend wird hier der Wert „admin“ übergeben.
• Das Module beschreibt natürlich das aktuelle Modul.
• Der FrontName wiederum bestimmt, unter welcher URL das eigene Modul aufgerufen werden kann. In unserem Fall wäre dies „http://www.example.com/glossary“.

    <rewrite>
      <Flagbit_Glossary>
        <from>
          <![CDATA[#^/{adminhtml}/glossary/#]]>
        </from>
        <to>/glossary/admin/</to>
      </Flagbit_Glossary>
    </rewrite>
  </admin>

Um das Backend-Modul nun optimal in das Magento-Backend zu integrieren, sollten sich auch die URLs des Moduls an den Admin-Adressen orientieren – die bisherige URL sieht eher wie die im Frontent aus. Hierfür steht der <rewrite>-Block, der alle Aufrufe von „/{adminhtml}/glossary“ auf den AdminController unseres Frontnames weiterleitet. ”{adminhtml}“ ist hierbei als Platzhalter für das die Adresse des Backend zu verstehen – dieser wird von Magento automatisch ausgetauscht. Als Resultat wird dem Nutzer automatisch unser AdminController angezeigt, wenn er den “GlossarController von Adminhtml” aufrufen möchte.

Der <adminhtml>-Block

  <adminhtml>
    <menu>
      <cms>
        <children>
          <glossary translate="title" module="glossary">
            <title>Glossary</title>
            <action>adminhtml/glossary</action>
            <sort_order>50</sort_order>
          </glossary>
        </children>
      </cms>
    </menu>

Der erste Teil des XML-Blocks beschreibt die Einbindung unseres Moduls in das Menü des Backends. Die Hauptmenü-Punkte sind Kindknoten von <menu>; in unserem Fall bauen wir keinen neuen Punkt in der ersten Ebene ein, sondern fügen einen neuen Unterpunkt zu CMS hinzu.

<cms> versteht sich als Referenz auf die Definitionen, die in der config.xml des CMS-Moduls eingefügt wurden – so könnten andere Module wiederum auf die Definitionen von <glossary> zugreifen und diese ändern oder erweitern. Zu beachten ist hierbei auch, dass zwei Module einer Extensions auch eindeutige Keys benötigen!

<title>, <action> und <sort_order> sind an sich selbsterklärend; bei <action> sollte nach Möglichkeit die Adresse angegeben werden, die wir im <rewrite> definiert haben.

    <acl>
      <resources>
        <admin>
          <children>
            <cms>
              <children>
                <glossary translate="title" module="glossary">
                  <title>Glossary</title>
                  <sort_order>50</sort_order>
                </glossary>
              </children>
            </cms>
          </children>
        </admin>
      </resources>
    </acl>
  </adminhtml>

Der <acl>-Bereich ist bezüglich des Aufbaus verwandt mit dem beschriebenen Menü. Er ermöglicht die Rechteverwaltung im Backend von Magento. Logischerweise wird der Glossar auch hier wieder als Kindknoten von CMS definiert.

Als Resultat gibt es in der Rechteverwaltung eine neue Checkbox – beim Generieren des Menüs und Aufruf des Moduls wird überprüft, ob das entsprechende Häkchen gesetzt ist oder eben nicht. Als Hinweis sei erlaubt, dass beim Testen der Rechte ein neuer Login Wunder bewirken kann, da die Rechte beim Login überprüft und in die Session des Nutzers gespeichert werden.

Die gesamte config.xml

Wie die gesamte Konfiguration aussehen kann, zeigt das folgende Listing:

<?xml version="1.0"?>
<config>
  <modules>
    <Flagbit_Glossary>
      <active>true</active>
      <codePool>local</codePool>
      <version>0.2.0</version>
    </Flagbit_Glossary>
  </modules>
  <admin>
    <routers>
      <glossary>
        <use>admin</use>
        <args>
          <module>Flagbit_Glossary</module>
          <frontName>glossary</frontName>
        </args>
      </glossary>
    </routers>
    <rewrite>
      <Flagbit_Glossary>
        <from>
          <![CDATA[#^/{adminhtml}/glossary/#]]>
        </from>
        <to>/glossary/admin/</to>
      </Flagbit_Glossary>
    </rewrite>
  </admin>
  <adminhtml>
    <menu>
      <cms>
        <children>
          <glossary translate="title" module="glossary">
            <title>Glossary</title>
            <action>adminhtml/glossary</action>
            <sort_order>50</sort_order>
          </glossary>
        </children>
      </cms>
    </menu>
    <acl>
      <resources>
        <admin>
          <children>
            <cms>
              <children>
                <glossary translate="title" module="glossary">
                  <title>Glossary</title>
                  <sort_order>50</sort_order>
                </glossary>
              </children>
            </cms>
          </children>
        </admin>
      </resources>
    </acl>
  </adminhtml>
</config>

Fazit

Im ersten Beitrag zur Entwicklung von Backend-Modulen haben wir die Definitionen der Konfiguration kurz unter die Lupe genommen. Mangels Dokumentation fällt deren Interpretation nicht immer leicht – den Platzhalter für {adminhtml} mussten wir uns auch im Quelltext zusammensuchen.

Mit der Konfiguration konnten wir den Grundstein für die Entwicklung von Backend-Modulen legen, indem wir unsere Controller registriert und in das Menü mit eingebunden haben. Viel Funktionalität haben wir damit natürlich noch nicht – in den kommenden Beiträgen werden wir diese Hülle mit Leben füllen.