SELECT * FROM catalog_product_entity_int LIMIT 2;
+----------+----------------+--------------+----------+-----------+-------+
| value_id | entity_type_id | attribute_id | store_id | entity_id | value |
+----------+----------------+--------------+----------+-----------+-------+
|        1 |             10 |          272 |        0 |        16 |     0 |
|        2 |             10 |          272 |        0 |        16 |     1 |
+----------+----------------+--------------+----------+-----------+-------+

Das Attribut mit der ID 272 ist also für das Produkt doppelt belegt, einmal mit dem Wert 0 und einmal mit dem Wert 1 (man hat aber auch das selbe Problem, wenn die Werte gleich sind).

Um die problematischen Werte zu finden, helfen folgende SQL Zeilen um Duplikate in den catalog_product_entity_… Tabellen zu finden:

SELECT eav_table.* FROM catalog_product_entity_int AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;
SELECT eav_table.* FROM catalog_product_entity_varchar AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;
SELECT eav_table.* FROM catalog_product_entity_text AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;
SELECT eav_table.* FROM catalog_product_entity_datetime AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;
SELECT eav_table.* FROM catalog_product_entity_decimal AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;

Um dann die doppelten Werte zu löschen (vorher bitte unbedingt anschauen, was doppelt ist und ob es Widerspüchlichkeiten gibt):

DELETE FROM catalog_product_entity_int WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_int GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);
DELETE FROM catalog_product_entity_varchar WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_varchar GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);
DELETE FROM catalog_product_entity_text WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_text GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);
DELETE FROM catalog_product_entity_datetime WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_datetime GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);
DELETE FROM catalog_product_entity_decimal WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_decimal GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);

Die eigentliche Frage ist, wie man überhaupt zu so einer EAV-Struktur kommen konnte. Das kann eigentlich nicht passieren, denn es gibt einen Unique-Index über die Felder (attribute_id, entity_id, store_id). Per SQL kann man diese aber über mit “SET  UNIQUE_CHECKS=0″ umgehen, was zum Beispiel am Anfang eines phpMyAdminDumps immer gemacht wird. Der “Trick” wird auch von eingen Extensions benutzt, um schneller in die Datenbank zu schreiben.

Das ganze ist möglich weil Magento in Mage_Core_Controller_Varien_Action in der Methode dispatch ein Flag abfragt ob es überhaupt einen Dispatch geben soll.

//Mage_Core_Controller_Varien_Action->dispatch()
...
if ($this->getRequest()->isDispatched()) {
    /**
     * preDispatch() didn't change the action, so we can continue
     */
    if (!$this->getFlag('', self::FLAG_NO_DISPATCH)) {
        $_profilerKey = self::PROFILER_KEY.'::'.$this->getFullActionName();
        Varien_Profiler::start($_profilerKey);
        $this->$actionMethodName();
        Varien_Profiler::stop($_profilerKey);
        Varien_Profiler::start(self::PROFILER_KEY.'::postdispatch');
        $this->postDispatch();
        Varien_Profiler::stop(self::PROFILER_KEY.'::postdispatch');
    }
}
...

Setzt man nun diesen Flag in Controller oder sonst wo, dann wird Magento nicht die Action des Controller ausführen. Damit war ich meinem Ziel schon etwas näher.
Aber wie kann ich mich in eine beliebige Controller Action einhängen? Auch hier bietet Magento einen Hook. Dieser befindet sich ebenfalls in Mage_Core_Controller_Varien_Action, aber dieses mal in der Methode preDispatch. Dort werden verschiede Events geworfen und das zu einem sehr frühen Zeitpunkt in Request-Response Zyklus von Magento. Erst dadurch ist es möglich eine Action vollständig zu überschreiben.

Mage::dispatchEvent('controller_action_predispatch', array('controller_action'=>$this));
Mage::dispatchEvent(
    'controller_action_predispatch_'.$this->getRequest()->getRouteName(),
    array('controller_action'=>$this)
);
Varien_Autoload::registerScope($this->getRequest()->getRouteName());
Mage::dispatchEvent(
    'controller_action_predispatch_'.$this->getFullActionName(),
    array('controller_action'=>$this)
);

Wie ihr seht werden hier viele verschiedene Events gefeuert. Ich kann einfach auf alle Controller preDispatches hören oder auch nur auf bestimmte. Zur Demonstration habe ich einfach mal alle Actions überschrieben.

//XML in aus der Config XML eines Moduls
<controller_action_predispatch>
  <observers>
    <updateflags>
      <type>singleton</type>
      <class>magelog_teaser/observer</class>
      <method>stopAction</method>
    </updateflags>
  </observers>
