Magento2: Blank install of Magento 2.4.1 via composer breaks on setup:install command.

Created on 21 Oct 2020  ·  66Comments  ·  Source: magento/magento2

Preconditions (*)

  1. PHP - 7.4.9
  2. Apache 2.4

Steps to reproduce (*)

  1. Run Composer Command
    composer create-project --repository=https://repo.magento.com/ magento/project-community-edition magento2
  2. Attempt to run command-line installation.
    php bin/magento setup:install --base-url=http://241.loc/ --db-host=mysql --db-name=241 --db-user=root --db-password= --admin-firstname=Magento --admin-lastname=User [email protected] --admin-user=admin --admin-password=admin123 --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --search-engine=elasticsearch7 --elasticsearch-host=elastic --elasticsearch-port=9200

Expected result (*)

  1. Magento Installs

Actual result (*)

  1. Fatal Error
    Fatal error: Declaration of Psr\Log\LoggerInterface\Proxy::emergency($message, array $context) must be compatible with Psr\Log\LoggerInterface::emergency($message, array $context = NULL) in /shared/httpd/24/htdocs/magento2/generated/code/Psr/Log/LoggerInterface/Proxy.php on line 93
    The proxy generated has functions like below:

public function alert($message, array $context)

However, if you change them directly to:

public function alert($message, array $context = array())


The command will then run successfully, however it will break all bin/magento setup:xxx commands the next time the code is regenerated.

FrameworCode FrameworObjectManager Reported on 2.4.1 Reproduced on 2.4.x S1

Most helpful comment

Hey. I have a question. Why we need create proxy for LoggerInterface object? What this profit we have from this "optimization"?

Maybe make sense remove proxy from DI class and this is fix problem in install.

All 66 comments

Hi @msyhr. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

  • Summary of the issue
  • Information on your environment
  • Steps to reproduce
  • Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this


  • Join Magento Community Engineering Slack and ask your questions in #github channel.

    :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

As a side note, repeating this above process in the identical environment, but specifying:

composer create-project --repository=https://repo.magento.com/ magento/project-community-edition=2.4.0 magento2
successfully install the software. Then updating the composer.json entry to

"magento/product-community-edition": "2.4.1"

will cause the same issue.

experiencing the same issue

