Disabled plugins are still being called

[hatimeria-artur-jewula]

When I create a di config in which I want to disable some plugin in given scope the resulted Interceptor still calls the original plugin. For example create a webapi/di.xml in a module with the following content:

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Catalog\Model\ResourceModel\Eav\Attribute">
        <plugin name="save_swatches_option_params" disabled="true"/>
    </type>
</config>

My expectation is that this plugin will not be called when the rest request. However the generated interceptor is

/**
 * {@inheritdoc}
 */
public function beforeSave()
{
    $arguments = func_get_args();
    $this->____plugin_save_swatches_option_params()->beforeBeforeSave($this, ...array_values($arguments));

    return parent::beforeSave(...array_values($arguments));
}

/**
 * {@inheritdoc}
 */
public function afterSave()
{
    $arguments = func_get_args();
    $result = parent::afterSave(...array_values($arguments));

    return (($tmp = $this->____plugin_save_swatches_option_params()->afterAfterSave($this, $result, ...array_values($arguments))) !== null) ? $tmp : $result;
}

[rhoerr]

I also ran into this, where a plugin is defined in global scope but disabled in frontend scope. Still gets compiled and executed by this module unless also disabled in global scope. Smile-SA/elasticsuite#2900

[magneto0007]

Hi @fsw

Has this been resolved ?

Thanks

[fsw]

This issue is still not resolved because I haven't run into it on production so I guess such a configuration (with plugin enabled globally and disabled in scope) happens rarely.

If someone would like to help and fix it here would be my tips:

For reading information about what plugins are enabled in a scope creatuity/magento2-interceptors uses same mechanics magento uses for generating its runtime interceptors (it just changes the generated code).

Issue might be somewhere in this function:

magento2-interceptors/Generator/CompiledPluginList.php

Line 95 in 5d49b94

protected function _loadScopedData()

I would start by debugging this function with creatuity/magento2-interceptors enabled to see what data is being loaded

and then with creatuity/magento2-interceptors disabled, debug if native magento mechanism (Magento\Framework\Interception\PluginList\PluginList, Magento\Framework\Interception\PluginListGenerator) generates same data when interceptors are beeing generated.

[jambardnishvili]

I've picked up this issue but for some reason are not able to replicate this. my test scenario.

Magento 2.4.7-p3 installation.

Create a controller in for example Vendor/Testing module with path, /testing/index/index.

Create a plugin for this controller named 'add_test_message' in Vendor/PluginTesting module in the global scope etc/di.xml
In the same module disable this plugin in the frontend scope, etc/frontend/di.xml

Result is that this plugin is not called anymore when accessing /testing/index/index, which is the correct behaviour.

Below is the generated interceptor for the controller. i can see ____plugin_add_test_message is not in the default: section so this plugin is not triggered for the current 'frontend' scope.

Maybe someone can point me to reproducing this issue.

    public function execute() : \Magento\Framework\View\Result\Page
    {
        switch ($this->____scope->getCurrentScope()) {
        	case 'global':
        	case 'adminhtml':
        	case 'graphql':
        	case 'crontab':
        	case 'webapi_rest':
        	case 'webapi_soap':
        	case 'primary':
        		$arguments = \func_get_args();
        		$this->____plugin_storeCheck()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_designLoader()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_customerNotification()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_add_test_message()->beforeExecute($this, ...\array_values($arguments));
        		
        		return parent::execute(...\array_values($arguments));
        	default:
        		$arguments = \func_get_args();
        		$this->____plugin_storeCheck()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_designLoader()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_customerNotification()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_invalidate_expired_session_plugin()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_tax_app_action_dispatchController_context_plugin()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_weee_app_action_dispatchController_context_plugin()->beforeExecute($this, ...\array_values($arguments));
        		
        		$this->____plugin_customer_app_action_executeController_context_plugin()->beforeExecute($this, ...\array_values($arguments));
        		
        		return parent::execute(...\array_values($arguments));
        }
    }

[fsw]

@jambardnishvili thanks a lot,

I am not sure if frontend/default are a special case so You can also disable this plugin in another scope (for example webapi) and check if this switch will generate with 3 different cases.

But indeed as plugin info is fetched using magento source it is possible that this was happening on older magento versions.

[rhoerr]

That's great, thanks @jambardnishvili and @fsw. It's very possible this was a core bug or conflict since resolved, then. I haven't seen it come up in the last ~1.5 years. The case I mentioned in my last note was definitely frontend scope, so I don't think that's a special case.

Unless anyone else has seen it, maybe we can close this out. Or try to reproduce it on 2.4.4 (although if it is a core bug, that's out of scope of this module and also rare enough to disregard, IMO).

[salvop85b]

Hi, we have encountered the same issue with Adobe Commerce 2.4.6-p8. A plugin declared as global but deactivated on the frontend (without specifying the type attribute) remained active. Through testing, we noticed that the error occurs only if there is only one plugin for the class.

For example:

/vendor/magento/module-enterprise/etc/di.xml

<type name="Magento\Theme\Model\Favicon\Favicon">
        <plugin name="enterprise_favicon" type="Magento\Enterprise\Model\Plugin\Favicon"/>
    </type>

/app/code/Vendor/Module/etc/frontend/di.xml

<type name="Magento\Theme\Model\Favicon\Favicon">  
    <plugin name="enterprise_favicon" disabled="true" />  
</type>

Interceptor:

public function getDefaultFavicon()  
{  
    $arguments = \func_get_args();  
    $result = parent::getDefaultFavicon(...\array_values($arguments));  
  
    return (($tmp = $this->____plugin_enterprise_favicon()->afterGetDefaultFavicon($this, $result, ...\array_values($arguments))) !== null) ? $tmp : $result;  
}