</controller_action_predispatch>

Die Methode im Oberserver macht nichts anderes als ein Hello in die Response zu schreiben. Will man nun eine Methode im Checkout überschreiben, ersetzt man das Hello durch eine JSON Rückgabe und wählt den Event weniger allgemein.

public function stopAction(Varien_Event_Observer $observer) {
        //controller aus dem event laden
        /** @var $controller Mage_Core_Controller_Varien_Action */
        $controller = $observer->getData('controller_action');
        //hier passiert die Magie, und wird der Dispatch unterbrochen
        $controller->setFlag(
             $controller->getRequest()->getActionName()
             ,Mage_Core_Controller_Varien_Action::FLAG_NO_DISPATCH
             ,true
         );
        //jetzt kann man beliebigen Output erzeugen
        $controller->getResponse()->setBody("Hello");
}

Viel Spaß damit und ich werde berichten wie weit wir dieses Konzept in unserem neuen Checkout getrieben haben. Ach ja, das ganze hat bei uns auch schon einen Namen: “Das schöne Magento die()”.

Ich hatte mich bei der Entwicklung auch gefragt warum in Magento 1.5 es nicht mehr erlaubt ist Category zu löschen, wenn man nicht im Backend eingelogt ist. Gibt es da einen Zusammenhang? Ich weiß es leider nicht, aber vielleicht ihr.

Ich konnte das Problem auch nicht mit MySQL-Mitteln lösen.

Code aus Magento 1.5.1.0:

    protected function _loadDbTranslation($forceReload = false)
    {
        $arr = $this->getResource()->getTranslationArray(null, $this->getLocale());
        $this->_addData($arr, $this->getConfig(self::CONFIG_KEY_STORE), $forceReload);
        return $this;
    }

Code aus Magento 1.3.2.4. Man beachte den fehlenden Locale Parameter bei getTranslationArray().

    protected function _loadDbTranslation($forceReload = false)
    {
        $arr = $this->getResource()->getTranslationArray();
        $this->_addData($arr, $this->getConfig(self::CONFIG_KEY_STORE), $forceReload);
        return $this;
    }

PHP Fatal error:  Uncaught exception ‘PDOException’ with message ‘SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘core_file_storage’ doesn’t exist’.

Nach ein wenig suchen im Magento Core ist mir aufgefallen, dass diese Tabellen “on the fly” anlegt werden. Jedoch nur wenn die Datenbank als Cache-Backend verwendet wird. Der Fehler hat bei mir nur das Log voll geschrieben. Der Shop war nicht beeinträchtigt.

Die Lösung ist folgender Schnippsel:

/** @var $model Mage_Core_Model_File_Storage_Directory_Database */
$model = Mage::getModel('core/file_storage_directory_database');
$model->prepareStorage();
/** @var $model Mage_Core_Model_File_Storage_Database */
$model = Mage::getModel('core/file_storage_database');
$model->prepareStorage();

Wichtig ist dabei die Reihenfolge! Die zweite Tabelle erstellt Foreign Keys auf die erste. Das ganze habe ich in ein Update Script eines der Module gepackt und nun werden sie einfach einmalig erstellt.

Ich habe gerade dieses Design auf dem Tisch. Eine Produktliste, oben eine Toolbar mit Sortieroptionen, unten eine Toolbar mit Pager, bestimmt kein Problem: Die Template-Engine von Magento ist doch wie gemacht für so etwas.

Schauen wir mal ins Template:

<div class="category-products">
<?php echo $this->getToolbarHtml(); ?>
... Produktlisten-Ausgabe ...
<?php echo $this->getToolbarHtml(); ?>
</div>

Die Nicht-Lösung

$this->getToolbarHtml() ruft lediglich $this->getChildHtml(‘toolbar’) auf, also werde ich einfach zwei Mage_Catalog_Block_Product_List_Toolbar-Blöcke mit verschiedenen Templates erstellen und mit $this->getChildHtml(‘product_list_toolbar’) und $this->getChildHtml(‘product_list_toolbar2′) ins Template einfügen, à la:

...
<catalog_category_default>
<reference name="content">
<block type="catalog/category_view" name="category.products" template="catalog/category/view.phtml">
<block type="catalog/product_list" name="product_list" template="catalog/product/list.phtml">
<block type="catalog/product_list_toolbar" name="product_list_toolbar" template="catalog/product/list/toolbar-sort.phtml" >
<block type="page/html_pager" name="product_list_toolbar_pager"/>
</block>
<block type="catalog/product_list_toolbar" name="product_list_toolbar2" template="catalog/product/list/toolbar-pager.phtml"/>
<block type="page/html_pager" name="product_list_toolbar_pager"/>
</block>
</block>
</block>
</reference>
...
</catalog_category_default>
...