Hi @sdzhepa. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

  • [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
    DetailsIf the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
  • [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

  • [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

  • [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

    Details- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

  • [ ] 5. Add label Issue: Confirmed once verification is complete.

  • [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

Hello @msyhr qsolutions-pl
@ihor-sviziev @lbajsarowicz

Thank you for collaboration!

After multiple attempts on different envs and sked different people to check it on their envs

We are not able to reproduce this issue by the provided steps.

At this point, I suppose some important steps/configuration/etc. information is missed in the description.
As possible advice, I would propose to clean composer caches

composer clearcache

Tested on next envs configurations:

  • Apache(2.4.18) | Nginix(1.15.12) |Nginix(1.17.10)
  • PHP 7.4.7 | PHP 7.4.5
  • elastic: 7.7
  • SQL mariadb 10.4 | mariadb 10.3.14 | mysql 14.14(Distr 5.7.31)
  • composer 1.10.6 | 1.9.1
  • w/o | redis 5.0

Tested using the next steps

  1. Get Magento using composer
  2. composer create-project --repository=https://repo.magento.com/ magento/project-community-edition magento2
  3. composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.1 magento2_2

  4. Install magento using CLI script from the description

  5. also checked with "--backend-frontname"(missed in description) and with several other additional parameters

Result: Magento sucessfuly installed. No Fatal errors. Sorefront is available

Hi @sdzhepa, I have the same bug with PHP 7.4.11. But if I use PHP 7.3 , The class Proxy created correctly.
bin/magento setup:di:compile
PHP Fatal error: Declaration of Psr\Log\LoggerInterface\Proxy::emergency($message, array $context) must be compatible with Psr\Log\LoggerInterface::emergency($message, array $context = NULL) in m2/generated/code/Psr/Log/LoggerInterface/Proxy.php on line 93
/usr/bin/php7.3 bin/magento setup:di:compile - This works without the bugs.

Hi @Knase,
Question 1: there might be incorrect php version used. what is php -v shows for you with php 7.4?
Question 2: are you using some extensions that adds plug-in to the logger? If so - could you provide some sample module in order to be able to reproduce the issue?

I am using php 7.4.11
php -v
PHP 7.4.11 (cli) (built: Oct 18 2020 19:39:42) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.11, Copyright (c), by Zend Technologies with Xdebug v2.9.8, Copyright (c) 2002-2020, by Derick Rethans
I installed magento 2.4.1
composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.1 m2
bin/magento setup:install \ --base-url=http://magento.ll \ --backend-frontname=admin \ --db-host=localhost \ --db-name=magento \ --db-user=magento \ --db-password=magento \ --admin-firstname=admin \ --admin-lastname=admin \ [email protected] \ --admin-user=magento \ --admin-password=magento \ --language=en_US \ --currency=USD \ --timezone=America/Chicago \ --search-engine=elasticsearch7 \ --elasticsearch-host=localhost \ --elasticsearch-port=9200 \ --use-rewrites=1;
I got the fatal error during bin/magento setup:install. I fixed the file generated/code/Psr/Log/LoggerInterface/Proxy.php. But if I run the command bin/magento setup:di:compile or remove the file generated/code/Psr/Log/LoggerInterface/Proxy.php, Magento 2 will create this file with errors.

@Knase could you provide your composer.lock file?
Probably with exact the same package versions we'll be able to reproduce this issue

@ihor-sviziev
There is my the composer.lock file
composer.lock.txt

I have same issue on after upgrading Magento Cloud 2.3.6 to 2.4.1 version with PHP 7.3.23.
This error happens on setup:upgrade and any other commands of bin/magento

$ php -v
PHP 7.3.23 (cli) (built: Oct 13 2020 10:38:39) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.23, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.23, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.9.8, Copyright (c) 2002-2020, by Derick Rethans
    with blackfire v1.42.0~linux-x64-non_zts73, https://blackfire.io, by Blackfire

UPD:
After downgrade Magento to 2.4.0 this error didn't show anymore.
I'm using Docker LAMP stack "Devilbox"

Re-opening since other people seem to be running into this issue now.

Some Information from me about my setup:

I'm using https://github.com/cytopia/devilbox for local development

OS 20.04.1 LTS (Focal Fossa)
Docker version 19.03.13, build 4484c46d9d

PHP
APACHE
MYSQL

`[email protected] in /shared/httpd/magento2/htdocs $ php -v
PHP 7.4.9 (cli) (built: Aug 6 2020 19:20:05) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.9, Copyright (c), by Zend Technologies

Virtual Host Below:

magento2.txt
`
Composer Lock Below:
composer.lock.txt

Still fails every time for me. Using a version in the composer command (2.4.0) works flawlessly. Upgrade will create the issue, create-project with no version will create the issue.

@sdzhepa @sidolov could you try to reproduce this issue again? Seems like more people getting this issue. This is quite critical issue

Same issue with the upgrade from 2.3.x to 2.4.0 / 2.4.1

@ihor-sviziev @qsolutions-pl @Knase @msyhr

Thank you for the details

I asked my team to review and investigate it one more time.
Previously we investigated it quite deeply and 4 persons tested it no different envs....
Seems some important precondition or condition or step is missed

I guess, for me that was a file permissions problem. These steps help me, when I upgrading from 2.4.0 to 2.4.1:

  1. Go to Magento 2 folder
  2. sudo chown -R :apache . (for Devilbox I used my user as owner - sudo chown -R 1000:1000 .)
  3. rm -rf generated/code/*

UPD: No, that ^ worked when I up project on the Magento Docker. But when I back to the Devilbox LAMP stack again (PHP 7.3.23 and 7.4.11) - error still persists. It seems to be an environment problem

Hi @msyhr @qsolutions-pl,
Could you try to remove the generated/ folder? Does the issue reproducing after that?

@msyhr Have you found any solution?

Hi @engcom-Delta. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

  • [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
    DetailsIf the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
  • [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

  • [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

  • [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

    Details- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

  • [ ] 5. Add label Issue: Confirmed once verification is complete.

  • [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

@msyhr @qsolutions-pl Unfortunately I am not able to reproduce issue with clean magento installation on my enviroment
Could you please clarify again:
Is this clean magento installation on clean database?
Or it is magento upgrade?

I was not able to reproduce the issue on my machine.
Server version: Apache/2.4.29 (Ubuntu)
PHP 7.4.11

@msyhr @qsolutions-pl Unfortunately I am not able to reproduce issue with clean magento installation on my enviroment
Could you please clarify again:
Is this clean magento installation on clean database?
Or it is magento upgrade?

Clean install clean DB (environment information in my last post)

Installing 2.4.0 works successfully (specifying the version in the composer create-project)

Installing with no version or upgrading via changing version in composer.json after a working 2.4.0 install causes the issue. I'm going to try to replicate this on one of our Dev servers instead of via local dev (docker) and report back.

Hi @msyhr @qsolutions-pl,
Could you try to remove the generated/ folder? Does the issue reproducing after that?

Same result, command fails as soon as the broken proxy is created. The only way I've gotten past this step is by manually changing the functions. However, this fails again as soon as generated/ is cleared again.

@ihor-sviziev

No sure if this would be of any help. Zip of my generated folder. This is what is created when I run the setup:install CLI after composer create-project has finished.

generated.zip

@msyhr I tried fresh magento installation without version on the composer create-project step - installation successfully
Env:

  • PHP 7.4.5 (cli) (built: Apr 19 2020 07:36:13)
  • Apache/2.4.18 (Ubuntu)

Testing scenario 1:

  1. composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .
  2. Install magento
    php bin/magento setup:install --base-url=http://magento2dev.loc/ --db-host=localhost --db-name=magento2dev --db-user=root --db-password="123123q" --admin-firstname=Magento --admin-lastname=User [email protected] --admin-user=admin --admin-password=123123q --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --search-engine=elasticsearch7 --elasticsearch-host=localhost --elasticsearch-port=9200
    Result:
    :heavy_check_mark: Magento installed without errors

Testing scenario 2:

  1. composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.0 .

    1. Install magento

      php bin/magento setup:install --base-url=http://magento2dev.loc/ --db-host=localhost --db-name=magento2dev --db-user=root --db-password="123123q" --admin-firstname=Magento --admin-lastname=User [email protected] --admin-user=admin --admin-password=123123q --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --search-engine=elasticsearch7 --elasticsearch-host=localhost --elasticsearch-port=9200

    2. Upgrade to 2.4.1 according https://devdocs.magento.com/guides/v2.4/comp-mgr/cli/cli-upgrade.html#manage-packages

      cp composer.json composer.json.bak

      composer remove magento/product-community-edition --no-update

      composer require magento/product-community-edition=2.4.1 --no-update

      composer update

      rm -rf var/cache/*

      rm -rf var/page_cache/*

      rm -rf generated/code/*

      bin/magento setup:upgrade

      Result:

      :heavy_check_mark: Magento upgraded to version 2.4.1 without errors

@engcom-Bravo @engcom-Dash could either of you provide your phpinfo(); for you setups. I'd like to compare with my docker instance as this now has to be an ENV issue on my end (devilbox)

same issue upgrading from 2.3.5 to 2.4.1, downgraded to 2.4.0 solved
PHP 7.3.23

@msyhr sure.
image

Clean install 2.4.1, php 7.3.23

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .

ezgif-4-ecb74d9b7e97

Question - are you using composer 1.x or composer 2? Version 2 is not currently supported

Hi Team,

I am facing this issue with vanilla installation
PHP Fatal error: Declaration of PsrLogLoggerInterfaceProxy::emergency($message, array $context) must be compatible with PsrLogLoggerInterface::emergency($message, array $context = NULL) in /var/www/html/m241/generated/code/Psr/Log/LoggerInterface/Proxy.php on line 93

My environment:
OS : Linux Mint 18.2 Sonya
PHP: 7.4.11
Composer: 1.10.13
Magento: 2.4.1

With PHP 7.3, it is not working for me either !

Hi @ihor-sviziev, I'm using Composer version 1.10.16

Interesting... I just tried to do the same on php 7.4 and php 7.3 - issue isn't reproducing for me as well.

Could someone who have this issue post those two files?

generated/code/Psr/Log/LoggerInterface/Proxy.php
vendor/psr/log/Psr/Log/LoggerInterface.php

Or even full project (clean installation, w/o any custom extensions)?

Hi @ihor-sviziev
here are mines
Archive.zip

Interesting... files vendor/psr/log/Psr/Log/LoggerInterface.php are equal, but in your generated/code/Psr/Log/LoggerInterface/Proxy.php we have

    /**
     * {@inheritdoc}
     */
    public function emergency($message, array $context)
    {
        return $this->_getSubject()->emergency($message, $context);
    }

while in my I have

    /**
     * {@inheritdoc}
     */
    public function emergency($message, array $context = [])
    {
        return $this->_getSubject()->emergency($message, $context);
    }

Default value is not defined. Checking...

Hi @ihor-sviziev, I'm using Composer version 1.10.16

Even i have issue with this composer version as well

Interesting... I just tried to do the same on php 7.4 and php 7.3 - issue isn't reproducing for me as well.

Could someone who have this issue post those two files?

generated/code/Psr/Log/LoggerInterface/Proxy.php
vendor/psr/log/Psr/Log/LoggerInterface.php

Or even full project (clean installation, w/o any custom extensions)?

PFA files for your reference, i am facing this in vanilla installation as well !

files.zip

@textarea @krisdass still don't have any valid idea.

I just looked that code actually generated from
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L86 ->
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L122 ->
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L169 ->
https://github.com/magento/magento2/blob/5a836abef542dffa23bd131f74d9f9afc9860c17/lib/internal/Magento/Framework/Code/Generator/EntityAbstract.php#L380-L395 ->
https://github.com/magento/magento2/blob/5a836abef542dffa23bd131f74d9f9afc9860c17/lib/internal/Magento/Framework/Code/Generator/EntityAbstract.php#L356-L371

And basically in this method it goes ValueGenerator is actually LaminasCodeGeneratorValueGenerator.

I just looked - seems like all these places weren't changed since magento 2.3 (except switching from Zend to Laminas, but no real changes were there), also the latest Laminas code package version was released on December 2019 https://github.com/laminas/laminas-code/releases/tag/3.4.1

Now I have following ideas:

  1. you have somehow different version of some package than me
  2. you have some different php settings than me.

In order to process further investigation, could someone from you provide following things?

  1. full zip of the code for clean magento installation that fails for you
  2. php version in the CLI - run following comand: php -v
  3. php configuration in the CLI - run following comand: php -i

Hi @ihor-sviziev. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

  • [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
    DetailsIf the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
  • [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

  • [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

  • [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

    Details- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

  • [ ] 5. Add label Issue: Confirmed once verification is complete.

  • [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

@ihor-sviziev
magento full code in https://we.tl/t-I5WRn8yUvM, php -i info in attached phpinfo.txt and php version in attached phpversion.txt
phpinfo.txt
phpversion.txt

@textarea I see you have installed psr pecl extension. I believe it might cause such issues. Could you try to remove/disable it, remove all files from generated/code/ folder and try again?

I have the same issue. I upgraded Magento via composer.json from 2.3.5-p2 to 2.4.1.
PHP version is: 7.3.20

If I manually modify the file (generated/code/Psr/Log/LoggerInterface/Proxy.php to has a default value of $context to NULL, then Magento starts working again.

Oddly the exact same files are working fine when I use them on an instance with PHP 7.3.22 (with Docker container) but have the issue with using 7.3.20 without Docker.

@ihor-sviziev I followed your advice and removed the PSR extension. It worked! I checked with my docker container and it doesn't have it installed. So it makes sense why it was working there but not on the environment without docker. I had the extension installed because I also have Phalcon based site on that machine too.
Thanks! ... now I have to remove Phalcon :D

@ihor-sviziev yes it works after psr pecl remove.
Also for me now phalcon has to be removed ;)
Thanks!

For everyone who will have the same issue:
please check if you have installed psr php extension (you could check it with php -m).
In case if it's installed - please uninstall or disable it and remove all files from the generated/code/ folder.

✔ Issue should be solved.

I'm closing this issue.

As the issue is inside psr php extension - I just reported issue to github repo https://github.com/jbboehr/php-psr/issues/78.

Any Idea why we need remove extension instead fix code generated ?

@pusachev I strongly believe this is the issue in the psr pecl extension. I'm going to report it soon to their issue tracker

@textarea @krisdass still don't have any valid idea.

I just looked that code actually generated from
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L86

->
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L122

->
https://github.com/magento/magento2/blob/170425c4ddf139ceda21288452ef06e0e464afa1/lib/internal/Magento/Framework/ObjectManager/Code/Generator/Proxy.php#L169

->
https://github.com/magento/magento2/blob/5a836abef542dffa23bd131f74d9f9afc9860c17/lib/internal/Magento/Framework/Code/Generator/EntityAbstract.php#L380-L395

->
https://github.com/magento/magento2/blob/5a836abef542dffa23bd131f74d9f9afc9860c17/lib/internal/Magento/Framework/Code/Generator/EntityAbstract.php#L356-L371

And basically in this method it goes ValueGenerator is actually LaminasCodeGeneratorValueGenerator.

I just looked - seems like all these places weren't changed since magento 2.3 (except switching from Zend to Laminas, but no real changes were there), also the latest Laminas code package version was released on December 2019 https://github.com/laminas/laminas-code/releases/tag/3.4.1

Now I have following ideas:

  1. you have somehow different version of some package than me
  2. you have some different php settings than me.

In order to process further investigation, could someone from you provide following things?

  1. full zip of the code for clean magento installation that fails for you
  2. php version in the CLI - run following comand: php -v
  3. php configuration in the CLI - run following comand: php -i

Hi @ihor-sviziev

PHP Version

PHP 7.4.11 (cli) (built: Oct 10 2020 19:44:32) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.11, Copyright (c), by Zend Technologies
with Xdebug v2.9.8, Copyright (c) 2002-2020, by Derick Rethans

PHP Info attached
php_details.txt

Hi @krisdass,
Please review my comment https://github.com/magento/magento2/issues/30575#issuecomment-721704953, seems like you just need to remove psr php extension.

Hi @ihor-sviziev,
Actually i need to run code scanning with magento2 PSR standards. I use codesniffer and code beautifier cbf to do this.
For this PSR module is required i think.

Let me try and update you.

@krisdass I think it shouldn't be required, but definitely let us know if it is

@ihor-sviziev : since this was reported by many people, I think we need to do something properly about this.

Could we maybe add the following to the composer.json file?

    "conflict": {
        "ext-psr": "*"
    },

@hostep good point, but I hope it will be fixed on the php extension side soon, so it will not be correct. Let's wait at least for some response.
PS: issue already reported https://github.com/jbboehr/php-psr/issues/78

@ihor-sviziev Even if it is fixed on the extension level, there will be instances that could not/will not upgrade that easily. Could we at least update documentation (https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements-tech.html) and add another note that "specific version XX.XX of extension PSR can caused issue"?

Hi @ihor-sviziev,
I was able to set the project and run commands after disabling php psr module.
I will check & update about codesiffer & code beautifier tool output !

Thanks @ihor-sviziev

:white_check_mark: Confirmed by @ihor-sviziev
Thank you for verifying the issue. Based on the provided information internal tickets MC-38918 were created

Issue Available: @ihor-sviziev, _You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself._

I created PR for updating docs in order to highlight that psr php extension might cause such issues.
https://github.com/magento/devdocs/pull/8185

Hi @ihor-sviziev. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:


    1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

    1. Verify that the issue is reproducible on 2.4-develop branch
      Details- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
      - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
      - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
    1. If the issue is not relevant or is not reproducible any more, feel free to close it.

Ok... we got responce from the author of psr extension, seems like PHP 7 API isn't supporting default values, so it can't be fixed for php 7.3 and php 7.4, but could be fixed for php 8.0, and it will be done in https://github.com/jbboehr/php-psr/pull/79.

So currently we have three options:

  1. ✔ Add docs for not using psr php extension with Magento 2 to the docs - I already did in https://github.com/magento/devdocs/pull/8185, hope someone will review it soon
  2. ❔ [not sure] Add conflict with ext-psr to the composer.json file, as suggested in https://github.com/magento/magento2/issues/30575#issuecomment-721813406
  3. ❔ [not sure] Add compatibility with psr extension in the magento2

For now I think adding just a warning to the docs should be enough, I still thinking about implementation of 2nd or maybe 3rd option.

@zenfork and any others using Devilbox running into this issue, I can confirm disabling the psr extension solves the issue.

You'll need to edit the entry to add "psr" in the .env of your devilbox root.

PHP_MODULES_DISABLE=oci8,PDO_OCI,pdo_sqlsrv,sqlsrv,rdkafka,swoole,psr,phalcon

Hey. I have a question. Why we need create proxy for LoggerInterface object? What this profit we have from this "optimization"?

Maybe make sense remove proxy from DI class and this is fix problem in install.

@pusachev TBH I don't really know. Feel free to investigate it 😃

This issue is also related to an upgrade:
2.3.4 -> 2.4.0
2.3.5 -> 2.4.0
2.3.6 -> 2.4.0
and the same with upgrade to 2.4.1

@qsolutions-pl FYI we added info that psr extension causing issue to the docs in https://github.com/magento/devdocs/pull/8185:
https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements.html

@pusachev @ihor-sviziev I bumped into this same issue and was able to solve it by removing the PSR extension (Ubuntu with PHP 7.3: apt-get remove php7.3-psr).

However, the question of @pusachev intrigued me: Why is the proxy needed in the first place?

I tried it and this gave the error Circular dependency: Magento\Framework\Logger\Monolog depends on Magento\Framework\Interception\PluginListGenerator. In other words, the reason why a DI proxy is needed is to fix the circular dependency at constructor time, while at the moment a method of PluginListGenerator is called where logging is needed, this issue is fixed already. So, there is no (easy) way to remove the proxy itself.

@jissereitsma I believe the only one valid fix will be introducing some not dynamically created logger proxy with the same logic inside

Was this page helpful?
0 / 5 - 0 ratings