Die Einbindung des „Gefällt mir“ Buttons von Facebook gehört mehr oder weniger zum Standardprogramm von Online-Shops. Damit bei Facebook die tatsächlich gewünschten (Produkt-)Informationen veröffentlicht werden, kann die Integration der so genannten Open Graph Meta-Tags weiterhelfen. Wie das in Magento funktioniert, zeigt der folgende Artikel.

Diese speziellen Meta-Tags besitzen jeweils das Präfix og: und können verschiedene Inhalte wie Seitenname, Produktbild, etc. beschreiben. Für Produkt-Links sind vor allem das Bild und der Titel interessant.

Zu Beginn muss der „Gefällt mir“ Button auf der Produktseite eingebaut werden. Dazu wird in der Template-Datei /catalog/product/view.phtml an der gewünschten Stelle folgender Code eingebunden, der auf Facebook’s Developer Seiten individuell definiert werden kann:

<div class="fb-like" data-href="<?php echo $_product->getProductUrl() ?>" data-width="350" data-send="false" data-show-faces="false"></div>

Wichtig ist hierbei der Wert des Attributs data-href, damit immer die jeweilige Produkt-URL zu Facebook übertragen wird.

Um nun die Open Graph Meta-Tags einzubinden, ist die Datei /page/html/head.phtml mit folgenden Code zu erweitern.

<?php if($_SERVER['HTTP_USER_AGENT'] == 'facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)') : ?>
<?php if (Mage::registry('current_product')) : ?>
<meta property="og:title" content="<?= $_product->getName() ?> im Online Shop XY bestellen" />
<meta property="og:image" content="<?php echo Mage::helper('catalog/image')->init(Mage::registry('current_product'), 'small_image')->resize(190);?>" />
<?php endif;?>
<?php endif;?>

Zuerst wird überprüft ob Facebook versucht, die Daten auszulesen. Erst dann werden die Open Graph Meta-Tags eingebunden. Somit ist es möglich, weiterhin validen HTML-Code zu erzeugen, da die Facebook-Meta-Tags nicht W3C-konform sind. Im Quelltext sind somit die Angaben für den Open Graph nicht zu sehen.

Danach wird überprüft, ob man sich auf einer Produktseite befindet. Ist das der Fall, werden die Open Graph Meta-Tags entsprechenden ausgegeben.

Danach noch den Magento-Cache leeren, testen und überprüfen ob alles wunschgemäß bei Facebook veröffentlicht wird.

Bekannterweise ist die Suchfunktion aus dem Standardumfang von Magento eher einfach gestrickt und für die ersten Schritte im Online-Business vielleicht auch noch eine Lösung.

Wer jedoch wirklich professionell verkaufen möchte muss sich nach einer Alternative umschauen – in Form von zusätzlichen Modulen oder externen Anbietern. Aus diesem Grund zeigt die folgende Aufstellung 10 Magento-Extensions die Verbesserungen hinsichtlich der Suche bringen – schließlich ist die Suche einer der Erfolgsfaktoren in Online-Shops.

Search Autocomplete and Suggest

Mit diesem Modul wird das Suchfeld um eine Auto-Suggest Funktion erweitert. Das nette daran ist, dass auch die Produktbilder gleich neben den Vorschlägen angezeigt werden. Für 89,00 Dollar erhält man eine ausgereifte Funktion, die jedoch im Demo-Store bei der Performance nicht punkten konnte (dieser Demo-Store ist allerdings generell langsam). Das Modul ist sowohl für die Community- und Enterprise-Edition erhältlich.

Ajax Search And Autocomplete

Mehr oder weniger dieselbe Funktion, wie das zuvor erwähnte Modul, bietet dieses Magento-Plugin. Es zeigt ebenfalls Bilder neben den Such-Vorschlägen an und kostet nur $ 29,00. Zudem ist die Extension mit vielen Magento-Versionen kompatibel.

Tangkoko & Fidesio CMS Search

Diese Modul erweitert die Magento-Suche, indem es zusätzlich die Inhalte der statischen Textseiten durchsucht. Ein kleines, feines Plugin, das kompatibel mit allen wichtigen Magento-Community-Versionen ist und zudem kostenlos zur Verfügung steht.

Part Finder

Mit dem „Part Finder“ können die Benutzer vorab über Auswahlboxen bestimmte Attribute abfragen und sich sogleich die passenden Produkte anzeigen lassen. Ein interessantes Feature, dass die User Experience im Shop erhöht.

Catalog Search Refinement

