Magento2 - setup:di:compile












9















I have been working in a project with some custom code... this is our first "medium" Magento 2 project, so (as all people here I think) every day we learn new things, and we have to change the way to deal with this new Magento version



The reason for this question is asking about the command setup:di:compile



I've been using it since the first day with Magento 2, as bin/magento asks for it after every setup:upgrade, with message "Please re-run Magento compile command"



Well... I have found executing setup:di:compile breaks product view page in this project, with a totally ambiguous Fatal Error. I've spent whole working days trying to debug it and testing with code changes with zero result



Today, I have discovered that if I omit that command then all works like a charm, even in production mode



So, the question is... what exactly does that setup:di:compile command? Is it required? Just recommended? Or it is some deprecated command, which is not needed to be executed?



UPDATE



As some users have required, this is the Fatal Error I was referring




PHP Fatal error: Cannot instantiate abstract class
MagentoCatalogBlockProductViewAbstractView in
***/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php
on line 93




I've searched for any custom block using MagentoCatalogBlockProductViewAbstractView but I've found it only in layout files, it is not present in any block class constructor



What I can't understand is: why Magento is throwing this Fatal Error with compiled code, but it works like a charm without compiled code










share|improve this question

























  • can you confirm that 'setup:di:compile' causes the product view error in development mode too?

    – paj
    Jul 18 '17 at 10:28











  • yes, Fatal Error occurs in both modes

    – Raul Sanchez
    Jul 18 '17 at 14:51











  • Can you post the "totally ambiguous Fatal Error"?

    – paj
    Jul 18 '17 at 15:55











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06
















9















I have been working in a project with some custom code... this is our first "medium" Magento 2 project, so (as all people here I think) every day we learn new things, and we have to change the way to deal with this new Magento version



The reason for this question is asking about the command setup:di:compile



I've been using it since the first day with Magento 2, as bin/magento asks for it after every setup:upgrade, with message "Please re-run Magento compile command"



Well... I have found executing setup:di:compile breaks product view page in this project, with a totally ambiguous Fatal Error. I've spent whole working days trying to debug it and testing with code changes with zero result



Today, I have discovered that if I omit that command then all works like a charm, even in production mode



So, the question is... what exactly does that setup:di:compile command? Is it required? Just recommended? Or it is some deprecated command, which is not needed to be executed?



UPDATE



As some users have required, this is the Fatal Error I was referring




PHP Fatal error: Cannot instantiate abstract class
MagentoCatalogBlockProductViewAbstractView in
***/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php
on line 93




I've searched for any custom block using MagentoCatalogBlockProductViewAbstractView but I've found it only in layout files, it is not present in any block class constructor



What I can't understand is: why Magento is throwing this Fatal Error with compiled code, but it works like a charm without compiled code










share|improve this question

























  • can you confirm that 'setup:di:compile' causes the product view error in development mode too?

    – paj
    Jul 18 '17 at 10:28











  • yes, Fatal Error occurs in both modes

    – Raul Sanchez
    Jul 18 '17 at 14:51











  • Can you post the "totally ambiguous Fatal Error"?

    – paj
    Jul 18 '17 at 15:55











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06














9












9








9


5






I have been working in a project with some custom code... this is our first "medium" Magento 2 project, so (as all people here I think) every day we learn new things, and we have to change the way to deal with this new Magento version



The reason for this question is asking about the command setup:di:compile



I've been using it since the first day with Magento 2, as bin/magento asks for it after every setup:upgrade, with message "Please re-run Magento compile command"



Well... I have found executing setup:di:compile breaks product view page in this project, with a totally ambiguous Fatal Error. I've spent whole working days trying to debug it and testing with code changes with zero result



Today, I have discovered that if I omit that command then all works like a charm, even in production mode



So, the question is... what exactly does that setup:di:compile command? Is it required? Just recommended? Or it is some deprecated command, which is not needed to be executed?



UPDATE



As some users have required, this is the Fatal Error I was referring




PHP Fatal error: Cannot instantiate abstract class
MagentoCatalogBlockProductViewAbstractView in
***/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php
on line 93




I've searched for any custom block using MagentoCatalogBlockProductViewAbstractView but I've found it only in layout files, it is not present in any block class constructor



What I can't understand is: why Magento is throwing this Fatal Error with compiled code, but it works like a charm without compiled code










