Magento2 - setup:di:compile
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
add a comment |
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
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
add a comment |
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
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
magento2 setup-di-compile setup-upgrade bin-magento
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
add a comment |
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
add a comment |
4 Answers
4
active
oldest
votes
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.
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
add a comment |
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?
- Factories
- Proxies
- 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
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
add a comment |
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.
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
add a comment |
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.
1
Sorry, I think this does not answer my question
– Raul Sanchez
Jul 18 '17 at 10:08
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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?
- Factories
- Proxies
- 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
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
add a comment |
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?
- Factories
- Proxies
- 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
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
add a comment |
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?
- Factories
- Proxies
- 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
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?
- Factories
- Proxies
- 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
edited 15 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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
1
Sorry, I think this does not answer my question
– Raul Sanchez
Jul 18 '17 at 10:08
add a comment |
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.
1
Sorry, I think this does not answer my question
– Raul Sanchez
Jul 18 '17 at 10:08
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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