cancel
Showing results for 
Search instead for 
Did you mean: 

Magento Migration to PHP 8 Update

sivashchenko
Adobe Team

General PHP compatibility

 

Each PHP release adds performance and feature improvements which drive the PHP ecosystem forward.  We can only take advantage of PHP improvements if the Magento 2 project builds on these new features and removes support for deprecated PHP features. A few of these changes are significant, requiring us to think about our architectural approach, but many can be implemented without significant impact. For example, even some very specific features introduced in PHP 7.0 such as anonymous classes (new class), generator delegation (yield from), spaceship operator (<=>) have been implemented in the Magento codebase multiple times.

 

Our focus for the near future is ensuring Magento can take advantage of new PHP versions. To achieve this we need to continuously update Magento dependencies, codebase, and infrastructure. 

 

Most Magento dependencies have already released PHP 8-compatible versions. We have started updating dependency versions while maintaining compatibility with PHP 7.3.  After all dependencies are updated, we will be able to install the project on a PHP 8 environment and run tests, which should accelerate updates to the codebase and stabilization activities. 

 

After this work is completed, we will evaluate the number of backward-incompatible changes required and decide if PHP 8 compatibility should be merged to the 2.4-develop or 2.5-develop branch. 

 

Support 

 

The next step is full PHP 8 support. PHP 8 has plenty of new features! Just imagine how Magento code can change for the better using named arguments and how constructor property promotion can simplify the routine of new class declarations. There may be some creative opportunities around bew DOM Traversal and Manipulation APIs, Weak Map, etc. 

 

To be able to utilize new PHP features in our projects, we’ll need to drop PHP 7 compatibility. The decision on when PHP 8 support will be available in Magento will be based on the compatibility project resultsPHP version support timeline, and Magento release plans. 

 

Future 

 

We are eager to learn how you think we should use PHP 8 features in the Magento codebase. Share your ideas! 

 

The PHP 8 Compatibility project is open for your propositions and contributions. Check out the project announcement blog post for further details. 

16 Comments
MarkShust
M2 Certified

This is great.

 

What are your thoughts about making 2.5 a PHP-8-upgrade only release event, branched from the current 2.4-develop branch, and moving the current 2.5-develop branch to 2.6-develop? This would most likely allow parrallel 2.5.0/2.4.3 releases with an extremely similar mainline, and also aid in the upgrade of future Magento releases. Either that, or just make 2.4.3 a breaking release. The version naming does not follow SemVer, and we've had breaking "minor" releases like this in the past.

 

While I appreciate stability, I believe waiting another year to support PHP 8 is going to thwart Magento adoption for new projects. I also understand they are entirely different frameworks, but those of the like of Laravel have had near-day-one support of PHP 8, are setting the standard on how we should probably be approaching language-level upgrades.

sivashchenko
Adobe Team

Thanks for the comment @MarkShust!

 

I would love to see PHP 8 support in Magento as early as possible, but a smooth upgrade process is very important too. We will definitely consider your ideas!

Vinai
Magento Master

I think it would be best to make the code base PHP 8 compatible, while avoiding PHP 7.4 incompatible changes until 7.4 is no longer supported.

Some of the new PHP 8 features - like named arguments - have not proven themselves to be a good addition in terms of code-maintainability.

Using them too quickly might introduce a burden or force backward incompatible changes down the road.

 

The new syntactic features PHP 8 offers are a sugar coating. They make some very specific code look nicer, but they aren't a real game changer in terms of enabling new patterns.

 

Why not wait a year or so until the new features have proven themselves effective and new good practices have emerged?

 

PHP 8 compatibility in general however is a good thing. That should be achieved as soon as possible. This will allow developers working on specific projects to gain the needed experience with the new syntactic features, and will allow shops to benefit from the performance and scalability improvements new PHP releases offer.

 

sivashchenko
Adobe Team

Good point, @Vinai, thanks for sharing!

 

Yes, we are currently focused on PHP 8 compatibility, still keeping the php8-develop branch compatible with PHP 7.3 and 7.4.

 

Named arguments feature appears to bring more flexibility to the development, what challenges do you think they will introduce to the code maintenance?

Vinai
Magento Master

Named arguments make variable names part of a methods public API that where previously an implementation detail.

 

Even fixing typos in argument names now are backward incompatible changes.

 

But for the sake of the argument, let's assume we don't commit typos anymore because the IDE spellchecker.

 

Even so, the best name for a method argument variable often only becomes obvious over time through use.

When I have to look up some implementation detail of a method again and again, maybe that can be improved by changing the name of an argument.

 

However, when that argument is used with named parameters, that change will break the call site that relies on the old argument name.

Personally I think it would be nice if the feature was opt-in on a method by method basis.

As it is currently I hope the feature is not used by developers at all, or only when calling methods that have not changed in a loooong time, which means their argument signatures where able to stabilize.

Then again, I might be wrong, and all code will be much more understandable when named arguments are used.

That's why I think it would be valuable to allow time to gather experience before using new features in platform code.

mageklein
Senior Member