share|improve this question
















I have been working in a project with some custom code... this is our first "medium" Magento 2 project, so (as all people here I think) every day we learn new things, and we have to change the way to deal with this new Magento version



The reason for this question is asking about the command setup:di:compile



I've been using it since the first day with Magento 2, as bin/magento asks for it after every setup:upgrade, with message "Please re-run Magento compile command"



Well... I have found executing setup:di:compile breaks product view page in this project, with a totally ambiguous Fatal Error. I've spent whole working days trying to debug it and testing with code changes with zero result



Today, I have discovered that if I omit that command then all works like a charm, even in production mode



So, the question is... what exactly does that setup:di:compile command? Is it required? Just recommended? Or it is some deprecated command, which is not needed to be executed?



UPDATE



As some users have required, this is the Fatal Error I was referring




PHP Fatal error: Cannot instantiate abstract class
MagentoCatalogBlockProductViewAbstractView in
***/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php
on line 93




I've searched for any custom block using MagentoCatalogBlockProductViewAbstractView but I've found it only in layout files, it is not present in any block class constructor



What I can't understand is: why Magento is throwing this Fatal Error with compiled code, but it works like a charm without compiled code







magento2 setup-di-compile setup-upgrade bin-magento






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 11 '17 at 9:56







Raul Sanchez

















asked Jul 18 '17 at 8:44









Raul SanchezRaul Sanchez

1,89431135




1,89431135













  • can you confirm that 'setup:di:compile' causes the product view error in development mode too?

    – paj
    Jul 18 '17 at 10:28











  • yes, Fatal Error occurs in both modes

    – Raul Sanchez
    Jul 18 '17 at 14:51











  • Can you post the "totally ambiguous Fatal Error"?

    – paj
    Jul 18 '17 at 15:55











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06



















  • can you confirm that 'setup:di:compile' causes the product view error in development mode too?

    – paj
    Jul 18 '17 at 10:28











  • yes, Fatal Error occurs in both modes

    – Raul Sanchez
    Jul 18 '17 at 14:51











  • Can you post the "totally ambiguous Fatal Error"?

    – paj
    Jul 18 '17 at 15:55











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06

















can you confirm that 'setup:di:compile' causes the product view error in development mode too?

– paj
Jul 18 '17 at 10:28





can you confirm that 'setup:di:compile' causes the product view error in development mode too?

– paj
Jul 18 '17 at 10:28













yes, Fatal Error occurs in both modes

– Raul Sanchez
Jul 18 '17 at 14:51





yes, Fatal Error occurs in both modes

– Raul Sanchez
Jul 18 '17 at 14:51













Can you post the "totally ambiguous Fatal Error"?

– paj
Jul 18 '17 at 15:55





Can you post the "totally ambiguous Fatal Error"?

– paj
Jul 18 '17 at 15:55













I have updated the question with error. Thanks

– Raul Sanchez
Jul 19 '17 at 8:06





I have updated the question with error. Thanks

– Raul Sanchez
Jul 19 '17 at 8:06










4 Answers
4






active

oldest

votes


















13














The command setup:di:compile command generates the contents of the var/di folder in Magento <2.2 and generated for Magento >= 2.2



According to Magento, this serves the following purpose:




  • Application code generation (factories, proxies, and so on)

  • Area configuration aggregation (that is, optimized dependency injection
    configurations per area)

  • Interceptor generation (that is, optimized
    code generation of interceptors)

  • Interception cache generation

  • Repositories code generation (that is, generated code for APIs)

  • Service data attributes generation (that is, generated extension
    classes for data objects)


Source (http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html)



However, when you place Magento in production mode, without compilation it indeed still works. So according to the Magento docs this is more an optimization step (that is, optimized code generation of interceptors)



When we have errors in the setup:di:compile command, this is mostly because of errors in one of the constructors of custom php classes.






share|improve this answer


























  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages

    – Raul Sanchez
    Jul 18 '17 at 14:55











  • Maybe you can post the error? That would make thing more clear.

    – Tjitse
    Jul 19 '17 at 7:15











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06



















6














It's not mandatory to run setup:di:compile command everytime but if you have done any code change specially with factory methods ,proxy, add plugins or any code compilation then you must need to run this command.




More Details




magento setup:di:compile in order to generate necessary files. Both options ends up with generating classes in MAGENTO_ROOT/var/generation directory.