Dieses kostenlose Magento-Modul verbessert die Suche, indem nicht nach allen in das Suchfeld eingetippten Wörtern gesucht wird, sondern bei Mehrwort-Kombination nur nach Produkten die tatsächlich auf die eingetippten Wörter zutreffen. Eine absolute Bereicherung der Magento-Suche!

Better Store Search

Dieses für die Community- und Enterprise-Edition erhältliche Such-Modul, ersetzt die Standard-Suche und implementiert eine gänzlich neue Suchfunktion samt verbessertem Algorithmus. Das Modul kostet zwar $ 249,00, bringt aber mit Sicherheit eine bessere Qualität in die Suchergebnisse.

Blast Search Lucence

Auf Basis von Lucence ersetzt dieses Modul ebenfalls die Magento-Suche. Es bringt bessere / exaktere Suchergebnisse und steigert deutlich die Performance der Suche. Die Kosten mit $ 149,99 sind hier gut angelegt, da damit eine zentrale Funktion im Shop erheblich verbessert wird.

Solr Bridge Search

Diese Extension, die auf der Open Source Platform Solr basiert, bietet eine eigenständige Suchfunktion innerhalb von Magento inklusive Faceted Search und Auto-Suggest. Mit $ 450,00 ist das Modul jedoch nicht ganz günstig, dafür aber sehr leistungsfähig.

Advanced Search

Das Magento-Modul „Advanced Search“ integriert ebenfalls eine eigenständige Suchfunktion mittels Sphinx. Im Backend können, wie bei den anderen Such-Modulen auch, Einstellungen zur Suche durchgeführt werden. Die Extension kostet $ 199,00 und ist kompatibel für die gängigsten Community- und Enterprise-Versionen.

FACT-Finder on-site search

Wer bei der Suche auf FACT-Finder setzt wird dieses Modul verwenden. Die Qualität der Suchergebnisse wird beim Einsatz eines externen Suchanbieters wie FACT-Finder auf jeden Fall besser sein, als bei der Standard-Magento-Suche. Ebenso zeigt das FACT-Finder Modul unter anderem bei der After-Search-Navigation seine große Stärke. Dafür kostet der Service auch einiges, wobei sich die Investitionen im Regelfall amortisieren sollten.

Findologic

Mit dem Findologic-Modul kann ebenfalls auf einen externen Suchanbieter gesetzt werden. Nach Rücksprache bei Findologic ist das Modul bis zur Version 1.6 kompatibel (hingegen den Angaben bei Magento-Connect). Findologic ist sicherlich eine Alternative zu FACT-Finder, da man hier qualitativ gute Suchergebnisse für einen guten Preis bekommt.

Für Shopbetreiber, die Google AdWords für Ihre Marketingaktivitäten einsetzen, ist es unabdingbar den Erfolg und Performance der AdWords-Kampagnen zu messen. Meist wird das anhand der im Shop getätigten Bestellungen durchgeführt. Dabei wird ein kleines Code-Schnipsel, der so genannten Conversion-Tracking Code, auf die "Bestätigungs"- bzw. "Danke-Seite" eingebunden.

Magento bietet mittels der Konfiguration im Admin-Bereich keine Möglichkeit, den Tracking-Code über ein grafisches Interface einzubinden. Daher muss dieser im Template manuell eingebunden werden.

Dies kann entweder in der Datei /checkout/success.phtml erfolgen. Oder noch eleganter mittels eines eigenen Blocks. Das kann dann wie folgt aussehen:

<checkout_onepage_success translate="label">
  <reference name="content">
    <block type="core/template" name="adwords.conversiontracking" template="checkout/conversiontracking.phtml"/>
  </reference>
</checkout_onepage_success>

Diese Variante bietet den Vorteil, das der Block an mehreren Stellen eingebunden werden kann (z.B. auf der Bestätigungsseite für Newsletter). Änderungen am Block wirken sich dann auf allen Seiten aus, wo der Block integriert ist.

Shopbetreiber die Magento im Einsatz haben, kennen sicherlich das Problem: Magento vergibt standardmäßig keine automatische SKU (Artikelnummer) bzw. lässt sich diese Option auch nicht in der Systemkonfiguration einstellen.

Aus diesem Grund haben wir ein kleines Modul erstellt, das nichts anderes macht, als die saveAction() des ProductControllers im Backend zu überschreiben.