@sivashchenko 

 

To support @Vinai : Named argument is hell, it allows inconsistency and finally does the opposite of what it was initially introduced for.
Some exemples of what could happen:

 

https://3v4l.org/gdPn7

https://3v4l.org/icX5t

https://3v4l.org/Kor4l

https://3v4l.org/PpPhE

https://3v4l.org/ndaLt

 

Check this thread: https://twitter.com/Ocramius/status/1356174009675739140

Vinai
Magento Master

Those examples are so funny Smiley Very Happy

I hadn't even thought of inheritance.

Someone in the twitter thread suggested using static code analysis to prohibit argument renaming in implementations / subclasses. A complex fix to a problem that could be easily avoided by officilally declaring arument names not part of the public api.

Looks like named arguments lift the whole brittleness of deep inheritance chains to a new level.

sivashchenko
Adobe Team

Good examples on named arguments, thanks @mageklein and @Vinai! Are there any PHP 8 features that you love and would like to use?

mageklein
Senior Member
MarkShust
M2 Certified

I think the focus should be on making the codebase PHP8-compatible, and focus on implementing features at a later date. This will give developers a chance to form proper best practices within the likes of custom code and third-party modules, but we can't do so until we can actually work with a codebase that supports PHP8. Waiting another year is delaying us using these  awesome features which we are already using today with other frameworks. 

The biggest enhancement for Magento would be promoted properties. Anything that makes our life easier and cuts back on typing & boilerplate will be a big boon to

developers. 

Vinai
Magento Master

@sivashchenko 

Are there any PHP 8 features that you love and would like to use?

Single-line PHP 8 attributes are useful (and PHP 7.4 backward compatible!) and could be a nice addition to some phpdoc conventions.

 

Once PHP 7.4 is no longer supported, I think union types would be quite useful.

Constructor property promotion would be nice to have.

 

 

diego_jh_mag
M2 Certified

This is fantastic.

 

I think developers will be really happy to get PHP8 support as soon as possible, it should make developing with PHP less cumberson and more enjoyable in general. Not strictly unique to PHP8, but I personally would love to see Magento relay on the type system more for things like REST API Interfaces, instead of relying on doc blocks. I think something smart could be done with the new PHP Attributes feature, perhaps to standarize how methods and classes are maked as deprecated and having this help better report when deprecated methods are being used. You could even use them in order to eliminate some of the configuration that is now done via XML such as plugins/observers, but that needs looking into carefully and I wouldn't do anything that changes how something works and then having to maintain 2 different ways of doing it.

 

In general I'd love to see Magento use the type system more, things like having strict types enabled at the top of most core files would be great, it helps to see type issues sooner rather than later, specially with the introduction of union types, etc.., This would also improve phpstan support, at the moment phpstan doesn't play well with Magento because some of the Magento docblocks are unfortunately not correct. For example it might say that a function returns a float, when it actually returns a string, and so on.

 

Kind Regards,

Diego

 

 

Vinai
Magento Master

Looknig at the PHP suppoorted versions roadmap, I think it would be good to wait until 28 Nov 2022 until PHP 7.4 compatibility is dropped from Magento 2..

coderimus
M2 Certified

@sivashchenko @Vinai 

Working with this project (PHP8 upgrade), I faced one thing that should also be considered: the 3rd party modules, which Magento uses in dependencies, with the PHP8 compatibility release represented and continue to release BIC changes. This makes upgrade challenging. In that case, I think we can complete upgrade and then keep it as up-to-date as possible before merge to the active Magento mainline (2.4 or 2.5) Also, what about reviewing dependencies and decrease their number?

Vinai
Magento Master

@coderimusThat is a good point. Sadly many libraries in the PHP ecosystem drop support for older PHP versions very eagerly. This is very harmful for enterprise projects that need stability.

I hope most libraries will publish at least one version that is PHP 8 and at the same time PHP 7.4 compatible.

Then Magento could stick with that version until it's time to drop PHP 7.4., too.

 

Reducing the number of dependencies would be good, but I would expect that to be a struggle. Magento seems to depend on each and every library out there Smiley Happy

 

 

Another thing to consider are core bundled Magento extensions. Is there a way to enforce they release versions compatible with the same PHP versions as the Magento core? If not, they could dictate the PHP versions Magento supports, which would be strange.

 

MarkShust
M2 Certified

What are the downsides of having 2.4.3 have full PHP 8 support, but not including any language-level updates or improvements so it's also compatible with 7.4? Then 2.5.0 can introduce breaking PHP 8 updates in the core.

This will put PHP 8 in the hands of devs much sooner, while also supporting both versions. Those that don't want to upgrade to PHP 8 can then do so at their peril by staying on 2.4.x, while also reaping the benefits of being able to upgrade to PHP 8. This will also help mitigate the risk of staying on PHP 7.x forever and having to maintain outdated packages, as well as ease the transition of upgrading to 2.5.

With the introduction of security patch updates for previous versions, there's also less risk now of introducing breaking changes, as they can always stay on older versions before upgrading (or choosing not to).