Hi @kvieira90,
Sorry to hear you’re having such issues after clearing cache.
Could you please explain a bit more on “non-admin site”, what exactly are you referring to?
Can you enable debug log which should show us where the 500 error is coming from?
You can enable debug log in your wp-config.php file (located in root WP folder) by replacing define(‘WP_DEBUG’, false); with this code:
// Enable WP_DEBUG mode
define('WP_DEBUG', true);
// Enable Debug logging to the /wp-content/debug.log file
define('WP_DEBUG_LOG', true);
// Disable display of errors and warnings
define('WP_DEBUG_DISPLAY', false);
@ini_set( 'log_errors', 1 );
@ini_set( 'display_errors', 0 );
Visit the page with the error and this should create debug.log file in your wp-content folder that could tell us what is going on.
Can you please upload it any file sharing service like GDrive or Dropbox and share the download link here so we can check it out?
Cheers,
Predrag
So I’ve narrowed it down to a DB issue by setting up my site again with a brand new wordpress install, our theme, and all our plugins, and once I verified that was all set, moved over our DB at which point the issues arose. What I meant by non-admin is the wp-admin part of the site works as expected but the customer facing side is completely down.
Looks to be a max memory limit issue but wasn’t happening before attempting to clear cache with your plugin.
[30-Sep-2020 13:05:08 UTC] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32768 bytes) in /home/klkhfxqa4j1x/public_html/wp-content/themes/zonex/vc_templates/vc_row.php on line 1
[30-Sep-2020 13:05:08 UTC] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 45056 bytes) in /home/klkhfxqa4j1x/public_html/wp-includes/functions.php on line 4609
[30-Sep-2020 13:05:08 UTC] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 45056 bytes) in Unknown on line 0
Looks like the issue is comming from the wp_options table. Not sure if there’s anything Hummingbird adjusts within that table. I assume there is, just figured I’d let you guys know in-case you can help. There are vast number of rows in that table so going through one by one reviewing data will take forever. Thank you
Hi @kvieira90
Sorry to hear you are having this problem.
The Hummingbird will write to the database when enqueuing the assets on Hummingbird > Assets Optmization, or when you run a cleanup on Hummingbird > Advanced Tools > Database Cleanup.
Could you try to repair your database and optimize it?
You can find more on:
https://www.wpbeginner.com/wp-tutorials/how-to-fix-the-error-establishing-a-database-connection-in-wordpress/
Could you also try to reset the plugin settings and see if this will make any difference?
On Hummingbird > Settings
However, make sure to run the website on PHP 7.4, set a nice max_execution_time and PHP/WordPress memory.
https://premium.wpmudev.org/blog/increase-memory-limit/
Let us know the result you got.
Best Regards
Patrick Freitas
I’ve just spent the week rebuilding the entire site locally by bringing in the tables I could salvage and making any changes I could to fix things. Just figured I’d give you guys a heads up that your tool frags db’s and maybe you can look into fixing it. Won’t be using HummingBird again but it did seem great while it lasted.
Hello @kvieira90,
I’m sorry to see you go through a lot of issues but the scenario here does not make us clear on where exactly the issue has been. We have tried to replicate some on a few huge test sites but could not replicate the same on our end.
Also, the error you have stated looks to be from the theme so I suppose something on the theme pulled up or was requesting up a lot of memory.
Could you also point out a few instances where you feel the plugin fragmented the DB? We do have the option under the Hummingbird-> Advanced tools-> Schedule section to schedule clean-ups on a daily weekly or monthly basis which should keep things clean too.
Thank you,
Prathamesh Palve
You’re probably not wrong. I imagine the plugin failed due to needing more memory than was available, but there should be some backup done before the cache reset and next load of plugin should revert if failed.Just an idea.
Hi @kvieira90
Thank you for the suggestion.
Do you mean backup the cache files, and in case anything goes wrong the plugin could revert the cached files?
I’m afraid we would have two issues on this, first, it would require more memory, and another problem if the issue is a fatal error, the plugin won’t be able to revert the process.
Best Regards
Patrick Freitas
Touche, figured I’d throw an idea out. Thank you