Im folgenden Beispiel verwendet das Modul den Namespace "Keynet" und bekommt den Namen "AutoSku". Wir erstellen also unter /app/code/local/Keynet/ einen Ordner mit diesem Namen. Weiters werden darin die Unterordner /controllers und /etc erzeugt.  Im Ordner /controllers wird weiters der Ordner /Catalog erstellt und darin die Datei ProductController.php gespeichert.

Anschließend erzeugen wir eine Kopie der saveAction-Methode von /app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php und erweitern diese um die Funktionalität der automatischen SKU-Vergabe. Die fertige Controller-Datei sieht wie folgt aus:

<?php
require_once 'Mage/Adminhtml/controllers/Catalog/ProductController.php';
class Keynet_AutoSku_Catalog_ProductController extends Mage_Adminhtml_Catalog_ProductController
{

	/**
     * Save product action
     */
    public function saveAction()
    {
        $storeId        = $this->getRequest()->getParam('store');
        $redirectBack   = $this->getRequest()->getParam('back', false);
        $productId      = $this->getRequest()->getParam('id');
        $isEdit         = (int)($this->getRequest()->getParam('id') != null);

        $data = $this->getRequest()->getPost();

        if ($data) {
            if (!isset($data['product']['stock_data']['use_config_manage_stock'])) {
                $data['product']['stock_data']['use_config_manage_stock'] = 0;
            }
            $product = $this->_initProductSave();

            if($data['product']['sku']=="") {
				$write = Mage::getSingleton('core/resource')->getConnection('core_write');
				$res = $write->query("SELECT max(sku) AS maxSKU FROM catalog_product_entity");
				$row = $res->fetch();
				$prev_sku = $row['maxSKU'];
				$sku_val = (int)$prev_sku + 1;
				$product->setSku($sku_val);
			}

            try {
                $product->save();
                $productId = $product->getId();

                /**
                 * Do copying data to stores
                 */
                if (isset($data['copy_to_stores'])) {
                    foreach ($data['copy_to_stores'] as $storeTo=>$storeFrom) {
                        $newProduct = Mage::getModel('catalog/product')
                            ->setStoreId($storeFrom)
                            ->load($productId)
                            ->setStoreId($storeTo)
                            ->save();
                    }
                }

                Mage::getModel('catalogrule/rule')->applyAllRulesToProduct($productId);

                $this->_getSession()->addSuccess($this->__('The product has been saved.'));
            }
            catch (Mage_Core_Exception $e) {
                $this->_getSession()->addError($e->getMessage())
                    ->setProductData($data);
                $redirectBack = true;
            }
            catch (Exception $e) {
                Mage::logException($e);
                $this->_getSession()->addError($e->getMessage());
                $redirectBack = true;
            }
        }

        if ($redirectBack) {
            $this->_redirect('*/*/edit', array(
                'id'    => $productId,
                '_current'=>true
            ));
        }
        else if($this->getRequest()->getParam('popup')) {
            $this->_redirect('*/*/created', array(
                '_current'   => true,
                'id'         => $productId,
                'edit'       => $isEdit
            ));
        }
        else {
            $this->_redirect('*/*/', array('store'=>$storeId));
        }
    }
}

Der interessante Teil ist dabei die If-Anweisung von Zeile 24 bis 31. Hiermit wird geprüft, ob im SKU-Feld ein Wert vergeben wurde. Ist das Feld leer, wird aus der Datenbank die höchste Artikelnummer gesucht und diese um 1 erhöht. Anschließend wird dem zu speichernden Artikel diese neue Artikelnummer zugewiesen.

Wichtig ist zudem, die Verwendung des require_once Statements in Zeile 2. Weiters muss zuvor unter "Attribute verwalten" das SKU-Feld so eingestellt werden, dass es kein Pflichtfeld ist (Option "Werte erforderlich" auf "Nein" setzen).

Jetzt muss Magento noch darüber informiert werden, dass wir ab nun unsere saveAction-Methode  verwenden wollen. Das geschieht mit der Datei config.xml im Ordner /etc.

<?xml version="1.0"?>
<config>
    <modules>
        <Keynet_AutoSku>
            <version>0.1.0</version>
        </Keynet_AutoSku>
	</modules>
    <admin>
		<routers>
			<adminhtml>
				<args>
					<modules>
						<Keynet_AutoSku before="Mage_Adminhtml_Catalog_ProductController"> Keynet_AutoSku</Keynet_AutoSku>
					</modules>
				</args>
			</adminhtml>
		</routers>
	</admin>
</config>

