Mehmet
Forum Replies Created
-
Hi @taojing10 ,
Thanks for your message, I really appreciate your patience.
The fix is still in progress, but I promise that as soon as it’s ready, I’ll share the download link with you right away and keep you fully updated.
If you need anything in the meantime, I’m here to help.
Best regards,Forum: Plugins
In reply to: [SlimStat Analytics] Slimstat Counting BotsHi @macwillard,
Thanks for reaching out.
Currently, Slimstat doesn’t have an option to block specific screen resolutions.
As a workaround, please make sure you’ve checked Slimstat > Settings > Exclusions and enabled Spammers and Bots.
This should help reduce bot-related bounce rate inflation.
Best regards,
Hi Iain,
Thanks for the detailed updates. I know this has been frustrating, and I appreciate all the work you’ve done so far.
The key issue is still the loopback error. As long as this error exists, the migration won’t run. The stuck refresh is only a symptom; the root cause is that WordPress can’t run its own background tasks.
This usually comes from the hosting environment or a plugin blocking the loopback request. Since the host confirmed the cron setup is correct, the next step is to fully rule out plugin interference.
Please try disabling all plugins again and check the Site Health loopback test immediately afterward. If the error disappears, we’ll know a plugin is blocking it. If the error remains, it’s almost certainly coming from the server or a security layer on the hosting side.
Once the loopback issue is resolved, the migration will run normally.
Just let me know what you see after testing. I’m here to help.
Best regards,
Hi @jfcypher,
Thank you for the detailed report and for providing all that information!
I’ve identified the issue with the Historical Total Visitors and Views not being included in your total
statistics. The historical data is being saved correctly in the database, but there’s a logic issue preventing it from being added to the total counts displayed throughout the plugin.The issue is located in: src/Service/Charts/DataProvider/SummaryChartDataProvider.php around lines 35-38
Next Steps:
I’ve escalated this to our development team with a proposed fix. They will review and implement the solution in an upcoming release. We’ll follow up with you once this is addressed.Thank you for bringing this to our attention!
Best regards,It’s been a while since your last message, so I’m just resolve this thread for now.
You can come back anytime if you’d like us to continue helping with this issue.
Best regards,
Hi @taojing10,
Thanks for reporting these issues.
Please enable WordPress debug by adding the following in
wp-config.php:define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Then reproduce the issue and check
wp-content/debug.logfor errors.Also, check your server’s PHP error log for any runtime issues.
To rule out plugin or theme conflicts, temporarily deactivate all other plugins and switch to a default theme like Twenty Twenty-X.
Collect your WordPress, PHP, MySQL, and plugin versions, along with any debug.log errors and screenshots of messages (without sensitive info). Share these to help reproduce the problem.
Once you have debug.log info, send it here and I can guide you further on resolving the issue.
Best regards,
Hi @iainpurdie,
I wanted to follow up with you regarding the migration issue.
Could you please check one thing on your site? Go to Tools > Site Health > Status and click on the “Passed” test. You should see a message like:
Your site can perform loopback requests
If you don’t see this, or you see an error related to it, the problem is likely server-related and should be reported to your hosting provider.
I’ll wait for your update so we can continue troubleshooting.
Best regards,
Hi @iainpurdie,
Thanks for checking those steps and getting back to me. Since the migration is still stuck, there are a couple more things that can help narrow this down.
Please ask your hosting provider to check the PHP resource limits on your server. If the server kills long-running processes, migrations may never move forward. These minimum values usually prevent that:
- memory_limit = 512M
- max_execution_time = 300
- max_input_time = 300
It’s also worth reviewing the hosting firewall or ModSecurity logs. Sometimes ModSecurity blocks background processes like data-migration or wp-cron. Please ask your host to check:
- ModSecurity logs for any blocked requests to
wp-cron.php - Any WAF rules that might interrupt long-running PHP processes
- If they find anything, whitelisting
wp-cron.phpusually resolves it.
Lastly, please enable PHP error logging so we can see if the migration is failing silently. You can follow this guide: Enable WordPress Debug Log
Once the log is active, let the migration run again and send me any related messages that appear in
debug.log. I’m here to help you get this sorted.Best regards,
Hi Tim,
Thanks for letting us know about this. I’m here to help.
I checked things on our side, and it looks like the Textplode gateway needs an update.
I’ve escalated this to our development team, and we’ll follow up with you as soon as we have progress.
Best regards,
Hi @iainpurdie,
Thanks for your patience. Since the refresh process is still stuck, you can reset it directly through the database. Please make sure to backup your database first to avoid any issues.
Once backed up, you can run the following queries in your database:
-- Remove the initiated flag
DELETE FROM wp_options WHERE option_name = 'wp_statistics_jobs';
-- Clear any stuck batches
DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_summary_totals_data_migration_batch_%';
-- Clear counters
DELETE FROM wp_options WHERE option_name IN ('wp_statistics_summary_totals_data_migration_total','wp_statistics_summary_totals_data_migration_processed');After doing this, the summary totals should be able to start refreshing again. Let me know if you need any guidance with these steps.
Best regards,
Hi Masoud,
Thank you so much for your kind words. I’m really glad to hear you’re enjoying the plugin.
If you ever need help, I’m here for you.
Best regards,
Hi @eftekhar,
Thank you for the wonderful feedback! We’re glad WP-Statistics is helping you gain clear insights into your site’s traffic and audience behavior.
If you ever need any help or have suggestions, feel free to reach out.
Best regards,
You’re very welcome, and thanks for the clarification.
I understand that keepingWP_DEBUGenabled is essential for your staging and testing workflow. We’ll make sure your suggestion is reviewed, because adding a throttle or environment check would definitely help reduce unnecessary noise in the logs.
Best regards,Hi @alirajabi129,
Thank you so much for your kind words. I’m really glad to hear everything looks great on your side.
Best regards,
Hello @hirngesicht,
Thank you for reporting this issue and for providing the log details.The message “Failed to decrypt token” is only logged when WP_DEBUG is enabled, because the logging function in WP Statistics writes errors to
debug.logexclusively under this condition.
That means the behavior you are seeing is expected while WP_DEBUG is set totrue, especially on staging or local environments.To stop these repeated entries from flooding your logs, you can simply disable debugging:
define('WP_DEBUG', false);or, if you prefer to keep debugging enabled but prevent log file flooding:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', false);Everything in the plugin continues to work normally, this is only a visual/logging issue, not a functional error.
If you would like to request improvements such as throttling the log messages or limiting them to production environments, you can submit feature suggestions here:
https://feedback.veronalabs.com/boards/wp-statistics
We appreciate your feedback and are always open to improving the plugin!
Best regards,
Mehmet