[Closed] When Toolset Types and Query Monitor are activated together, admin-ajax failed

[Author]

Posts

[fabriceD-3]

Hi,

I activated Query Monitor to investigate an issue with Avada Template (they made request before proxy variable are set). It's for context, not your problem 🙂

During my tests, I discovered that when Query Monitor and Toolset Types are both activated, /wp-admin/admin-ajax.php go in not answering (HTTP 502).

If I desactivate one (anyone), the issue disapeares.

Do I have a possibility to log in Toolset what is interacting with Query Monitor to keep both activated ?

Best

[Nigel]

Hi there

Toolset doesn't have any kind of integration with Query Monitor, but Query Monitor tracks every database operation that occurs with every request, which inevitably means it interacting in some way with any code that interacts with the database, that would include Toolset.

Is there any particular operation you undertake that uses an ajax request that triggers the 502 request?

If you can give us the steps of what you are doing which triggers the problem, then we can try to reproduce it on a test site.

[fabriceD-3]

To reproduce, you can active the two plugins.

Thank go to Appearance > Menus and try to add an element to the menu.
This is done with admin-ajax.php and it's not working.

[Nigel]

I tried that on my local test site just now and it works okay, and I can see the browser network tab that the ajax completes with a 200 code.

So it seems there is something particular about your site or server that contributes to the problem.

Can you check if the same happens after deactivating all plugins except for Types and Query Monitor and switching theme to twentytwentyone?

If it doesn't, then it should be possible to determine what else is required for the issue to occur by a process of elimination.

If the issue does still occur, then can you check your debug log to see if there are any errors or warnings that might explain the problem?

If you haven't already, turn on the debug log by editing your wp-config.php file and change the line with WP_DEBUG like so:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DISABLE_FATAL_ERROR_HANDLER',true);

That will create a debug.log file in your /wp-content/ directory which you can examine in any text editor. Try repeating the steps again and then inspect the log. If you don't find the debug.log file it means it didn't generate any warnings or errors.

[fabriceD-3]

Hi,

Just to notify, I didn't have time for now to work on this issue;

I will go back to you when it's done from my side

Best

[Nigel]

No problem. Let me mark this as awaiting your feedback so it's not sitting in my queue, and if the support robot warns that the thread will be closed you can just reply again to keep it open.