Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null can not be used as a standalone type in Paypal Braintree Core #38775

Open
1 of 5 tasks
GrimLink opened this issue May 29, 2024 · 13 comments
Open
1 of 5 tasks

Null can not be used as a standalone type in Paypal Braintree Core #38775

GrimLink opened this issue May 29, 2024 · 13 comments
Labels
Area: Framework Component: Backend Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Priority: P1 Once P0 defects have been fixed, a defect having this priority is the next candidate for fixing. Progress: ready for dev Reported on 2.4.7 Indicates original Magento version for the Issue report. Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch

Comments

@GrimLink
Copy link
Member

Preconditions and environment

  • Magento 2.4.7
  • MacOS 14.5 running on Laravel Valet

Steps to reproduce

Run bin/magento setup:di:compile after a very short moment the following error is thrown:

Fatal error: Null can not be used as a standalone type in /vendor/paypal/module-braintree-core/Plugin/DeleteStoredPaymentPlugin.php on line 57

Expected result

No errors

Actual result

Fatal error: Null can not be used as a standalone type in /vendor/paypal/module-braintree-core/Plugin/DeleteStoredPaymentPlugin.php on line 57

Additional information

No response

Release note

No response

Triage and priority

  • Severity: S0 - Affects critical data or functionality and leaves users without workaround.
  • Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
  • Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
  • Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
  • Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Copy link

m2-assistant bot commented May 29, 2024

Hi @GrimLink. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:


Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

@m2-community-project m2-community-project bot added this to Ready for Confirmation in Issue Confirmation and Triage Board May 29, 2024
@engcom-Bravo engcom-Bravo added the Reported on 2.4.7 Indicates original Magento version for the Issue report. label May 30, 2024
@nuwaus
Copy link

nuwaus commented May 30, 2024

I have the same issue too, after upgrading to 2.4.7

@hostep
Copy link
Contributor

hostep commented May 30, 2024

What version of PHP are you guys using? Is it 8.1? Because standalone type of null is only supported in PHP 8.2 and higher.

I can confirm that the paypal/braintree module is using null as a return type, despite its composer constraints stating it's compatible with PHP 8.1: "php": "~8.1.0||~8.2.0||~8.3.0",

So this is a valid bug report, the people who maintain the paypal/braintree module should fix this.

Quick fix would be to switch to PHP 8.2 or 8.3

@nuwaus
Copy link

nuwaus commented May 31, 2024

What version of PHP are you guys using? Is it 8.1? Because standalone type of null is only supported in PHP 8.2 and higher.

I can confirm that the paypal/braintree module is using null as a return type, despite its composer constraints stating it's compatible with PHP 8.1: "php": "~8.1.0||~8.2.0||~8.3.0",

So this is a valid bug report, the people who maintain the paypal/braintree module should fix this.

Quick fix would be to switch to PHP 8.2 or 8.3

I'm currently on PHP 8.1

I will try switching the PHP version.

Thank you

@GrimLink
Copy link
Member Author

@hostep I am also using php 8.1, also why I am reporting this 😉

@engcom-November engcom-November self-assigned this Jun 25, 2024
Copy link

m2-assistant bot commented Jun 25, 2024

Hi @engcom-November. 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: 👇

  • 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  • 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
  • 3. Add Area: XXXXX label to the ticket, indicating the functional areas 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.

@engcom-November
Copy link
Contributor

Hello @GrimLink,

Thank you for the report and collaboration!

Verified this on 2.4-develop branch.
When running bin/magento setup:di:compile with php 8.1 installed we are getting the below error:

Fatal error:  Null can not be used as a standalone type in /opt/homebrew/var/www/magento8/app/code/PayPal/Braintree/Plugin/DeleteStoredPaymentPlugin.php on line 57

Hence confirming the issue.

Thank you.

@engcom-November engcom-November added Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Component: Backend Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Area: Framework labels Jun 25, 2024
@m2-community-project m2-community-project bot moved this from Ready for Confirmation to Confirmed in Issue Confirmation and Triage Board Jun 25, 2024
@github-jira-sync-bot
Copy link

