php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #81675 Undocumented change in get_class_vars behaviour with static properties in 8.1
Submitted: 2021-11-30 10:56 UTC Modified: 2021-11-30 14:24 UTC
Votes:6
Avg. Score:4.2 ± 0.7
Reproduced:5 of 5 (100.0%)
Same Version:5 (100.0%)
Same OS:3 (60.0%)
From: diede at yoast dot com Assigned:
Status: Verified Package: Scripting Engine problem
PHP Version: 8.1.0 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: diede at yoast dot com
New email:
PHP Version: OS:

 

 [2021-11-30 10:56 UTC] diede at yoast dot com
Description:
------------
I have a feeling that `get_class_vars()` received a bugfix. Previously it included the current value of a static property, but now returns the default/initial value instead. This now matches the documentation, but the behaviour of previous PHP versions didn't match the documentation.

I can't find anything in the changelogs, docs and RFCs. Here's where we looked:
- https://github.com/php/php-src/blob/php-8.1.0/UPGRADING
- https://www.php.net/manual/en/migration81.php
- https://www.php.net/manual/en/function.get-class-vars.php
- https://wiki.php.net/rfc#php_81
- https://github.com/php/php-src/blob/php-8.1.0/NEWS


This could at the very least be considered a breaking change and should be documented.


Test script:
---------------
<?php
// https://3v4l.org/RjVk0
class MyClass {
    public static $myProperty;
}

MyClass::$myProperty = 3;
var_dump( get_class_vars( MyClass::class ) );

Expected result:
----------------
// Output for 7.3.0 - 7.3.33, 7.4.0 - 7.4.26, 8.0.0 - 8.0.13
array(1) {
  ["myProperty"]=>
  int(3)
}

Actual result:
--------------
// Output for 8.1.0
array(1) {
  ["myProperty"]=>
  NULL
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-11-30 12:21 UTC] cmb@php.net
-Type: Bug +Type: Documentation Problem -Package: *General Issues +Package: Scripting Engine problem
 [2021-11-30 12:21 UTC] cmb@php.net
3v4l.org runs without OPcache.  With OPcache enabled, you already
got the same result as with PHP 8.1.  This inconsistency[1] has
now been fixed[2]; I'm not sure whether this should be documented,
given that OPcache is likely always enabled in production
environments at least.

[1] <https://bugs.php.net/bug.php?id=80821>
[2] <https://github.com/php/php-src/commit/3eb97a456648c739533d92c81102cb919eab01c9>
 [2021-11-30 13:40 UTC] bugs dot php dot net_nospam at adviesenzo dot nl
> I'm not sure whether this should be documented,
given that OPcache is likely always enabled in production
environments at least.

Well, considering it took us a not insignificant amount of time to pin down what was causing the difference in behaviour and that the change removes a difference between typical production vs develop environments which people may have run into and got stuck on trying to figure out before, I think documenting this would be useful, if for no other reason than to save other people running into the same/similar situation debug time.
 [2021-11-30 14:11 UTC] nikic@php.net
As the behavior was there for quite a long time, adding a note for buggy behavior with PHP < 8.1 without opcache seems reasonable.
 [2021-11-30 14:24 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2022-09-22 10:07 UTC] pedder55655 at gmx dot net
I can can confirm this. 

I use a static object for localisation and modify the static variables upon load-up with those from the user's preference. After upgrade to php 8.1, they all see the default language as my property assignments have no effect anymore.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Wed Nov 30 16:05:52 2022 UTC