What classes are generated?




  1. Factories

  2. Proxies

  3. Plugins


Factories



Factories are used to instantiate objects that can not be injected automatically. For example, a product object has to be loaded from the database, but dependency injection container doesn’t have enough information to create this object. That’s why we use factories.



Proxies



Magento 2 uses constructor injection in which all dependencies are required. You cannot instantiate an object without passing all dependencies. What if you’d like to have optional dependencies? That’s why proxies exist.



Plugins (Interceptors)



Simply put, plugins are the primary customization mechanisms for Magento 2. No more class rewrites. It allows you to hook in and do something before, after or around any public method of the application.



when you run setup:di:compile command it do below things



Code compilation consists of all of the following in no particular order:




  • Application code generation (factories, proxies, and so on)


  • Area configuration aggregation (that is, optimized dependency
    injection configurations per area)


  • Interceptor generation (that is, optimized code generation of
    interceptors)


  • Interception cache generation Repositories code generation (that is,
    generated code for APIs)


  • Service data attributes generation (that is, generated extension
    classes for data objects)



Refer this answer for when we should run which commands: https://magento.stackexchange.com/a/184927/35758






share|improve this answer


























  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages... so I don't really understand why not compiled code works nice but when compiling then Fatal Error happens

    – Raul Sanchez
    Jul 19 '17 at 7:56











  • This can happen if your sub-class added new dependencies after the existing optional dependencies of the parent class. You can fix this by moving any new required parameter up above the optional ones.

    – Prince Patel
    Jul 19 '17 at 8:32



















1














Magento will still run in production and dev without the di:compile command. It will actually compile the Interceptors as it needs to and store the in the generated folder.



Even if it works, that does not mean you should skip this step! In fact, when this is ran, magento also checks for duplicated injections, dependency loops and other fundamental steps that will make your site more stable and less likely to crash and !die.



I strongly believe that that error is due to the use of a class that Magento can't compile due to some wrong constructor argument.



The error you posted is pretty vague, but I believe you have a class that extends the AbstractView class, 99% it's a block somewhere in your custom modules that does not pass the correct arguments to the parent::__construct() method. Hence when instantiated it fails.



Note that all blocks extend the AbstractView class so you'll have to execute the compile command with xdebug on and set a log at look at the stack trace to see what class called it last before it failed.



The fact that the site runs without that error means that you're not actually using the corrupted block anywhere on your page, but Magento will still try to compile it when running the compile command, hence it fails.






share|improve this answer
























  • Thanks for taking the time to answer an older question like this, with other validated answers... In fact, I resolved this by fixing that wrong blocks in custom layouts, as you have pointed

    – Raul Sanchez
    Feb 22 '18 at 15:58



















-1














I think you have created a new custom module or you made changes in your custom theme after create a new module execute this command one by one.



i hope your problem will be solved.



Setup Upgrade Using Command Line



php bin/magento setup:upgrade


Cache Clean Using Command Line



php bin/magento cache:clean


Cache Flush Using Command Line



php bin/magento cache:flush


View cache status Using Command Line



php bin/magento cache:status


Enable Cache Using Command Line



php bin/magento cache:enable [cache_type]


Disable Cache Using Command Line



php bin/magento cache:disable [cache_type]


Static Content Deploy Using Command Line



php bin/magento setup:static-content:deploy


Reference By Magento2 Commands



Thank you.






share|improve this answer



















  • 1





    Sorry, I think this does not answer my question

    – Raul Sanchez
    Jul 18 '17 at 10:08











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "479"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f184237%2fmagento2-setupdicompile%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























4 Answers
4






active

oldest

votes








4 Answers
4






active

oldest

votes









active

oldest

votes






active

oldest

votes









13














The command setup:di:compile command generates the contents of the var/di folder in Magento <2.2 and generated for Magento >= 2.2



According to Magento, this serves the following purpose:




  • Application code generation (factories, proxies, and so on)

  • Area configuration aggregation (that is, optimized dependency injection
    configurations per area)

  • Interceptor generation (that is, optimized
    code generation of interceptors)

  • Interception cache generation

  • Repositories code generation (that is, generated code for APIs)

  • Service data attributes generation (that is, generated extension
    classes for data objects)


Source (http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html)



