Indeed, for the case of local variables that were undefined before, this can usually be fixed in a straightforward way by initializing to NULL. The goal here is to get rid of the error or notice while preserving the original behavior (even if it was buggy).
This is IF this is your own custom code, or you have a strategy for maintaining patches on 3rd party code. (which you probably should). Another problem which has not been talked about much is code like this, which I have seen in multiple legacy code bases for Drupal 7 projects. Code like this is not considered good practice in Drupal 7, but it does exist. $element['field_category'][LANGUAGE_NONE][0]['#entity']->field_author_label['en'][0]['value']; This is crying for "trying to access property of non-object". Because the values in $element were usually created "elsewhere", and who knows if the value at that position is an object? Even worse: This might go unnoticed 99% of the time, but in a specific edge case the value might not be initialized and the website would crash with error in PHP8. The "minimal fix" to preserve behavior 1:1 is to call if (isset()) or if (!empty()) on the whole thing before every such construct, even if at the moment you are not aware of cases where it might fail. In the "else" case, you do whatever would have happened before if the value was NULL. On Thu, 12 Sep 2019 at 20:10, Lynn <kja...@gmail.com> wrote: > > On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <m...@newclarity.net> wrote: > > > > > > > Just a few weeks ago I was refactoring some particularly horrible code > > developed by previously employed developers — a code based that has a 1400 > > line function and many other functions 100s of lines long, and I added some > > initialization for variable and array elements prior to their use. > > > > Unfortunately my changes broke the code because the original developer > > using isset($var) as branching criteria. After finding this bug, I > > realized that this code base uses that technique frequently. I am know > > from lots of experience that this is a common technical among WordPress > > plugins. > > > > > The bug is not that you initialized the variable, it's that you initialized > it with a different value: https://3v4l.org/8mB8B > ``` > var_dump(isset($a)); > $a = null; > var_dump(isset($a)); > > // gives > bool(false) > bool(false) > ``` > > Whenever one of these errors will occur, you can initialize either the > array key or variable with null and it will work again without changing > behavior. If anything, Wordpress shouldn't be an argument to not improve > PHP, though I think it's important to consider the impact of a change, > including for the Wordpress community. However, I think most people agree > that the quality of Wordpress code and Plugins is highly debatable. I don't > like the idea of not being able to progress because Wordpress users won't > upgrade PHP. > > Regards, > Lynn van der Berg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