Super Lösung, ausser, dass sie nicht funktioniert: Die Toolbar wird gesondert behandelt, in Mage_Catalog_Block_Product_List_Toolbar::_beforeToHtml() wird der Toolbar-Block on the fly unter dem Name “toolbar” erstellt, mit den nötigen Daten (der Produkt-Collection und den Pager- und Sortieroptionen) befüllt und dann erst gerendert.

Die Lösung: 2 verschiedene Toolbar-Templates?

Die obere Toolbar behandeln wir einfach wie von Magento gedacht, sie wird per $this->getToolbar() in das Template eingefügt, dafür müssen wir im Layout-XML noch den Toolbar-Block-Namen registrieren:

...
<catalog_category_default>
<reference name="content">
<block type="catalog/category_view" name="category.products" template="catalog/category/view.phtml">
<block type="catalog/product_list" name="product_list" template="catalog/product/list.phtml">
<block type="catalog/product_list_toolbar" name="product_list_toolbar" template="catalog/product/list/toolbar-sort.phtml">
<block type="page/html_pager" name="product_list_toolbar_pager"/>
</block>
<action method="setToolbarBlockName"><name>product_list_toolbar</name></action>
<block type="catalog/product_list_toolbar" name="product_list_toolbar2" template="catalog/product/list/toolbar-pager.phtml">
<block type="page/html_pager" name="product_list_toolbar_pager"/>
</block>
</block>
</block>
</reference>
...
</catalog_category_default>
...

Ausserdem haben wir eine weiteren Toolbar-Block unter dem Namen “product_list_toolbar2″ im XML angelegt. Damit wir diesen benutzen können, muss der Block aus dem PHP-Template heraus per $this->setToolbarBlockName(‘product_list_toolbar2′) als der Toolbar-Block registriert und per “$this->_beforeToHtml()” mit Daten befüllt werden.
Für die eigentlich Ausgabe kann dann $this->getChildHtml(‘toolbar’,false) aufgerufen werden, der zweite Parameter bewirkt, dass der Block-Cache umgangen wird (im Cache ist sonst noch die obere Toolbar hinterlegt):

<?php
$this->setToolbarBlockName('product_list_toolbar2');
$this->_beforeToHtml();
echo $this->getChildHtml('toolbar',false);
?>

ich bin nicht so wirklich zufrieden mit der Lösung: Gut ist, dass sie funktioniert, schlecht ist, dass sie den Layout-XML-Mechanismus und das Block-Caching umgeht, das Template vollmüllt, und es evtl. Seiteneffekte durch den doppelten Aufruf von _beforeToHtml() gibt.

Kennt jemand einen besseren Ansatz?

$quote = Mage::getModel('sales/quote')->getCollection()->getItemById($quote_id);

harmlos, oder? Nein!

Diese eine Zeile brauchte ca. 30 Sekunden, und das auf einem wirklich performanten Kundenserver.
Wie kommt’s?

In lib/Varien/Data/Collection.php finden wir folgendes:

    /**
     * Retrieve item by id
     *
     * @param   mixed $idValue
     * @return  Varien_Object
     */
    public function getItemById($idValue)
    {
        $this->load();
        if (isset($this->_items[$idValue])) {
            return $this->_items[$idValue];
        }
        return null;
    }

Zuerst wird die gesamte Collection geladen, und dann per Array-Lookup das richtige Element zurückgegeben. Die gesamte Collection laden bedeutete in diesem Fall 50.000 Quotes aus der Datenbank abholen, 50.000 mal den Konstruktor der Klasse aufrufen, und dann den EINEN verdammten Eintrag zurückgeben.
Wir haben diese Zeile dann durch das gute alte Mage::getModel(‘sales/quote’)->load($id) ersetzt und konnten so die Performance um den Faktor 50.000 erhöhen;)
Ich frage mich was die Idee hinter dieser Methode ist und warum eine dermaßen nicht skalierende Methode überhaupt im Magento-Core vorhanden ist. Oder gibt es da vernünftige Einsatzbereiche?

