Plugin Ordering — Sort Order, Conflicts, and Resolution

How sortOrder Works

Plugins with lower sortOrder execute first:

<type name="Magento\Catalog\Model\Product">
    <plugin name="first" type="Vendor\A\Plugin\A" sortOrder="10"/>
    <plugin name="second" type="Vendor\B\Plugin\B" sortOrder="20"/>
    <plugin name="third" type="Vendor\C\Plugin\C" sortOrder="30"/>
</type>

Execution for getName():

A::beforeGetName -> B::beforeGetName -> C::beforeGetName
  -> Product::getName()
C::afterGetName -> B::afterGetName -> A::afterGetName

Before plugins: ascending sortOrder
After plugins: descending sortOrder (LIFO)

Default sortOrder

If no sortOrder is specified, plugins execute in config merge order:

<!-- These run in unpredictable order -->
<plugin name="a" type="Vendor\A\Plugin\A"/>
<plugin name="b" type="Vendor\B\Plugin\B"/>

Always specify sortOrder for predictable behavior.

sortOrder Ranges

Around Plugins Stack

Around plugins nest like layers:

<type name="Magento\Catalog\Model\Product">
    <plugin name="outer" type="Vendor\Outer\Plugin" sortOrder="10"/>
    <plugin name="inner" type="Vendor\Inner\Plugin" sortOrder="20"/>
</type>

Execution:

outer::aroundGetName {
    inner::aroundGetName {
        Product::getName()
    }
}

Around + Before/After Mixing

<type name="Magento\Catalog\Model\Product">
    <plugin name="around_1" type="Vendor\Around1" sortOrder="10"/>
    <plugin name="before_1" type="Vendor\Before1" sortOrder="15"/>
    <plugin name="around_2" type="Vendor\Around2" sortOrder="20"/>
    <plugin name="before_2" type="Vendor\Before2" sortOrder="25"/>
</type>

Execution:

around_1::around {
    around_2::around {
        before_2::before
        before_1::before
        Product::getName()
        before_1::after
        before_2::after
    }
    around_2::after
}
around_1::after

Around plugins at lower sortOrder wrap the entire inner chain.

Common Conflict Scenario

Two modules plugin the same method with conflicting logic:

// Vendor A: converts name to uppercase
public function afterGetName($subject, $result) {
    return strtoupper($result);
}

// Vendor B: adds prefix
public function afterGetName($subject, $result) {
    return 'Product: ' . $result;
}

Result depends on sortOrder. If A=10, B=20:

1. Original: "Widget"
2. A after (sortOrder 10): "WIDGET" (after runs in reverse)
3. B after (sortOrder 20): "Product: WIDGET"

Disabling Conflicting Plugins

<type name="Magento\Catalog\Model\Product">
    <plugin name="conflicting_plugin" disabled="true"/>
</type>

Using di.xml Override Pattern

<!-- Module A di.xml -->
<type name="Magento\Catalog\Model\Product">
    <plugin name="module_a_plugin" type="Vendor\A\Plugin" sortOrder="10"/>
</type>

<!-- Module B di.xml - can override via plugin name -->
<type name="Magento\Catalog\Model\Product">
    <plugin name="module_a_plugin" disabled="true"/>
    <plugin name="module_b_better" type="Vendor\B\Plugin" sortOrder="10"/>
</type>

Conflict Resolution Strategies

1. Use specific sortOrder values to control order
2. Disable conflicting plugins from other modules
3. Use around plugins to wrap and modify behavior
4. Check for existing plugins before implementing
5. Document plugin sort order in README

Inspecting Plugin Configuration

$objectManager = \Magento\Framework\App\ObjectManager::getInstance();
$config = $objectManager->get(\Magento\Framework\Interception\Config\ConfigInterface::class);
$plugins = $config->getPlugins('Magento\Catalog\Model\Product');
print_r($plugins);

Plugin Profiling

public function aroundGetName($subject, callable $proceed)
{
    $start = microtime(true);
    $result = $proceed();
    $elapsed = microtime(true) - $start;
    $this->logger->info(static::class . '::getName: ' . round($elapsed, 4) . 's');
    return $result;
}

CLI Debug Commands

# List plugins for a class
php bin/magento dev:di:info Magento\\Catalog\\Model\\Product

# Check generated interceptor
cat var/classes/Magento/Catalog/Model/ProductInterceptor.php

# Verify plugin configuration
php bin/magento setup:di:compile -vvv

Common Issues