This appears to fix #453, #498, #499 and possibly more issues.

[wisskid]

Will need further testing and unit tests.

Using the @-operator will supress errors generated in code wrapped in the isset() call. That's not good. Better than what we have now, but not ideal.

[wisskid]

Another approach would be to improve the regex that tries to determine whether $p is a variable. This might do it:
^\$[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*((->)[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*|\[[^\]]*\])*$

[wisskid]

Slight improvement to balance out brackets with nested brackets: ^\$[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*((->)[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*|\[.*]*\])*$

[uwetews]

Please note that the issues at handling isset() and empty() calls can get much more complex.
If the variable tested is an object its properties can be variable.
Array indexes may contain variables.
You will get runtime errors when some of this subvariables are undefined.
I was working on a solution before I got ill last year.
I should be able to work on this problem in about 2-3 weeks

[wisskid]

@uwetews great to hear you are coming back! I was thinking a truly proper solution would require lexing/parsing the parameter to ensure it's a valid php variable instead of using a regex. But my solution posted above seems pretty effective too.
I'd love to hear your thoughts. Get well soon!

[wisskid]

@uwetews a similar fix in libs/plugins/modifiercompiler.default.php would fix #336

[glensc]

please note that you can't really get by pattern match accurate result whether
empty() argument is non-variable.

see discussion and example here:

• False Positive: PHPCompatibility.PHP.EmptyNonVariable.Found PHPCompatibility/PHPCompatibility#410