Open daigo75 opened 10 months ago
It looks like Query Monitor attempts to emulate the Debug Bar plugin when that plugin isn't active. PUC has limited Debug Bar integration, so under certain conditions, it adds a callback to the debug_bar_panels
filter that QM calls here:
Debug_Bar::init_panels() wp-content/plugins/query-monitor/classes/debug_bar.php:53
During that, PUC tries to load some classes related to the Debug Bar. Which apparently doesn't work because the Debug_Bar_Panel
class doesn't exist. I think this probably happens because QM autoloads its version of Debug_Bar_Panel
, and PUC specifically disables autoloading for the relevant class_exists()
check.
However, I can't figure out what scenario could actually lead to that chain of events. You need a situation where the Debug_Bar
class already exists but Debug_Bar_Panel
does not. Maybe something else makes QM load Debug_Bar
earlier than usual? Do any of the other plugins on those sites use Debug Bar? Their tabs might also show up in QM.
Unfortunately, I don't have any other information about the issue. The affected sites, both of which threw the error between yesterday and today, belong to clients, but I don't have access to them, due to data protection policies. Neither client is tech savvy, nor do they have a person who can provide technical details, therefore we're still at a preliminary investigation level, at least until someone can provide more details about the conditions that cause the issue.
Well, I have an idea about how the error can be avoided, but I don't have a way to verify if it will actually work since I can't reproduce the error. And if you don't have access to the sites, you might not be able to verify the fix either.
If you'd like to try it anyway, switch from version 5.1 of PUC to what's currently in the master
branch.
I would be happy to try the master branch, but I wasn't able to reproduce the error myself, either. Due to that, there's no way of knowing if the fix will work.
I will ask the clients if they could grant access to a staging site for testing. If they agree, I will report back here. If not, I will have to wait until I get the chance to run the test.
Noting I hit the same error this morning. Deactivated Query Monitor via WP-CLI so I could access the Dashboard.
@YahnisElsts Just a quick update. Another user reported the same error. Unfortunately, I couldn't get access to a staging site (they are all very strict with the access), so I couldn't test the proposed fix. If there's going to be a new version coming soon, please let me know and I will update my plugins too.
I could create a new release pretty easily, but I'm a bit reluctant to do that when I don't know if the fix actually works.
@YahnisElsts What's the best way to test (if I hit it again)? Do I run the develop branch, or just change that line manually in my plugin on the site with issues?
I think either would work. Changing the line yourself might be slightly safer because the repository could (at some point) include other, unrelated changes.
@YahnisElsts I prepared a build of my plugin that includes the proposed changes, then asked some of my customers to try it on their sites. After installing the update, the error went away. It reappeared shortly after, due to the presence of another plugin (Admin Menu Editor Pro) which includes the "old", unpatched version of the Plugin Update Checker library, but that is a further confirmation that the patched version works.
All right, I've made a new release, version 5.3. I will also update Admin Menu Editor Pro sometime this week.
I came across the error on two sites that were running the Query Monitor plugin. I couldn't reproduce the error on my development servers, but I was able to fetched the call stack from the sites:
The "wc-aelia-foundation-classes" is my plugin, which loads the library. It's not doing anything in this scenario phase, it just looks like the events triggered by the Query Monitor are intercepted by the update checker, which can't find one of the classes, for some reason.