However, when you place Magento in production mode, without compilation it indeed still works. So according to the Magento docs this is more an optimization step (that is, optimized code generation of interceptors)



When we have errors in the setup:di:compile command, this is mostly because of errors in one of the constructors of custom php classes.






share|improve this answer


























  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages

    – Raul Sanchez
    Jul 18 '17 at 14:55











  • Maybe you can post the error? That would make thing more clear.

    – Tjitse
    Jul 19 '17 at 7:15











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06
















13














The command setup:di:compile command generates the contents of the var/di folder in Magento <2.2 and generated for Magento >= 2.2



According to Magento, this serves the following purpose:




  • Application code generation (factories, proxies, and so on)

  • Area configuration aggregation (that is, optimized dependency injection
    configurations per area)

  • Interceptor generation (that is, optimized
    code generation of interceptors)

  • Interception cache generation

  • Repositories code generation (that is, generated code for APIs)

  • Service data attributes generation (that is, generated extension
    classes for data objects)


Source (http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html)



However, when you place Magento in production mode, without compilation it indeed still works. So according to the Magento docs this is more an optimization step (that is, optimized code generation of interceptors)



When we have errors in the setup:di:compile command, this is mostly because of errors in one of the constructors of custom php classes.






share|improve this answer


























  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages

    – Raul Sanchez
    Jul 18 '17 at 14:55











  • Maybe you can post the error? That would make thing more clear.

    – Tjitse
    Jul 19 '17 at 7:15











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06














13












13








13







The command setup:di:compile command generates the contents of the var/di folder in Magento <2.2 and generated for Magento >= 2.2



According to Magento, this serves the following purpose:




  • Application code generation (factories, proxies, and so on)

  • Area configuration aggregation (that is, optimized dependency injection
    configurations per area)

  • Interceptor generation (that is, optimized
    code generation of interceptors)

  • Interception cache generation

  • Repositories code generation (that is, generated code for APIs)

  • Service data attributes generation (that is, generated extension
    classes for data objects)


Source (http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html)



However, when you place Magento in production mode, without compilation it indeed still works. So according to the Magento docs this is more an optimization step (that is, optimized code generation of interceptors)



When we have errors in the setup:di:compile command, this is mostly because of errors in one of the constructors of custom php classes.






share|improve this answer















The command setup:di:compile command generates the contents of the var/di folder in Magento <2.2 and generated for Magento >= 2.2



According to Magento, this serves the following purpose:




  • Application code generation (factories, proxies, and so on)

  • Area configuration aggregation (that is, optimized dependency injection
    configurations per area)

  • Interceptor generation (that is, optimized
    code generation of interceptors)

  • Interception cache generation

  • Repositories code generation (that is, generated code for APIs)

  • Service data attributes generation (that is, generated extension
    classes for data objects)


Source (http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html)



However, when you place Magento in production mode, without compilation it indeed still works. So according to the Magento docs this is more an optimization step (that is, optimized code generation of interceptors)



When we have errors in the setup:di:compile command, this is mostly because of errors in one of the constructors of custom php classes.







share|improve this answer














share|improve this answer



share|improve this answer








edited May 16 '18 at 21:10









vitoriodachef

1,049418




1,049418










answered Jul 18 '17 at 10:58









TjitseTjitse

657418




657418













  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages

    – Raul Sanchez
    Jul 18 '17 at 14:55











  • Maybe you can post the error? That would make thing more clear.

    – Tjitse
    Jul 19 '17 at 7:15











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06



















  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages

    – Raul Sanchez
    Jul 18 '17 at 14:55











  • Maybe you can post the error? That would make thing more clear.

    – Tjitse
    Jul 19 '17 at 7:15











  • I have updated the question with error. Thanks

    – Raul Sanchez
    Jul 19 '17 at 8:06

















Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages

– Raul Sanchez
Jul 18 '17 at 14:55





Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages

– Raul Sanchez
Jul 18 '17 at 14:55













Maybe you can post the error? That would make thing more clear.

– Tjitse
Jul 19 '17 at 7:15





Maybe you can post the error? That would make thing more clear.

– Tjitse
Jul 19 '17 at 7:15













I have updated the question with error. Thanks

– Raul Sanchez
Jul 19 '17 at 8:06





I have updated the question with error. Thanks

– Raul Sanchez
Jul 19 '17 at 8:06













6