/**
 * Return translated string from text.
 *
 * @param string $text
 * @param string $code
 * @return string
 */
 protected function _getTranslatedString($text, $code)
 {
   $translated = '';
   if (array_key_exists($code, $this->getData())) {
     $translated = $this->_data[$code];
   }
   elseif (array_key_exists($text, $this->getData())) {
     $translated = $this->_data[$text];
   }
   else {
     $translated = $text;
     // THE LINE THAT SAVES THE DAY FOLLOWS:
     Mage::log('UNTRANSLATED STRING: "'.$code.' - '.$text.'"');
     // THAT WAS THE LINE THAT SAVED THE DAY
   }
   return $translated;
}

und anschliessend sich die fehlenden Übersetzungen per

grep 'UNTRANSLATED STRING' var/log/system.log

anzeigen lassen.

Vielleicht gibt es das später auch noch mal in schön, mal sehen…

Die Autovervollständigung der IDE

Meistens funktioniert die Autovervollständigung bei der Magento-Entwicklung ja recht gut, wenn ich z.B. in einem eigenen Controller

$this->getRequest()->getP[CTRL+SPACE]

tippe, schlägt mir netbeans, wie es sich gehört,

$this->getRequest()->getParam($key, $default);

vor.

und wo sie versagt:

Das funktioniert aber nicht immer: Wenn netbeans den Kontext, in dem ich mich befinde nicht analysieren kann, gibt es keine ober nur sehr allgemeine Vorschläge:

$product = Mage::getModel('catalog/product');
$product->get [CTRL+SPACE]

liefert magere 13 Möglichkeiten, obwohl es weitaus mehr Methoden in der Klasse Mage_Catalog_Model_Product gibt, wie man sich schnell mit einem Blick in den Sourcecode überzeugen kann. Netbeans erkennt am Rückgabewert der Methode getModel(), dass es sich bei der zurückgegebenen Instanz um eine von Mage_Core_Model_Abstract abgeleitete Klasse handelt, welche aber genau, kann Netbeans natürlich nicht ableiten.

Type-Hints for the rescue

Hier helfen wir mit einem Type-Hint-Kommentar nach. Type-Hint-Kommentare sind eine spezielle PHPDoc-Syntax um den Typ einer lokalen Variablen explizit anzugeben.

Der äußerst gewünschte Nebeneffekt ist, dass Netbeans nun auf Basis des angegebenen Typs die Autovervollständigung generiert:

$product = Mage::getModel('catalog/product');
/* @var $product Mage_Catalog_Model_Product */
$product->get [CTRL+SPACE]

Und tada: Netbeans weiss, was wir wollen!

Templates schreiben lassen

Noch viel nützlicher ist die Methode bei der Magento-Template-Erstellung: Hier haben die Magento-Entwickler ja beinahe mitgedacht, und haben meistens oben im Template das zugehörige Block-Model in einem @see-Kommentar notiert. Wenn man in einem Template gerade nicht weiss, welche Methoden, einem zur Verfügung stehen, ergänzte man einfach den @see-Kommentar um einen Type-Hint-Kommentar. Dass die gehintete Variable zufällig $this ist, stört Netbeans nicht weiter:

<?php
/**
* Shopping cart template
*
* @see Mage_Checkout_Block_Cart
*/
/* @var $this Mage_Checkout_Block_Cart */
?>
<div>
<h3><?php echo $this->getQ [CTRL+SPACE] ?></h3>
// ...

Fazit

Den minimalen zusätzlichen Aufwand, lokale Variablen zu kommentieren, hat man spätestens nach dem zweiten Editieren der Datei wieder raus. Außerdem hilft der Type-Hint nicht nur der Entwicklungsumgebung, sondern auch dem Entwickler, den Überblick zu behalten.

Also: Machen! Immer!

<resources>
 <db>
 <table_prefix><![CDATA[]]></table_prefix>
 </db>
 <default_setup>
 <connection>
 <host><![CDATA[localhost]]></host>
 <username><![CDATA[root]]></username>
 <password><![CDATA[]]></password>
 <dbname><![CDATA[magento_test]]></dbname>
 <active>1</active>
 <profiler>1</profiler>
 </connection>
 </default_setup>
 </resources>

Nachdem man einmal den Cache gelöscht hat erscheint unterhalb des regulären Profilers ein neuer Bereich mit ein paar wenigen Infos, unter anderem wird auch die langsamste SQL-Query ausgegeben. Wie nützlich das in der Praxis ist muss man sehen, wem die Ausgabe zu langweilig ist, der kann sich per

$profiler = Mage::getSingleton('core/resource')->getConnection('core_write')->getProfiler();

auch das ganze Zend_Db_Profiler – Objekt mit allen SQL-Queries und Laufzeiten heranholen und die Infos selber besser aufbereiten, z.B im einfachsten Fall so

print_r($profiler->getQueryProfiles());