4

I have a module that has errors when compiling.

I am disabling it via cli: magento module:disable Aheadworks_Layerednav.

Then magento module:status shows the module as disabled. Cleared cache, removed everything from var folder.

But then when I run magento setup:di:compile I get Errors during compilation:

    Aheadworks\Layerednav\Block\Navigation
        Incorrect dependency in class Aheadworks\Layerednav\Block\Navigation in /data/web/public/app/code/Aheadworks/Layerednav/Block/Navigation.php
\Magento\Store\Model\StoreManagerInterface already exists in context object

My expectation was that disabled modules aren't compiled.

1 Answer 1

1

@claudiu Creanga it looks like if you rename or remove your registration.php that when you run the module:status command after running module:disable Your_Module, the module doesn't show up in the "List of disabled modules". Then if you run setup:di:compile you won't see any errors, if there are any, for that module.

UPDATE: I was focusing on the di compilation and not focusing on the error message you shared. Your solution is here: http://magento-quickies.alanstorm.com/post/138686669515/quick-note-on-already-exists-in-context-object . Your problem doesn't have anything to do with a module not being disabled. It's a matter of doubly injecting an interface.

  1. Looks like you'll want to go to your /data/web/public/app/code/Aheadworks/Layerednav/Block/Navigation.php class
  2. Look for the StoreManagerInterface being passed as an argument to your constructor and remove that and the comma from the line above (if there is one)
  3. Then, in the body of the constructor, there will probably be something like $this->_storeManager = $storeManager or $this->_storeManagerInterface = $storeManagerInterface (I don't have the extension, so I can't give you an exact answer; But if you'd like to post your code I can show you exactly what to change); Make sure you're assigning $this->_storeManager = $context->getStoreManager() instead of an instance of the StoreManagerInterface

If you check Magento\Framework\View\Element\Template\Context class you'll see the getStoreManager() method, which returns an instance of \Magento\Store\Model\StoreManagerInterface, therefore the error you're seeing is Magento telling you that this StoreManagerInterface is already available, so no need to inject it into the Navigation block's constructor.

One of the things that intrigued me from Alan's article, was that these errors aren't shown in Developer mode, only when we explicitly run the setup:di:compile command.

I hope this helps.

9
  • It also seems that if you've disabled the modules, but you left the modules in your code base, under code/Vendor/ModuleA, and you run any of the di compilation commands, that M2 will still try to compile the di for those modules...so it appears you'd have to use setup:di:compile-multi-tenant --exlude-pattern or setup:di:compile --exlude-pattern in order to tell the di compilation command to ignore your module directories which have been disabled.
    – ryanF
    Commented Jun 11, 2016 at 20:06
  • yes, cleared all folders in var. It seems that there is no parameter exlude-pattern. using 2.0.7 Commented Jun 11, 2016 at 20:26
  • @ClaudiuCreanga it appears the exclude pattern is not present in the setup:di:compile, but is still present in the setup:di:compile-multi-tenant command. I just tested it out on 2.0.7
    – ryanF
    Commented Jun 12, 2016 at 0:07
  • @ClaudiuCreanga my mistake, this isn't available for setup:di:compile for 2.0.6 and 2.0.7.
    – ryanF
    Commented Jun 12, 2016 at 0:15
  • 1
    @ryanF Could be faulty memory. Maybe setup:di:compile-multi-tenant isn't being removed until 2.1 but I'm pretty sure the entire command is going away. Commented Jun 18, 2016 at 16:05

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.