It's not mandatory to run setup:di:compile command everytime but if you have done any code change specially with factory methods ,proxy, add plugins or any code compilation then you must need to run this command.




More Details




magento setup:di:compile in order to generate necessary files. Both options ends up with generating classes in MAGENTO_ROOT/var/generation directory.



What classes are generated?




  1. Factories

  2. Proxies

  3. Plugins


Factories



Factories are used to instantiate objects that can not be injected automatically. For example, a product object has to be loaded from the database, but dependency injection container doesn’t have enough information to create this object. That’s why we use factories.



Proxies



Magento 2 uses constructor injection in which all dependencies are required. You cannot instantiate an object without passing all dependencies. What if you’d like to have optional dependencies? That’s why proxies exist.



Plugins (Interceptors)



Simply put, plugins are the primary customization mechanisms for Magento 2. No more class rewrites. It allows you to hook in and do something before, after or around any public method of the application.



when you run setup:di:compile command it do below things



Code compilation consists of all of the following in no particular order:




  • Application code generation (factories, proxies, and so on)


  • Area configuration aggregation (that is, optimized dependency
    injection configurations per area)


  • Interceptor generation (that is, optimized code generation of
    interceptors)


  • Interception cache generation Repositories code generation (that is,
    generated code for APIs)


  • Service data attributes generation (that is, generated extension
    classes for data objects)



Refer this answer for when we should run which commands: https://magento.stackexchange.com/a/184927/35758






share|improve this answer


























  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages... so I don't really understand why not compiled code works nice but when compiling then Fatal Error happens

    – Raul Sanchez
    Jul 19 '17 at 7:56











  • This can happen if your sub-class added new dependencies after the existing optional dependencies of the parent class. You can fix this by moving any new required parameter up above the optional ones.

    – Prince Patel
    Jul 19 '17 at 8:32
















6














It's not mandatory to run setup:di:compile command everytime but if you have done any code change specially with factory methods ,proxy, add plugins or any code compilation then you must need to run this command.




More Details




magento setup:di:compile in order to generate necessary files. Both options ends up with generating classes in MAGENTO_ROOT/var/generation directory.



What classes are generated?




  1. Factories

  2. Proxies

  3. Plugins


Factories



Factories are used to instantiate objects that can not be injected automatically. For example, a product object has to be loaded from the database, but dependency injection container doesn’t have enough information to create this object. That’s why we use factories.



Proxies



Magento 2 uses constructor injection in which all dependencies are required. You cannot instantiate an object without passing all dependencies. What if you’d like to have optional dependencies? That’s why proxies exist.



Plugins (Interceptors)



Simply put, plugins are the primary customization mechanisms for Magento 2. No more class rewrites. It allows you to hook in and do something before, after or around any public method of the application.



when you run setup:di:compile command it do below things



Code compilation consists of all of the following in no particular order:




  • Application code generation (factories, proxies, and so on)


  • Area configuration aggregation (that is, optimized dependency
    injection configurations per area)


  • Interceptor generation (that is, optimized code generation of
    interceptors)


  • Interception cache generation Repositories code generation (that is,
    generated code for APIs)


  • Service data attributes generation (that is, generated extension
    classes for data objects)



Refer this answer for when we should run which commands: https://magento.stackexchange.com/a/184927/35758






share|improve this answer


























  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages... so I don't really understand why not compiled code works nice but when compiling then Fatal Error happens

    – Raul Sanchez
    Jul 19 '17 at 7:56











  • This can happen if your sub-class added new dependencies after the existing optional dependencies of the parent class. You can fix this by moving any new required parameter up above the optional ones.

    – Prince Patel
    Jul 19 '17 at 8:32














6












6








6







It's not mandatory to run setup:di:compile command everytime but if you have done any code change specially with factory methods ,proxy, add plugins or any code compilation then you must need to run this command.




More Details




magento setup:di:compile in order to generate necessary files. Both options ends up with generating classes in MAGENTO_ROOT/var/generation directory.



What classes are generated?




  1. Factories

  2. Proxies

  3. Plugins


Factories



Factories are used to instantiate objects that can not be injected automatically. For example, a product object has to be loaded from the database, but dependency injection container doesn’t have enough information to create this object. That’s why we use factories.



Proxies



Magento 2 uses constructor injection in which all dependencies are required. You cannot instantiate an object without passing all dependencies. What if you’d like to have optional dependencies? That’s why proxies exist.



