Local Community

PHP 7.4.20 required for Xdebug 3.1.x

With a note from @ben.turner I understand that getting a built-in current version of PHP v7.4 is considered a Feature Request.

RE: “As for why Local’s versions of PHP are slightly behind the published minor versions of PHP…”

OK now, that sort of understatement was funny when the word “slightly” was just getting moldy. But the supported version of v7 is now painfully behind the current version. The problem is that there are dependencies on v7.4.x updates that we can’t use until Local gets an update. Specifically, we can’t load the latest Xdebug v3.1.4+ because of this.

Why do we need to update Xdebug? Because I feel incompetent when trying to diagnose an issue, Derek asks what version is installed, and I have to admit that it’s 3.0.4 rather than 3.1.4. What’s the issue? It seems a recent VSCode update broke the way PHP arrays are displayed on mouse-over when in debug mode. Why is that an issue? Reading the contents of large variables is now difficult.

“Why doesn’t the latest Xdebug support 7.4.1 anymore?” : From Xdebug installation wizard : “PHP version 7.4.1 is not supported on Windows due to missing exported symbols in zlib, upgrade to at least 7.4.20.

“But if it seems like a VSCode issue, why should Local (WPEngine) be pressed to update?”

It’s only reasonable to ensure that we’re up on all of the latest software to ensure this isn’t due to some issue that was fixed long ago in some other tool in the stack. You guys would reasonably ask us to upgrade Local if we had an issue for you, we ask our users to keep current so that we can provide effective support, and that’s the process we all understand that we need to follow.

So - now I’m going to go look at VSCode issues and source, and maybe ask that team for help, and let’s just hope no one asks the logical questions: “What tools are you using? Are those tools current?”. EDIT: The issue is in the VSCode debugger and I dodged that bullet. :wink:

I’ll do the legwork - I’m just conveying to you folks that keeping the stack up to date isn’t just a “feature” to be considered for a future release - there is some priority associated with getting this internal procedural/policy issue addressed rather soon.

Thanks for your time.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.