✅ Jira issue https://jira.corp.adobe.com/browse/AC-12288 is successfully created for this GitHub issue.

Copy link

m2-assistant bot commented Jun 25, 2024

✅ Confirmed by @engcom-November. Thank you for verifying the issue.
Issue Available: @engcom-November, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

@engcom-Hotel engcom-Hotel added the Priority: P1 Once P0 defects have been fixed, a defect having this priority is the next candidate for fixing. label Jun 25, 2024
@m2-community-project m2-community-project bot added this to Ready for Development in High Priority Backlog Jun 25, 2024
@amcguireweb
Copy link

@hostep I am also using php 8.1, also why I am reporting this 😉

Why are you using PHP 8.1 with 2.4.7?
2.4.7 System Requirements

@hostep
Copy link
Contributor

hostep commented Jun 27, 2024

Because you can, it's allowed by the composer.json file, if Adobe doesn't want people to use PHP 8.1, they should remove it from their composer.json files. The composer.json file defines the dependencies of a package, if it states that it can work with PHP 8.1, 8.2 and 8.3, then the package should work with 8.1, 8.2 and 8.3.

Also, people really need to stop pointing to the system requirements, those aren't the real system requirements, but only a list of versions of software Adobe tests against. Yes, it's safer to stick to those versions, but if they allow other versions, then expect people to use other versions as well and report bugs about them.

@amcguireweb
Copy link

Because you can, it's allowed by the composer.json file, if Adobe doesn't want people to use PHP 8.1, they should remove it from their composer.json files. The composer.json file defines the dependencies of a package, if it states that it can work with PHP 8.1, 8.2 and 8.3, then the package should work with 8.1, 8.2 and 8.3.

Also, people really need to stop pointing to the system requirements, those aren't the real system requirements, but only a list of versions of software Adobe tests against. Yes, it's safer to stick to those versions, but if they allow other versions, then expect people to use other versions as well and report bugs about them.

It's allowed in composer.lock, sure, but if you'd look at the system requirements (like most people), you'd see that it's not listed. If they wanted you to use 8.1, don't you think they'd include it in the system requirements and test against it?

It sounds like more people need to pay closer attention to the system requirements, including you and the OP. What a silly take honestly. Good luck.

@hostep
Copy link
Contributor

hostep commented Jun 27, 2024

Look, personally I always try to use the latest available PHP version that is compatible with Magento, we don't use PHP 8.1 for Magento 2.4.7 on any of our projects.

I'm just saying that this bug report would have never existed if Adobe would have just removed the "so called" PHP 8.1 compatibility from their composer.json files. This has happened so many times in the past already and they still haven't learned. I just don't understand it.

They do state on their release notes the following:

Magento Open Source 2.4.7 is still compatible with PHP 8.1 for upgrade purposes only. PHP 8.1 is not supported and not recommended. Magento Open Source 2.4.7 core code, all bundled extensions, and all Adobe-owned extensions and SaaS services are compatible with PHP 8.3.

So yes, they claim "in words" that we should use at least PHP 8.2, but in technical terms they still allow for PHP 8.1. Also "for upgrade purposes only", what does that even mean? I don't see any good reason why you would want to use PHP 8.1 "during" an upgrade. Anybody who knows what this means?
I performed like dozens if not hundreds of Magento upgrades over the years and never even once needed I to use an in-between PHP version to get something done.


The only reason I'm complaining here, is that Adobe should make it so that their users can make fewer mistakes, defining the correct compatibility with PHP versions in the composer.json file is one such way of doing that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Framework Component: Backend Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Priority: P1 Once P0 defects have been fixed, a defect having this priority is the next candidate for fixing. Progress: ready for dev Reported on 2.4.7 Indicates original Magento version for the Issue report. Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch
Projects
High Priority Backlog
  
Ready for Development
Development

No branches or pull requests

8 participants