Que dois-je faire quand une extension d'une classe à l'échelle mondiale écrase et je veux utiliser l'original?

Question

Nous utilisons une extension qui globalement le bloc écrase de 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>

Alors que l'extension fonctionne dans le contexte d'une catégorie de navigation en couches, la classe réécrite ne fonctionne pas correctement lorsque l'on insère une liste de produits arbitraire dans une autre vue (sur mesure) dans notre propre module en interne. Si nous prenons l'extension Ecraser uniquement à des fins de test, tout fonctionne bien.

Comment peut-on annuler la réécriture d'un poste juste pour notre propre contrôleur, sans modifier le code communautaire du développeur d'extension?

Answer 1

Mises en garde: Il y a moyen de le faire pas conçu ce que vous demandez dans le système. Ce qui suit devrait fonctionner, mais je ne l'ai jamais essayé à de nombreux articles sur un système de production, et il peut y avoir des situations où il causera plus d'ennuis que cela vaut la peine. Avancez seulement si vous avez des problèmes de débogage confortables liés à l'évolution des réécritures d'un système de travail.

L'étape 1 est défait la réécriture. L'arbre de configuration Magento peut être modifiée lors de l'exécution. Donc, si vous exécutez le code suivant

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

Alors Magento instancier le bloc Mage_Catalog_Block_Product_List_Toolbar d'origine pour le reste de la demande.

Étape 2 est de décider où appeler dans votre module. Comme il est juste pour votre contrôleur et il est la réécriture d'un bloc qui ne sera pas instancié jusqu'à la fin de votre commande, j'ajouter une méthode à quelque chose de votre classe contrôleur comme ceci

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

et il suffit d'appeler cette méthode au début de chacune de vos actions

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

Cela peut sembler un peu maladroit, mais je pense que c'est une bonne idée d'être maladroits (à savoir évident) quand vous êtes intelligent avec les objets du système de Magento. Un autre endroit pour cela pourrait être les événements controller_action_predispatch ou controller_action_predispatch_front_controller_action et / ou conditionnelle appliquée.

Rappelez-vous la réécriture ne sera pas annulée jusqu'à ce que cette méthode est appelée. Cela signifie que si vous essayez d'instancier un bloc avant d'appeler _undoRewrites, la classe réécrite sera utilisée pour instancier l'objet.

Answer 2

Solution 1: Vous pouvez essayer de instancier la classe directement (chemin php) dans votre contrôleur

au lieu de

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

quelque chose comme:

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

Solution 2: Une autre approche serait de créer une nouvelle classe, dans votre module, qui étend la classe d'origine et de l'utilisation que l'on.

Solution 3: Dans le cas contraire, si l'extension n'encryptée (que nous aimons tous open source :) vous pouvez essayer de savoir pourquoi il brise vos trucs

Answer 3

Si plusieurs réécritures existent pour le même alias de classe, puis la dernière config les Magento chargeur Parsis de config.xml « gagne ». J'attaque ce problème:

1. Créer une nouvelle extension de votre propre.
2. Réécrire la catalog/product_list_toolbar dans votre extension
3. Demandez à étendre votre bloc Mage_Catalog_Block_Product_List_Toolbar au lieu de la classe Amasty.
4. Généreusement commentaire votre classe en expliquant que ce conflit rewrite est intentionnel. Vous ne voulez pas un autre développeur qui dirige MageRun pour essayer de « régler » le conflit de réécriture que vous venez de créer.
5. Ajouter une dépendance à l'application / etc de votre extension / modules / blah.xml fichier pour vous assurer que votre extension est chargée après une Amasty.

Answer 4

Similaire à ce que Francesco suggéré ci-dessus, mais je crois que vous pouvez passer en fait le nom complet de la classe pour getModel. De cette façon, vous faites un peu toujours la même chose, mais en utilisant des méthodes de base pour le faire. Je ne suis pas tout à fait sûr des avantages / inconvénients de cette méthode, mais je pensais que je jetterais ce là-bas comme une idée.

Mage::getModel('Mage_Catalog_Block_Product_List_Toolbar');

Sur une note de côté, je crois que ce sera le moyen standard pour les classes de charge dans Magento2.

Answer 5

Vous avez besoin de faire un léger changement dans le code d'extension que je crains. Ne pas réécrire la classe dans votre propre config.xml plus, il suffit de changer Amasty_Shopby_Block_Catalog_Product_List_Toolbar pour étendre votre classe qui, à son tour étend Mage_Catalog_Block_Product_List_Toolbar.