Plugins (Interceptors)



Simply put, plugins are the primary customization mechanisms for Magento 2. No more class rewrites. It allows you to hook in and do something before, after or around any public method of the application.



when you run setup:di:compile command it do below things



Code compilation consists of all of the following in no particular order:




  • Application code generation (factories, proxies, and so on)


  • Area configuration aggregation (that is, optimized dependency
    injection configurations per area)


  • Interceptor generation (that is, optimized code generation of
    interceptors)


  • Interception cache generation Repositories code generation (that is,
    generated code for APIs)


  • Service data attributes generation (that is, generated extension
    classes for data objects)



Refer this answer for when we should run which commands: https://magento.stackexchange.com/a/184927/35758






share|improve this answer















It's not mandatory to run setup:di:compile command everytime but if you have done any code change specially with factory methods ,proxy, add plugins or any code compilation then you must need to run this command.




More Details




magento setup:di:compile in order to generate necessary files. Both options ends up with generating classes in MAGENTO_ROOT/var/generation directory.



What classes are generated?




  1. Factories

  2. Proxies

  3. Plugins


Factories



Factories are used to instantiate objects that can not be injected automatically. For example, a product object has to be loaded from the database, but dependency injection container doesn’t have enough information to create this object. That’s why we use factories.



Proxies



Magento 2 uses constructor injection in which all dependencies are required. You cannot instantiate an object without passing all dependencies. What if you’d like to have optional dependencies? That’s why proxies exist.



Plugins (Interceptors)



Simply put, plugins are the primary customization mechanisms for Magento 2. No more class rewrites. It allows you to hook in and do something before, after or around any public method of the application.



when you run setup:di:compile command it do below things



Code compilation consists of all of the following in no particular order:




  • Application code generation (factories, proxies, and so on)


  • Area configuration aggregation (that is, optimized dependency
    injection configurations per area)


  • Interceptor generation (that is, optimized code generation of
    interceptors)


  • Interception cache generation Repositories code generation (that is,
    generated code for APIs)


  • Service data attributes generation (that is, generated extension
    classes for data objects)



Refer this answer for when we should run which commands: https://magento.stackexchange.com/a/184927/35758







share|improve this answer














share|improve this answer



share|improve this answer








edited 24 mins ago

























answered Jul 18 '17 at 17:17









Prince PatelPrince Patel

13.3k54676




13.3k54676













  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages... so I don't really understand why not compiled code works nice but when compiling then Fatal Error happens

    – Raul Sanchez
    Jul 19 '17 at 7:56











  • This can happen if your sub-class added new dependencies after the existing optional dependencies of the parent class. You can fix this by moving any new required parameter up above the optional ones.

    – Prince Patel
    Jul 19 '17 at 8:32



















  • Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages... so I don't really understand why not compiled code works nice but when compiling then Fatal Error happens

    – Raul Sanchez
    Jul 19 '17 at 7:56











  • This can happen if your sub-class added new dependencies after the existing optional dependencies of the parent class. You can fix this by moving any new required parameter up above the optional ones.

    – Prince Patel
    Jul 19 '17 at 8:32

















Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages... so I don't really understand why not compiled code works nice but when compiling then Fatal Error happens

– Raul Sanchez
Jul 19 '17 at 7:56





Thanks! So, it is totally optional... Just one point, so it is more clear to me. In our case, setup:di: compile does not throw any error, command ends ok. It is when browsing the site, after command has finished, when Fatal Error is fired, in product view pages... so I don't really understand why not compiled code works nice but when compiling then Fatal Error happens

– Raul Sanchez
Jul 19 '17 at 7:56













This can happen if your sub-class added new dependencies after the existing optional dependencies of the parent class. You can fix this by moving any new required parameter up above the optional ones.

– Prince Patel
Jul 19 '17 at 8:32





This can happen if your sub-class added new dependencies after the existing optional dependencies of the parent class. You can fix this by moving any new required parameter up above the optional ones.

– Prince Patel
Jul 19 '17 at 8:32











1














Magento will still run in production and dev without the di:compile command. It will actually compile the Interceptors as it needs to and store the in the generated folder.



Even if it works, that does not mean you should skip this step! In fact, when this is ran, magento also checks for duplicated injections, dependency loops and other fundamental steps that will make your site more stable and less likely to crash and !die.



