[Ernest Marcinko]

Hi,

Thank you very much for the details it helped a lot.

After some debugging I have found the error stack trace:

[28-May-2026 09:30:09 UTC] WordPress database error Table 'scenesderdgreggy.wp_ajaxsearchpro_statistics' doesn't exist for query SELECT COUNT(*) FROM.wp_ajaxsearchpro_statistics. made by activate_plugin, do_action('activate_ajax-search-pro/ajax-search-pro.php'), WP_Hook->do_action, WP_Hook->apply_filters, WPDRMS\ASP\Core\Manager->activationHook, WPDRMS\ASP\Core\Init->activate, WPDRMS\ASP\Database\Manager->create, WPDRMS\ASP\Database\Manager->count
[28-May-2026 09:30:09 UTC] PHP Fatal error:  Uncaught TypeError: WPDRMS\ASP\Database\Manager::count(): Return value must be of type int, null returned in /home/scenesderd/www/wp-content/plugins/ajax-search-pro/src/server/Database/Manager.php:200
Stack trace:
#0 /home/scenesderd/www/wp-content/plugins/ajax-search-pro/src/server/Database/Manager.php(128): WPDRMS\ASP\Database\Manager->count('stats')
#1 /home/scenesderd/www/wp-content/plugins/ajax-search-pro/src/server/Core/Init.php(41): WPDRMS\ASP\Database\Manager->create()
#2 /home/scenesderd/www/wp-content/plugins/ajax-search-pro/src/server/Core/Manager.php(406): WPDRMS\ASP\Core\Init->activate()
#3 /home/scenesderd/www/wp-includes/class-wp-hook.php(341): WPDRMS\ASP\Core\Manager->activationHook(false)
#4 /home/scenesderd/www/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters('', Array)
#5 /home/scenesderd/www/wp-includes/plugin.php(522): WP_Hook->do_action(Array)
#6 /home/scenesderd/www/wp-admin/includes/plugin.php(703): do_action('activate_ajax-s...', false)
#7 /home/scenesderd/www/wp-admin/plugins.php(60): activate_plugin('ajax-search-pro...', 'https://www.sce...', false)
#8 {main}
  thrown in /home/scenesderd/www/wp-content/plugins/ajax-search-pro/src/server/Database/Manager.php on line 200

This indicated a database issue, where one of the options was corrupted (_asp_db_tables), likely during saving or when migrated from the staging environment. I have removed the option from the database so it’s get refreshed and now the plugin activates and will work as before. This is extremely rare and likely will never happen again.

I left it deactivated for you as I don’t want to change anything on your website without permission.

[Ernest Marcinko]

Hi,

Thank you for the feedback! I took some time to test this on every single major browser on both Mac and Windows platforms on 3 different computers just to be sure (Chrome, Firefox, Safari, Edge and Opera), but in every single case it works all right on my end. The changes reflect on both the settings and the front-end.
This is definitely not a cache problem at this point, but I still suspect something with the browser or something above that, the values can’t just reset randomly on their own, the plugin saves and serves back whatever was entered to the inputs.

Can you please try with a different browser, preferably google Chrome?

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi,

Thank you!

I have changed a couple of things (border, settings tick color) but the changes are apparent on my end: https://wp-dreams.com/assets/support/2026-05-26_OAgCpQL9L6.jpg

Do the colors reset back on the preview window as well? Do you have any auto-fill related browser extensions by any chance? I recall someome having a very similar issue, where a browser extension was just pre-filling some input fields and caused a very similar problem.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi!

Thank you for your kind words and the details, it helps a lot!

If the preview is all right, then it is always a cache issue – if there is no cache plugin active, then most likely Cloudflare or a CDN that you might be using.

I switched the theme to test, but then I realized I don’t know which page has the search (as on the screenshot) and I didn’t want to change or break anyting on your site. Can you let me know the page URL where the plugin is active? Thank you!

[Ernest Marcinko]

Hi,

Very soon actually! Version 4.29 is getting ready to be released in ~1 week, in which the synonyms is moved to a separate menu item with a new UI. It will feature taxonomy term result synonyms too.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

The main issue with that is, that something is extremely clogging up the wp_postmeta table in your database. If I re-enable the stock status ordering it will re-trigger the slowdown.

Have you checked the wp_postmeta table state? Have you tried adding indexes via the index sql plugin?
I suspect there might be a serious fragmentation problem with that table, or it has grown way too big, I strongly recommend checking it, otherwise if I make the change it will get slow because of the very slow response from that table.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi Boris,

Thank you very much for the details, it helps a lot.

There seems to be a general issue somewhere on the website. When I try to load the products page, it takes ~8 seconds to load, if I enter a search term on the products page on the back-end, then it’s over 30 seconds, so it looks like something might be adding a lot of workload to the server. I suspect that there might be a little too many plugins active and one or more is causing a massive workload for certain tasks. I strongly recommend removing some plugins which you may not use, it can significantly improve the overall site health. If you are using cloudflare enterprise, then I would disable all cache, query monitor and profiler plugins, those are already mitigated by Cloudflare itself.

The index is small, it’s only 10000 keywords, it should execute almost instantly. I did a debugging and found one issue, and that was the primary ordering using the stock status, but that shouldn’t be an issue at all. I changed it to relevance, now some bottleneck is gone and the search is a lot faster. I recommend checking the wp_postmeta table, perhaps do a degfragmentation on it, it seems like something might be wrong there, as all queries on the metadata table seem to be slowed down for some reason, maybe there is a table lock or a paging issue that could be solved via an optimize table commad. I also strongly recommend trying this plugin after you did a table optimize command on the postmeta table.

[Ernest Marcinko]

Hi Matt,

It was always a pain to handle custom javascript modules in live search containers as swapping out elements will automatically detach those actions. Usually these javascript events are initialized through a window readystate event, which is triggered after the search to re-attach the event handlers, but sometimes that just doesn’t work.

Can I check the issue somewhere? I can try to check what is triggering the events and perhaps suggest a custom code snippet to resolve it.

[Ernest Marcinko]

You cannot access this content.

[Author]

Posts