Was mache ich, wenn eine Erweiterung eine Klasse global überschreibt und ich das Original verwenden möchte?

Wir verwenden eine Erweiterung, die den Mage_Catalog_Block_Product_List_Toolbar-Block global überschreibt.

<global>
    <blocks>
        <catalog>
            <rewrite>
                <product_list_toolbar>Amasty_Shopby_Block_Catalog_Product_List_Toolbar</product_list_toolbar>
            </rewrite>
        </catalog>
    </blocks>
</global>

Während die Erweiterung im Kontext einer geschichteten Navigationskategorie funktioniert, funktioniert die umgeschriebene Klasse nicht ordnungsgemäß, wenn wir eine beliebige Produktliste in eine andere (benutzerdefinierte) Ansicht in unserem eigenen internen Modul einfügen. Wenn wir die Erweiterung nur zu Testzwecken überschreiben, funktioniert alles einwandfrei.

Wie können wir das Umschreiben einer Erweiterung nur für unseren eigenen Controller rückgängig machen, ohne den Community-Code des Erweiterungsentwicklers zu bearbeiten?

Vorsichtsmaßnahmen: Es gibt keine spezielle Methode, um die Anforderungen des Systems zu erfüllen. Das Folgende sollte funktionieren, aber ich habe es auf einem Produktionssystem noch nie ausgiebig ausprobiert, und es kann Situationen geben, in denen es mehr Probleme verursacht, als es sich lohnt. Fahren Sie nur fort, wenn Sie mit dem Debuggen von Problemen im Zusammenhang mit dem Ändern der Umschreibungen eines funktionierenden Systems vertraut sind.

Schritt 1 macht das Neuschreiben rückgängig. Der Magento-Konfigurationsbaum kann zur Laufzeit geändert werden. Also, wenn Sie den folgenden Code ausführen

$config = Mage::getConfig();        
$config->setNode(
    'global/blocks/catalog/rewrite/product_list_toolbar',
    'Mage_Catalog_Block_Product_List_Toolbar'
);

Dann instanziiert Magento den ursprünglichen Mage_Catalog_Block_Product_List_ToolbarBlock für den Rest der Anfrage.

In Schritt 2 wird entschieden, wo dies in Ihrem Modul aufgerufen werden soll. Da dies nur für Ihren Controller gilt und ein Block neu geschrieben wird, der erst am Ende Ihres Controllers instanziiert wird, füge ich Ihrer Controller-Klasse so etwas wie eine Methode hinzu

protected function _undoRewrites()
{
    $config = Mage::getConfig();        
    $config->setNode(
        'global/blocks/catalog/rewrite/product_list_toolbar',
        'Mage_Catalog_Block_Product_List_Toolbar'
    );    
}

Rufen Sie diese Methode zu Beginn jeder Ihrer Aktionen auf

public function indexAction()
{
    $this->_undoRewrites();
    $test = Mage::getSingleton('core/layout')->createBlock('catalog/product_list_toolbar');        
    var_dump($test);
}

Dies mag etwas klobig erscheinen, aber ich denke, es ist eine gute Idee, klobig (dh offensichtlich) zu sein, wenn Sie mit Magentos Systemobjekten klug sind. Ein anderer Ort dafür könnten die Ereignisse controller_action_predispatchoder sein controller_action_predispatch_front_controller_actionund / oder bedingt angewendet werden.

Denken Sie daran, dass das Umschreiben erst dann rückgängig gemacht wird, wenn diese Methode aufgerufen wird. Das heißt, wenn Sie versuchen, einen Block vor dem Aufruf zu instanziieren _undoRewrites, wird die neu geschriebene Klasse verwendet, um das Objekt zu instanziieren.

Lösung 1:
Sie können versuchen, die Klasse direkt in Ihrem Controller zu instanziieren (PHP-Methode)

Anstatt von

$this->getLayout()->createBlock('catalog/product_list_toolbar');

so etwas wie:

$block = New Magento_Catalog_Product_List_Toolbar;
$this->getLayout()->addBlock(....);

Lösung 2:
Ein anderer Ansatz wäre, in Ihrem Modul eine neue Klasse zu erstellen, die die ursprüngliche Klasse erweitert und diese verwendet.

Lösung 3:
Andernfalls, wenn die Erweiterung nicht verschlüsselt ist (wir alle lieben Open Source :), können Sie herausfinden, warum sie Ihre Inhalte beschädigt

Wenn für denselben Klassenalias mehrere Überschreibungen vorhanden sind, wird die letzte vom Magento-Konfigurationslader aus config.xml "analysiert". Ich würde dieses Problem angreifen, indem ich:

1. Erstellen Sie eine eigene neue Erweiterung.
2. Schreiben Sie die catalog/product_list_toolbarin Ihrer Erweiterung
3. Mage_Catalog_Block_Product_List_ToolbarLassen Sie Ihren Block anstelle der Amasty-Klasse verlängern.
4. Kommentieren Sie Ihre Klasse großzügig und erklären Sie, dass dieser Umschreibungskonflikt beabsichtigt ist. Sie möchten nicht, dass ein anderer Entwickler, der MageRun ausführt, versucht, den soeben erstellten Überschreibungskonflikt zu "beheben".
5. Fügen Sie eine Abhängigkeit in die Datei app / etc / modules / blah.xml Ihrer Erweiterung ein, um sicherzustellen, dass Ihre Erweiterung nach der Amasty geladen wird.

Ähnlich dem, was Francesco oben vorgeschlagen hat, aber ich glaube, Sie können den vollständigen Klassennamen tatsächlich an getModel übergeben. Auf diese Weise machen Sie immer noch das Gleiche, verwenden jedoch die Kernmethoden, um dies zu tun. Ich bin mir nicht ganz sicher, welche Vor- und Nachteile diese Methode hat, aber ich dachte, ich würde das als Idee rausschmeißen.

Mage::getModel('Mage_Catalog_Block_Product_List_Toolbar');

Ich bin der Meinung, dass dies die Standardmethode zum Laden von Klassen in Magento2 sein wird.

Ich fürchte, Sie müssen den Erweiterungscode geringfügig ändern. Schreiben Sie die Klasse nicht config.xmlmehr in Ihrer eigenen um , sondern ändern Sie sie Amasty_Shopby_Block_Catalog_Product_List_Toolbar, um die Klasse zu erweitern, die sich wiederum erweitert Mage_Catalog_Block_Product_List_Toolbar.