¿Qué hago cuando una extensión sobrescribe una clase globalmente y quiero usar el original?

Estamos utilizando una extensión que sobrescribe globalmente el bloque 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>

Si bien la extensión funciona en el contexto de una categoría de navegación en capas, la clase reescrita no funciona correctamente cuando insertamos una lista de productos arbitraria en otra vista (personalizada) en nuestro propio módulo interno. Si eliminamos la sobrescritura de la extensión solo con fines de prueba, todo funciona bien.

¿Cómo podemos deshacer la reescritura de una extensión solo para nuestro propio controlador, sin editar el código de comunidad del desarrollador de la extensión?

Advertencias: No hay una forma diseñada para hacer lo que está pidiendo en el sistema. Lo siguiente debería funcionar, pero nunca lo he probado exhaustivamente en un sistema de producción, y puede haber situaciones en las que cause más problemas de lo que vale. Solo proceda si se siente cómodo depurando problemas relacionados con el cambio de reescrituras de un sistema de trabajo.

El paso 1 es deshacer la reescritura. El árbol de configuración de Magento se puede cambiar en tiempo de ejecución. Entonces, si ejecuta el siguiente código

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

Entonces Magento creará una instancia del Mage_Catalog_Block_Product_List_Toolbarbloque original para el resto de la solicitud.

El paso 2 es decidir dónde llamar a esto en su módulo. Dado que esto es solo para su controlador y está reescribiendo un bloque que no se instanciará hasta el final de su controlador, agregaría un método a su clase de controlador algo como esto

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

y luego simplemente llame a este método al comienzo de cada una de sus acciones

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

Esto puede parecer un poco torpe, pero creo que es una buena idea ser torpe (es decir, obvio) cuando se es inteligente con los objetos del sistema de Magento. Otro lugar para esto podría ser los eventos controller_action_predispatcho controller_action_predispatch_front_controller_actiony / o aplicados condicionalmente.

Solo recuerde que la reescritura no se deshará hasta que se llame a este método. Eso significa que si intenta crear una instancia de un bloque antes de llamar _undoRewrites, la clase reescrita se usará para crear una instancia del objeto.

Solución 1:
puede intentar crear una instancia de la clase directamente (forma php) en su controlador

en lugar de

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

algo como:

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

Solución 2:
Otro enfoque sería crear una nueva clase, en su módulo, que extienda la clase original y use esa.

Solución 3: de lo
contrario, si la extensión no está encriptada (a todos nos encanta el código abierto :), puede intentar averiguar por qué rompe sus cosas

Si existen varias reescrituras para el mismo alias de clase, entonces la última que el cargador de configuración de Magento analiza desde config.xml "gana". Atacaría este problema al:

1. Crea una nueva extensión propia.
2. Reescribe el catalog/product_list_toolbaren tu extensión
3. Haga que su bloqueo se extienda en Mage_Catalog_Block_Product_List_Toolbarlugar de la clase Amasty.
4. Comenta liberalmente tu clase explicando que este conflicto de reescritura es intencional. No desea que otro desarrollador que ejecuta MageRun intente "arreglar" el conflicto de reescritura que acaba de crear.
5. Agregue una dependencia en el archivo app / etc / modules / blah.xml de su extensión para asegurarse de que su extensión se cargue después de Amasty.

Similar a lo que sugirió Francesco anteriormente, pero creo que en realidad puedes pasar el nombre completo de la clase a getModel. De esta manera, de alguna manera sigues haciendo lo mismo, pero usando métodos básicos para hacerlo. No estoy completamente seguro de los pros / contras de este método, pero pensé que lo lanzaría como una idea.

Mage::getModel('Mage_Catalog_Block_Product_List_Toolbar');

En una nota al margen, creo que esta será la forma estándar de cargar clases en Magento2.

Necesito hacer un ligero cambio en el código de extensión, me temo. No reescriba la clase en la suya config.xml, solo cámbiela Amasty_Shopby_Block_Catalog_Product_List_Toolbarpara extender su clase que a su vez se extiende Mage_Catalog_Block_Product_List_Toolbar.