Hiermit weisen wir Magento an, dass ab nun unsere Action-Methode für die Speicherung von Artikeln im Backend zu verwenden ist. Das war's! Das Modul muss noch mit der Datei "Keynet_AutoSku.xml" in /app/etc/modules/ aktiviert werden. Wie diese Datei aussehen kann, zeigt unter anderem dieser Artikel hier im Blog.

Portiert man einen bereits bestehenden Shop nach Magento (oder egal in welches System), entstehen dabei in der Regel eine Vielzahl an 404-Fehlern, da sich die Produkt-Url's ändern. Die sauberste Lösung ist dabei, Redirects für alle alten Url's automatisiert herzustellen, was jedoch auch immer abhängig vom alten Shop-System und dessen URL-Aufbau ist.

Die andere und einfachste Variante ist die Anzeige der Startseite anstatt einer 404-Fehlerseite. Hierfür bietet Magento über "System > Konfiguration > Web > Standardseiten > CMS keine Route Seite" die Möglichkeit, eine Standardseite für nicht existierende Seiten einzustellen.

Ruft man also z.B. www.domain.com/meine-nicht-vorhandene-seite auf, dann wird mit dieser Einstellung der Inhalt der Startseite angezeigt. Die URL bleibt trotzdem im Browser stehen, und zudem wird im Header der Statuscode 404 gesendet. Beim Relaunch eine Shops entsteht dabei das Problem, dass hiermit ziemlich viele 404-Seiten vorhanden sind, und sich dies negativ auf die Google-Rankings auswirken könnte.

Schöner und besser wäre es meiner Meinung nach, alle nicht mehr vorhandenen Seiten direkt per 301-Redirect auf die Startseite weiterleiten zu lassen. Da Magento seinen eigenen Error-Handler verwendet, ist dies jedoch nicht so einfach möglich. Zum Beispiel wird die Anweisung "ErrorDocument 404 /" in der .htaccess-Datei schlichtweg ignoriert. Abhilfe schafft ein eigenes Modul, das den IndexController und in weiterer Folge die noRoute-Action überschreibt.

Für das Modul wird anfangs unter app/code/local/Keynet der Ordner "Redirect" erstellt (der Ordner "Keynet" wird bei Euch auch anders lauten oder muss eben erst erstellt werden). Im Ordner "Redirect" sind dann noch die beiden Verzeichnisse "etc" und "controllers" zu erzeugen. Danach muss die Datei config.xml im Ordner "etc" erzeugt und mit folgendem Inhalt gespeichert werden:

<?xml version="1.0"?>
<config>
  <modules>
    <Keynet_Redirect>
      <version>0.0.1</version>
    </Keynet_Redirect>
  </modules>
  <frontend>
    <routers>
      <mycms>
        <use>standard</use>
        <args>
          <module>Keynet_Redirect</module>
          <frontName>redirect</frontName>
        </args>
      </mycms>
    </routers>
  </frontend>
  <global>
    <routers>
      <cms>
        <rewrite>
          <index>
            <to>Keynet_Redirect/index</to>
            <override_actions>true</override_actions>
            <actions>
              <noroute><to>Keynet_Redirect/index/noroute</to></noroute>
            </actions>
          </index>
        </rewrite>
      </cms>
    </routers>
  </global>
</config>

Anschließend wird die Datei IndexController.php in /controllers erzeugt. Darin wird die noRoute-Action überschrieben und eine Weiterleitung per 301-Statuscode zur Startseite eingerichtet.

<?php
class Keynet_Redirect_IndexController extends Mage_Cms_IndexController
{
    public function noRouteAction($coreRoute = null)
    {
        header("Status: 301");
        header('Location: http://www.domain.com/');
    }
}

Abschließend ist noch die Datei Keynet_Redirect in /app/etc/modules herzustellen, damit die Extension auch durch Magento aktiviert bzw. verwendet wird. Zur Vollständigkeit halber hier der Inhalt dieser Datei:

<?xml version="1.0" encoding="UTF-8"?>
<config>
   <modules>
      <Keynet_Template>
         <active>true</active>
         <codePool>local</codePool>
      </Keynet_Template>
   </modules>
</config>

Am Ende möchte ich noch die Diskussion starten, ob es unbedingt notwendig ist hierfür extra ein Modul zu entwickeln, oder ob Ihr der Meinung seit, das Google ja sowieso nach einiger Zeit die Seite mit den 404-Statuscodes entfernt/ignoriert und die Umstellung mit den damit verbundenen Fehlerseiten keine negative Auswirkungen auf die Rankings haben wird? Ich freue mich auf eventuelle Antworten bei den Kommentaren!

