5

I've got a di.xml that looks something like this

<config>
<type name="Psr\Log\LoggerInterface">                
    <plugin name="namespace_modulename_plugins_psr"
            type="Namespace\Modulename\Plugins\Psr"
            sortOrder="10"
            disabled="false"/>     
</type>
</config>

The Namespace\Modulename\Plugins\Psr class can be instantiated, and has a beforeInfo method defined

public function beforeInfo($subject)
{
    var_dump(__METHOD__);
    exit;
}

However, if I inject a logger and try to use it

/* @var $psr `Psr\Log\LoggerInterface` */
$psr->info("This is a message");

The message will successfully log, but the system does not call my plugin method.

Is there something special about the Psr\Log\LoggerInterface that makes in non-plugin-able? If not, does anyone have a solid methodology for debugging plugin configuration issues?

2 Answers 2

5

After a bit of research, it turns out the Psr\Log\LoggerInterface (and its underlying concrete Monolog implementation class) can be plugged into. The problem was, if you have developer mode enabled you need to do a full di compile (see this bug). Running

php bin/magento setup:di:compile

should get the interceptors generated, and the plugins working.

3

PSR\Log\LoggerInterface is not in magento module or framework folder. So it's not analyzed by compiler and will not be pluginized in production mode. If you want to pluginize/configure behavior of third-party classes, you should use adapter.

5
  • +1 for useful information, but I'm not sure I follow that -- are you saying the plugin system only works with Magento namespaced classes? Does that means that third party modules are also not plugin-able? Also, if it's the compiler that control this wouldn't that mean when running in developer mode the plugin would be applied? Or am I misunderstanding what you mean by compiler? Dec 8, 2015 at 19:49
  • 1
    Expressed myself incorrectly. Compiler collects configuration from module libraries (both magento & 3rd-party), magento framework and generation directories. Interception subsystem works differently in dev mode & in production. In dev mode it tries to read configuration for classes in runtime. For production it reads configuration from files prepared by compiler. So compiler dictates for which files the configuration is available. Updated my answer
    – Anton Kril
    Dec 8, 2015 at 20:00
  • Thank you for the clarification. One last follow up -- based on the behavior I'm seeing it seems like non-production modes also know to skip code that's not part of the module library. Any idea where this skipping happens? (at configuration loading time, instantiation time, etc.) Dec 8, 2015 at 20:18
  • Re: "PSR\Log\LoggerInterface is not in magento module or framework folder. So it's not analyzed by compiler " This is incorrect/incomplete. The Psr\Log\LoggerInterface, if used as a type hint in a Magento classe (which it is) IS analyzed by the compiler. The problem was/is it's an early stage object, and in developer mode its instantiated before the di config is loaded, and then that version is cached in the object manager. See github.com/magento/magento2/issues/2674 Dec 10, 2015 at 19:37
  • Was a surprise for me. I expected that compiled definition would not process unknown type but it's only for arguments. Thanks for investigating correct answer.
    – Anton Kril
    Dec 15, 2015 at 6:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.