Critical Error on Settings change

Hi @schweizerschoggi,

Could you please enable the WordPress debugging function and share the contents of your debug.log file after trying to save changes again so that the error is logged?

Good morning Hector
Unfortunatly I don’t have access to the server configuration and the wp_config file – is there any other way I can help you with additional information?

• This reply was modified 1 year ago by SchweizerSchoggi.

You need access to the server in order to be able to read the log and see what the actual error is. Try reaching out to whoever does have access to the server and ask them to get that log for you.

[14-Nov-2023 13:06:47 UTC]
WordPress database error Deadlock found when trying to get lock; try restarting transaction for query DELETE FROM wp_options WHERE option_name = ‘_transient_timeout_wpp_bae9674c4df924dca73541b70a9f3037’ made by require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/thewaitingroom/front-page.php’), get_template_part, locate_template, load_template, require(‘/themes/thewaitingroom/template_parts/content-page.php’), the_content, apply_filters(‘the_content’), WP_Hook->apply_filters, do_shortcode, preg_replace_callback, do_shortcode_tag, slide_anything_shortcode, do_shortcode, preg_replace_callback, do_shortcode_tag, WordPressPopularPosts\Shortcode\Posts->handle, WordPressPopularPosts\Shortcode\Posts->maybe_query, WordPressPopularPosts\Cache::get, get_transient, delete_option

I tried to change the setting “Refresh cache every:” from “1 minute” to “12 hours”.

The log offers quite more rows, but this one above (as one of many similar) seems to be related to this setting.

I can send you the full log files (or save them somewhere) if needed.

What you have there is a database issue. That “Deadlock found when trying to get lock” error usually means that there’s at least one process blocking your wp_options database table which results in this particular error.

This is not being caused by WordPress Popular Posts itself, it’s just a consequence of another problem on your site.

I see.. ??
Here are the links to the complete logfiles then:

Webseite 1: https://file.io/1Y80ZuycCveN

Website 2: https://file.io/PMNvQKHOFf7Z

I hope you can find something in there that helps!

Unfortunately I don’t see any errors related to WordPress Popular Posts in those logs.

The ones I saw were two generic PHP errors related to running out of resources when WordPress tried to run a query, and one similar PHP error coming from the Forminator plugin (website #2):

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32768 bytes) in C:\home\site\wwwroot\wp-content\plugins\forminator\library\external\src\Forminator\woocommerce\action-scheduler\classes\abstracts\ActionScheduler_Lock.php on line 1

Regarding the “deadlock” issue, it might be a good idea to reach out to your developer or the people who maintain your website (or maybe consider hiring a freelance developer) and have them look into it for you.

From WordPress Popular Posts’ side, I can add a check to prevent fatal errors from happening but that won’t really fix the underlying issue you have there. I can share a test version of the plugin with said patch with you so you can test it out (which should allow you to update WPP’s settings, that’s the whole reason why you posted here right? :P)

Will give it a try with extended memory allocation first.

I’ll keep you posted!

We have 256MB allocated memory but it’s still not working.
There might be another plugin blocking this, as it’s been working on the test environment (where not all of the plugins are installed).
Will install one after the other on test and see when I am getting the error again.