I strongly believe that that error is due to the use of a class that Magento can't compile due to some wrong constructor argument.



The error you posted is pretty vague, but I believe you have a class that extends the AbstractView class, 99% it's a block somewhere in your custom modules that does not pass the correct arguments to the parent::__construct() method. Hence when instantiated it fails.



Note that all blocks extend the AbstractView class so you'll have to execute the compile command with xdebug on and set a log at look at the stack trace to see what class called it last before it failed.



The fact that the site runs without that error means that you're not actually using the corrupted block anywhere on your page, but Magento will still try to compile it when running the compile command, hence it fails.






share|improve this answer
























  • Thanks for taking the time to answer an older question like this, with other validated answers... In fact, I resolved this by fixing that wrong blocks in custom layouts, as you have pointed

    – Raul Sanchez
    Feb 22 '18 at 15:58
















1














Magento will still run in production and dev without the di:compile command. It will actually compile the Interceptors as it needs to and store the in the generated folder.



Even if it works, that does not mean you should skip this step! In fact, when this is ran, magento also checks for duplicated injections, dependency loops and other fundamental steps that will make your site more stable and less likely to crash and !die.



I strongly believe that that error is due to the use of a class that Magento can't compile due to some wrong constructor argument.



The error you posted is pretty vague, but I believe you have a class that extends the AbstractView class, 99% it's a block somewhere in your custom modules that does not pass the correct arguments to the parent::__construct() method. Hence when instantiated it fails.



Note that all blocks extend the AbstractView class so you'll have to execute the compile command with xdebug on and set a log at look at the stack trace to see what class called it last before it failed.



The fact that the site runs without that error means that you're not actually using the corrupted block anywhere on your page, but Magento will still try to compile it when running the compile command, hence it fails.






share|improve this answer
























  • Thanks for taking the time to answer an older question like this, with other validated answers... In fact, I resolved this by fixing that wrong blocks in custom layouts, as you have pointed

    – Raul Sanchez
    Feb 22 '18 at 15:58














1












1








1







Magento will still run in production and dev without the di:compile command. It will actually compile the Interceptors as it needs to and store the in the generated folder.



Even if it works, that does not mean you should skip this step! In fact, when this is ran, magento also checks for duplicated injections, dependency loops and other fundamental steps that will make your site more stable and less likely to crash and !die.



I strongly believe that that error is due to the use of a class that Magento can't compile due to some wrong constructor argument.



The error you posted is pretty vague, but I believe you have a class that extends the AbstractView class, 99% it's a block somewhere in your custom modules that does not pass the correct arguments to the parent::__construct() method. Hence when instantiated it fails.



Note that all blocks extend the AbstractView class so you'll have to execute the compile command with xdebug on and set a log at look at the stack trace to see what class called it last before it failed.



The fact that the site runs without that error means that you're not actually using the corrupted block anywhere on your page, but Magento will still try to compile it when running the compile command, hence it fails.






share|improve this answer













Magento will still run in production and dev without the di:compile command. It will actually compile the Interceptors as it needs to and store the in the generated folder.



Even if it works, that does not mean you should skip this step! In fact, when this is ran, magento also checks for duplicated injections, dependency loops and other fundamental steps that will make your site more stable and less likely to crash and !die.



I strongly believe that that error is due to the use of a class that Magento can't compile due to some wrong constructor argument.



The error you posted is pretty vague, but I believe you have a class that extends the AbstractView class, 99% it's a block somewhere in your custom modules that does not pass the correct arguments to the parent::__construct() method. Hence when instantiated it fails.



Note that all blocks extend the AbstractView class so you'll have to execute the compile command with xdebug on and set a log at look at the stack trace to see what class called it last before it failed.



The fact that the site runs without that error means that you're not actually using the corrupted block anywhere on your page, but Magento will still try to compile it when running the compile command, hence it fails.







share|improve this answer












share|improve this answer



share|improve this answer










answered Feb 22 '18 at 15:46









drew7721drew7721

433310




433310













  • Thanks for taking the time to answer an older question like this, with other validated answers... In fact, I resolved this by fixing that wrong blocks in custom layouts, as you have pointed

    – Raul Sanchez
    Feb 22 '18 at 15:58



















  • Thanks for taking the time to answer an older question like this, with other validated answers... In fact, I resolved this by fixing that wrong blocks in custom layouts, as you have pointed

    – Raul Sanchez
    Feb 22 '18 at 15:58

