Der folgende Artikel zeigt zwei Snippets, die bei der Entwicklung von Themes bzw. Templates mit Magento hilfreich sein können.

Möchte man für die einzelnen StoreViews gewisse Bereiche unterschiedlich haben, z.B dass jeweils eine separate länderspezifische Kontakt E-Mail Adresse angezeigt wird, so muss zuerst der StoreView Code abgefragt werden. Dies funktioniert mit folgendem PHP-Statement:

$store = Mage::app()->getStore()->getCode();

// Anschließend nach dem StoreView Code unterscheiden
switch ($store) {
case 'at':
  $mail = 'info@domain.at';
case 'de':
  $mail = 'info@domain.de';
case 'ch':
  $mail = 'info@domain.ch';
default:
  $mail = 'info@domain.com';
}

Das zweite, kleine Helferlein macht folgendes:  Damit nicht immer gesamte Pfad zum eigenen Skin-Folder eingetippt werden muss, kann die folgende PHP-Funktion eingesetzt werden.

$path = $this->getSkinUrl();
echo '<img src="' . $path . 'images/my_image.jpg" />';

So ist es möglich, auf einfache Weise, auf die Bilder im Skin-Ordner zu verweisen. Und sollte sich das Skin einmal ändern, so sind keine weiteren Änderungen in der Template-Datei notwendig.

Nun ist es fix: Für einen neu gewonnenen Kunden, entwickeln wir einen Online-Shop auf Basis des E-Commerce System Magento. Der Shop wird ca. 14.000 Produkte / Produktvarianten umfassen. Branche und Namen des Kunden werden später bekannt gegeben!

Zu Beginn wird ein, extra für dieses Shop-Projekt, erstelltes Screendesign in Magento integriert, so dass der Shop mit einem individuellen Erscheinungsbild punkten kann. Weiters werden zahlreiche, länderspezifische Einstellungen (z.B. für die Schweiz) vorgenommen, da der Online-Shop weltweit Kunden beliefert. Eine Ausweitung und Optimierung des internationalen Vertriebs, wie z.B. ein mehrsprachiger Shop, ist in einer weiteren Projektphase geplant.

Nun gilt es einmal, Magento so zu konfigurieren, dass der Shop lauffähig ist und ordnungsgemäß darüber Bestellungen durchgeführt werden können. Ein zentraler Punkt ist dabei die Integration eines Moduls für Kreditkartenzahlungen. Diese erste Projektphase soll Anfang September abgeschlossen sein. Da werden dann auch Kundenname und Shop-Domain hier im Blog veröffentlicht.

Wie gestern bekannt wurde, wird Magento nun komplett von eBay übernommen. Bereits im letzten Jahr sicherte sich die Auktionsplattform 49% an der E-Commerce Software. Die offizielle Mitteilung zur Übernahme ist im Magento Blog zu lesen. Magento soll in Zukunft Bestandteil von X.Commerce werden.

Wie es nun mit Magento weitergehen wird, ist schwer zu sagen. Es ist kaum vorzustellen, dass eBay komplett auf Magento Community "pfeifen" wird. Weiters wird interessant zu beobachten sein, was nun genau von Magento 2 kommen bzw. was die neue Version endgültig beinhalten wird.

Durch die Übernahme Magento's durch eBay, haben wir einen Grund mehr, uns nun in Zukunft intensiver mit Shopware zu beschäftigen. Shopware ist ein Shopping-System das, genauso wie Magento, auf dem Zend Framework basiert. Allerdings ist sie um einiges schlanker und daher auch performanter. Ein guter Artikel zu Shopware wurde von Roman Zenner auf t3n.de veröffentlicht.

Für Entwickler von Magento-Modulen ist es unerlässlich, die zugrunde liegende Datenbankstruktur und das von Magento verwendete EAV-Model (Entity-Attribute-Value) zu verstehen.

