Co mam zrobić, gdy rozszerzenie globalnie nadpisuje klasę i chcę użyć oryginału?

Używamy rozszerzenia, które globalnie zastępuje blok Mage_Catalog_Block_Product_List_Toolbar.

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

Podczas gdy rozszerzenie działa w kontekście warstwowej kategorii nawigacji, przepisana klasa nie działa poprawnie, gdy wstawimy dowolną listę produktów do innego (niestandardowego) widoku w naszym własnym module wewnętrznym. Jeśli wyjmujemy nadpisywanie rozszerzenia tylko do celów testowych, wszystko działa dobrze.

Jak możemy cofnąć przepisywanie rozszerzenia tylko dla naszego własnego kontrolera, bez edytowania kodu społeczności programisty rozszerzenia?

Ostrzeżenia: Nie ma specjalnie zaprojektowanego sposobu na wykonanie tego, o co prosisz w systemie. Następujące elementy powinny działać, ale nigdy nie wypróbowałem tego szeroko na systemie produkcyjnym, i mogą wystąpić sytuacje, w których spowoduje to więcej problemów, niż jest to warte. Kontynuuj tylko, jeśli nie masz problemów z debugowaniem związanych ze zmianą przepisywania działającego systemu.

Krok 1 polega na cofnięciu przepisywania. Drzewo konfiguracji Magento można zmienić w czasie wykonywania. Jeśli uruchomisz następujący kod

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

Następnie Magento utworzy oryginalny Mage_Catalog_Block_Product_List_Toolbarblok dla pozostałej części żądania.

Krok 2 decyduje, gdzie wywołać to w swoim module. Ponieważ jest to tylko dla twojego kontrolera i przepisuje blok, który nie zostanie utworzony do końca twojego kontrolera, dodałbym metodę do twojej klasy kontrolera coś takiego

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

a następnie po prostu wywołaj tę metodę na początku każdej akcji

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

To może wydawać się trochę niezręczne, ale myślę, że dobrym pomysłem jest być niezręcznym (tj. Oczywistym), gdy jesteś sprytny z obiektami systemowymi Magento. Innym miejscem tego mogą być zdarzenia controller_action_predispatchlub controller_action_predispatch_front_controller_actionzdarzenia i / lub stosowane warunkowo.

Pamiętaj tylko, że przepisywanie nie zostanie cofnięte, dopóki ta metoda nie zostanie wywołana. Oznacza to, że jeśli spróbujesz utworzyć blok przed wywołaniem _undoRewrites, do przepisania obiektu zostanie użyta zmieniona klasa.

Rozwiązanie 1:
Możesz spróbować utworzyć instancję klasy bezpośrednio (sposób php) w ​​kontrolerze

zamiast

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

coś jak:

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

Rozwiązanie 2:
Innym podejściem byłoby utworzenie nowej klasy w module, która rozszerzy klasę oryginalną i skorzystanie z niej.

Rozwiązanie 3:
W przeciwnym razie, jeśli rozszerzenie nie jest szyfrowane (wszyscy uwielbiamy open source :) możesz spróbować dowiedzieć się, dlaczego to psuje twoje rzeczy

Jeśli istnieje wiele przeróbek dla tego samego aliasu klasy, to ostatni moduł ładujący konfigurację Magento analizuje z pliku config.xml „wygrywa”. Zaatakowałbym ten problem przez:

1. Utwórz własne rozszerzenie.
2. Przepisz catalog/product_list_toolbarw swoim rozszerzeniu
3. Niech twój blok zostanie przedłużony Mage_Catalog_Block_Product_List_Toolbarzamiast klasy Amasty.
4. Swobodnie komentuj swoją klasę, wyjaśniając, że ten konflikt przepisywania jest celowy. Nie chcesz, aby inny programista, który uruchamia MageRun, próbował „naprawić” właśnie utworzony konflikt przepisywania.
5. Dodaj zależność w pliku aplikacji / etc / modules / blah.xml rozszerzenia, aby mieć pewność, że rozszerzenie zostanie załadowane po Amasty.

Podobne do tego, co sugerował Francesco powyżej, ale wierzę, że możesz przekazać pełną nazwę klasy, aby uzyskać getModel. W ten sposób nadal robisz to samo, ale używasz do tego podstawowych metod. Nie jestem całkowicie pewien zalet / wad tej metody, ale pomyślałem, że przedstawię to jako pomysł.

Mage::getModel('Mage_Catalog_Block_Product_List_Toolbar');

Na marginesie, uważam, że będzie to standardowy sposób ładowania klas w Magento2.

Obawiam się, że musisz wprowadzić niewielką zmianę w kodzie rozszerzenia. Nie przepisuj już klasy we własnym zakresie config.xml, po prostu zmień, Amasty_Shopby_Block_Catalog_Product_List_Toolbaraby rozszerzyć klasę, która z kolei się wydłuży Mage_Catalog_Block_Product_List_Toolbar.