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

[GrimLink]

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”.

[m2-assistant]

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:

• @magento give me 2.4-develop instance - upcoming 2.4.x release
• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

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.

[nuwaus]

I have the same issue too, after upgrading to 2.4.7

[hostep]

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]

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]

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

[m2-assistant]

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]

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.

[github-jira-sync-bot]

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

[m2-assistant]

✅ 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.

[amcguireweb]

@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]

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]

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]

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.