Magento verwendet für Entitäten, also Objekte, eigene Model-Klassen (z.B. Produkte oder Kunden). Jedes dieser Models beinhaltet wiederum Methoden und Attribute (Eigenschaften). Allerdings ist es so, dass Magento die Daten unterschiedlich speichert: Entweder in flachen Tabellen oder eben in EAV-Tabellen. Beispielsweise werden für Produkte EAV-Tabellen verwendet, für Bestellungen wiederum sind flache Tabellen im Einsatz. Doch wo ist nun der Unterschied (man kann sich nämlich beider Modul-Programmierung für eine der beiden Varianten entscheide

EAV-Tabellen

Bei Verwendung des EAV-Schemas, hat man den Vorteil, dass sich die Datenbanktabellen mit einem einzigen Befehle anlegen lassen, ohne dabei auf SQL-Statements zurückgreifen zu müssen. Weiters wird jedes Attribut durch eine eigene Attribut-Model-Klasse repräsentiert. Somit ist es möglich, für das jeweilige Attribut weitere Informationen bereitzustellen bzw. das Rendering zu beeinflussen. Weiters können mittels so genannten Source-Model-Klassen, das sind Unterklassen der Attribut-Model-Klasse, Optionen für Attribute bereitgestellt werden (z.B. Werte für eine Selectbox).

Die Möglichkeiten die das EAV-Schema mit sich bringt haben jedoch auch Nachteile: EAV macht sich durch schlechtere Performance und höheren Speicherverbrauch bemerkbar. Da die Informationen zu einem Attribut über mehrere Tabellen hinweg gespeichert werden, sind umfangreiche Datenbankoperationen notwendig. Auch die Instanzierung der vielen benötigten PHP-Objekte wird zum Ressourcenfresser und fordert somit leistungsstarke Server.

Flache Tabellen

Die so genannten „Flat Tables“ sind dagegen performanter, da die Datenbankstruktur einfach gehalten ist und somit weniger oder keine Joins durchgeführt werden müssen. Hinzu kommt, dass man als Entwickler die Struktur der Datenbank einfacher versteht, da diese beim EAV-Model oft schwer zu durchblicken ist. Ebenso müssen weniger PHP-Objekte instanziert werden.

Allerdings ist beim Einsatz von flachen Tabellen mehr Entwicklungsarbeit notwendig. Beim EAV-Schema wird z.B. die Aufbereitung und Validierung der Daten automatisch vorgenommen, bei flachen Tabellen muss diese Arbeit jedoch vom Programmierer durchgeführt werden. Weiters fehlen bei flachen Tabellen diverse Meta-Informationen, wie etwa ob ein Attribut ein Pflichtfeld ist oder nicht – bei EAV sind diese Informationen von Haus aus vorhanden.

Was soll man nun einsetzen?

Da die Geschwindigkeit eines Online-Shops ein entscheidender Erfolgsfaktor ist, und Magento sowieso keine Vorbild in Sachen Performance ist, sollten meiner Meinung nach in vielen Fällen die flachen Tabellen bevorzugt werden. Um die Entscheidungsfindung einfacher zu machen, hat Vinai Kopp im PHP Magazin (Ausgabe 2.11, Seite 96) folgende Fragen / Aussagen aufgestellt:

• Wieviele Attribute hat die Entität? Viele Attribute verlangsamen EAV noch mehr.
• Wenn im Frontend komplexe Berechnungen für die Entität benötigt werden, dann sollten Flat Tables genommen werden.
• Kommen häufig neue Attribute dazu? Mit EAV sind diese einfacher hinzuzufügen.
• Bei mehr als 2000 Datensätzen sollten flache Tabellen verwendet werden.
• Werden komplexe Backend-Formulare benötigt? Das funktioniert mit EAV etwas weniger gut.

Bei Google Books sind übrigens Teile des Kapitels „Models und Resource-Models“ aus dem Buch „Magento – Das Handbuch für Entwickler“ abzurufen. Darin finden sich weiterführende Informationen zur Datenbankstruktur von Magento und zum Entity-Attribute-Value-Model. Und wer sich nicht selbst mit der Magento-Datenbankstruktur auseinander setzten möchte, findet z.B. bei Twago.de haufenweise PHP-Programmierer und Magento-Experten.

Es tut sich was bei Magento: Nachdem bekannt geworden ist, das eBay 49% von Magento hält, sind auch auf technischer Ebene über Neuigkeiten bzw. Verbesserungen zu berichten.

Die Programmierschnittstellen und Shopping-Funktionen wurden in der kostenlosen Community Edition 1.5 und in den kostenpflichtigen Varianten (Professional und Enterprise) in der Version 1.10 überarbeitet. Erwähnenswert dabei ist, dass nun die Möglichkeit besteht, direkt im Warenkorb die Produkte und Details zu bearbeiten. Weiters wurden der Wunschzettel und die Core-API überarbeitet sowie das Zend Framework auf die Version 1.11 aktualisiert.

Alle weiteren Verbesserungen und Details zu den neuen Versionen sind im Magento Blog nachzulesen.