Thanks for taking the time to answer an older question like this, with other validated answers... In fact, I resolved this by fixing that wrong blocks in custom layouts, as you have pointed

– Raul Sanchez
Feb 22 '18 at 15:58





Thanks for taking the time to answer an older question like this, with other validated answers... In fact, I resolved this by fixing that wrong blocks in custom layouts, as you have pointed

– Raul Sanchez
Feb 22 '18 at 15:58











-1














I think you have created a new custom module or you made changes in your custom theme after create a new module execute this command one by one.



i hope your problem will be solved.



Setup Upgrade Using Command Line



php bin/magento setup:upgrade


Cache Clean Using Command Line



php bin/magento cache:clean


Cache Flush Using Command Line



php bin/magento cache:flush


View cache status Using Command Line



php bin/magento cache:status


Enable Cache Using Command Line



php bin/magento cache:enable [cache_type]


Disable Cache Using Command Line



php bin/magento cache:disable [cache_type]


Static Content Deploy Using Command Line



php bin/magento setup:static-content:deploy


Reference By Magento2 Commands



Thank you.






share|improve this answer



















  • 1





    Sorry, I think this does not answer my question

    – Raul Sanchez
    Jul 18 '17 at 10:08
















-1














I think you have created a new custom module or you made changes in your custom theme after create a new module execute this command one by one.



i hope your problem will be solved.



Setup Upgrade Using Command Line



php bin/magento setup:upgrade


Cache Clean Using Command Line



php bin/magento cache:clean


Cache Flush Using Command Line



php bin/magento cache:flush


View cache status Using Command Line



php bin/magento cache:status


Enable Cache Using Command Line



php bin/magento cache:enable [cache_type]


Disable Cache Using Command Line



php bin/magento cache:disable [cache_type]


Static Content Deploy Using Command Line



php bin/magento setup:static-content:deploy


Reference By Magento2 Commands



Thank you.






share|improve this answer



















  • 1





    Sorry, I think this does not answer my question

    – Raul Sanchez
    Jul 18 '17 at 10:08














-1












-1








-1







I think you have created a new custom module or you made changes in your custom theme after create a new module execute this command one by one.



i hope your problem will be solved.



Setup Upgrade Using Command Line



php bin/magento setup:upgrade


Cache Clean Using Command Line



php bin/magento cache:clean


Cache Flush Using Command Line



php bin/magento cache:flush


View cache status Using Command Line



php bin/magento cache:status


Enable Cache Using Command Line



php bin/magento cache:enable [cache_type]


Disable Cache Using Command Line



php bin/magento cache:disable [cache_type]


Static Content Deploy Using Command Line



php bin/magento setup:static-content:deploy


Reference By Magento2 Commands



Thank you.






share|improve this answer













I think you have created a new custom module or you made changes in your custom theme after create a new module execute this command one by one.



i hope your problem will be solved.



Setup Upgrade Using Command Line



php bin/magento setup:upgrade


Cache Clean Using Command Line



php bin/magento cache:clean


Cache Flush Using Command Line



php bin/magento cache:flush


View cache status Using Command Line



php bin/magento cache:status


Enable Cache Using Command Line



php bin/magento cache:enable [cache_type]


Disable Cache Using Command Line



php bin/magento cache:disable [cache_type]


Static Content Deploy Using Command Line



php bin/magento setup:static-content:deploy


Reference By Magento2 Commands



Thank you.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jul 18 '17 at 9:03









SarfarajSarfaraj

378318




378318








  • 1





    Sorry, I think this does not answer my question

    – Raul Sanchez
    Jul 18 '17 at 10:08














  • 1





    Sorry, I think this does not answer my question

    – Raul Sanchez
    Jul 18 '17 at 10:08








1




1





Sorry, I think this does not answer my question

– Raul Sanchez
Jul 18 '17 at 10:08





Sorry, I think this does not answer my question

– Raul Sanchez
Jul 18 '17 at 10:08


















draft saved

draft discarded




















































Thanks for contributing an answer to Magento Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f184237%2fmagento2-setupdicompile%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Polycentropodidae

Magento 2 Error message: Invalid state change requested

Paulmy