WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#41134 closed enhancement (duplicate)

Move __autoload compat to pevent deprecation warnings

Reported by: ayeshrajans Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9
Component: Bootstrap/Load Keywords: has-patch
Focuses: Cc:
PR Number:

Description

Hi everyone,
This is my first ticket in WP Trac, so I apologize in advance and appreciate shedding some lights if I'm doing anything unconventional.

With Wordpress now recommending PHP 7, I believe we should take care of compatibility issues with modern PHP versions. PHP 7.2 alpha is released, and I decided to see and fix any incompatibilities with it. 7.2 has not reached a feature-freeze yet, but we already know the deprecated features/functions in it.

Vanilla Wordpress 4.8, running on PHP 7.2.alpha2 (todays version) has one consistent notice:

Deprecated:  __autoload() is deprecated, use spl_autoload_register() instead in wp-includes\compat.php on line 502.

There is a comment in compat.php that says SPL can be disabled. This is true for PHP 5.2 users,but since PHP 5.3, SPL can not be disabled (http://php.net/manual/en/spl.installation.php). This noticed is raised by the PHP compiler itself, and not during the execution. This means the notice will be raised as soon as the compiler "sees" the function.

wordpress.org stats show that we only have PHP 5.2 user base of 4.7 (https://wordpress.org/about/stats/). Quite often, one need to recompile PHP in order to disable SPL extension, and it makes a PHP installation hardly usable with modern PHP applications.

I suggest that we remove the compat.php __autoload and its other compat functions (spl_register_*) to avoid the PHP notice in PHP 7.2, and I believe it's a fair trade-off.

Attachments (3)

41134.1.patch (2.7 KB) - added by ayeshrajans 2 years ago.
Patch to remove the spl_autoload polyfils and autoload declaration
41134.2.patch (3.1 KB) - added by ayeshrajans 2 years ago.
New patch with the SPL polyfill moved to a separate file
41134.3.patch (5.9 KB) - added by ayeshrajans 2 years ago.
Third time's the charm, I hope.

Download all attachments as: .zip

Change History (15)

@ayeshrajans
2 years ago

Patch to remove the spl_autoload polyfils and autoload declaration

#1 @schlessera
2 years ago

Alternatively, the polyfill can be put into a separate file and loaded conditionally based on PHP version.

@ayeshrajans
2 years ago

New patch with the SPL polyfill moved to a separate file

#2 @ayeshrajans
2 years ago

That's an excellent workaround Alain. Thanks. Attached a new patch for review.

#3 @ayeshrajans
2 years ago

  • Keywords has-patch added
  • Summary changed from Remove __autoload compat provided to Move __autoload compat to pevent deprecation warnings

#4 @jorbin
2 years ago

@ayeshrajans Welcome to trac and thanks for the ticket.
41134.2.patch doesn't contain the new file. If you specifically git add it before generating the diff, it should load correctly.

@ayeshrajans
2 years ago

Third time's the charm, I hope.

#5 @ayeshrajans
2 years ago

Thank you very much for your reply, @jorbin. I have uploaded a new patch with the new file as well, while feeling embarrassed about the second one :)

#6 @voldemortensen
2 years ago

This also requires users to be up to date with WP (which, yes, they should be), but if PHP updates happen before WP version updates happen, this will still trigger.

Not a huge deal, just something to think about.

#7 @ayeshrajans
2 years ago

@voldemortensen the approach has changed from the original ticket contents. Basically we offload the old __autoload() functionality to a new file, and include only if necessary (PHP 5.2, no SPL). For all other cases, the compiler wouldn't see the __autoload() declaration, preventing the PHP notice.

#8 @voldemortensen
2 years ago

Yes, I understand the approach. But let's assume a user is at a host who upgrades their PHP version to 7.2, but the user still has their website on WordPress 4.8. This patch will not be in their version of WP and the notice will still trigger.

Like I said, its not a huge deal, just something to think about.

#9 @jorbin
2 years ago

@voldemortensen WordPress 4.8 doesn't support PHP 7.2 (in large part due to PHP 7.2 not existing in a production capacity). When we get to the day that hosts are moving so fast that they are auto updating to alpha versions of PHP, I'll likely faint.

#10 @voldemortensen
2 years ago

To me, its not so much about hosts updating PHP as people not updating WordPress. 40.2% of installs are still on 4.7.x (according to wordpress.org/about/stats as of this comment). There has been a big push for PHP version upgrading as of late, and those numbers are moving relatively quickly.

But as I said before, this isn't a huge deal. It's just a deprecation notice. We fill error_logs up with _doing_it_wrong stuff all the time.

#11 @schlessera
2 years ago

@voldemortensen Yes, that's a valid point. There will be situations where people just don't intend to update core, but want to use PHP 7.2.

One option is to backport this change to older versions, just to be on the safe side.

However, on the other side, I would bet there are other issues with older WP versions when it comes to PHP 7.2...

#12 @swissspidy
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

#40109 addresses PHP 7.2 compatibility as a whole and is slated for 4.9 already.

Would you mind discussing things and uploading patches there? 41134.3.patch looks good to me at first glance.

Backporting fixes is another topic for itself. See #41135 for an example. Fixing fatal errors in older releases like noted in that ticket makes sense, but for a deprecation warning not so much in my opinion.

Note: See TracTickets for help on using tickets.