Forum Replies Created

Viewing 15 replies - 151 through 165 (of 410 total)
  • Mehmet

    (@gandomi)

    Hi @fandoshop,
    Thank you so much for your kind words. We really appreciate it!
    Best regards,
    Mehmet

    Mehmet

    (@gandomi)

    Hi Ranveig,

    Thank you for the detailed information and screenshots. From what you described, it seems the WP Statistics CSS/JS files are being blocked, most likely by a browser AdBlock/privacy extension or by your hosting firewall or security rules. It could also be a file permission or caching issue. Please try opening the Statistics page in a different browser or in a private/incognito window without any extensions to see if the styling loads correctly. If it still appears broken, check the Network tab in DevTools for any blocked or failed CSS/JS files, and you may also want to ask your hosting provider if any security rules are preventing these files from loading.

    Could you let me know if the page looks correct in another browser?

    Best regards,
    Mehmet

    Mehmet

    (@gandomi)

    Hi @mosimages,

    Thanks for your patience. Our development team has reviewed the issue, and it seems the main cause of the delay is related to Redis and network latency, not WP Statistics itself.

    A few important points and steps:

    1. If your Redis server is hosted outside the same network as your website, network delays can significantly slow down data retrieval.
    2. When WordPress requests a large number of records from Redis, it can further add to the slowness.
    3. As a temporary solution, you can disable Redis for the admin dashboard by adding this to your wp-config.php file:

    if ( defined('WP_ADMIN') && WP_ADMIN ) { define( 'WP_REDIS_DISABLED', true ); }

    1. Also, you can temporarily deactivate the Redis Object Cache plugin and check if WP Statistics starts reporting normally. This will help confirm whether Redis is causing the delay.

    To help us investigate further, please provide the following:

    • Go to Dashboard → Settings → Redis (wp-admin/options-general.php?page=redis-cache) and share the Client, Database, Connection Timeout, Read Timeout, Redis Version.
    • On the same page, check the Diagnostics and Metrics tabs and share the info, including Redis response times.
    • Confirm whether your Redis is self-hosted on your server or managed by a third party.

    If possible, please open a support ticket directly at support@veronalabs.com so we can track and respond to this issue faster.

    Thanks again for your support and patience!

    Best regards,
    Mehmet

    Mehmet

    (@gandomi)

    Hello @toxicum,

    Thank you for your patience!

    We’ve prepared a dedicated version of SlimStat just for your setup to help us pinpoint the issue with the 12-month graphs. Here’s how you can use it:

    1. Download the plugin
    2. Install the plugin
      • Go to your WordPress Admin → Plugins → Add New → Upload Plugin
      • Choose the ZIP file you just downloaded and install it
      • Activate the plugin
    3. Enable Debug Logging
      • After activation, visit the SlimStat Admin page
      • You’ll see a debug notice at the top if logging is active
    4. Reproduce the Issue
      • Switch your graph to the 12-month range (like before) so the issue occurs
    5. Send us the log
      • Click “Download Debug Log” from the admin notice or check the file at wp-content/uploads/
      • Please send this log to us so we can apply a precise fix

    This will help us resolve the problem quickly and accurately.

    Thank you again for your cooperation!

    Best regards,
    Mehmet

    Mehmet

    (@gandomi)

    Hi @mansourikhah,

    Since we haven’t heard back from you in a while, I’ll go ahead and resolve this ticket for now.

    The fix we mentioned earlier has already been released in the latest version of the plugin, so please update to the newest version to ensure the issue is resolved on your site.

    Best regards,
    Mehmet

    Mehmet

    (@gandomi)

    Hi Dilip,

    Thank you for sharing the screenshot link. I can confirm that bot exclusions are enabled correctly in your setup. In this section, you can also add any additional bots you’d like to exclude.

    Regarding your monitoring tool: yes, those HTTP health check requests can indeed explain the sudden increase in visitor counts. Please review the IP logs, and if you find recurring IPs from the monitoring system, you can exclude them here:
    Statistics > Filtering & Exceptions > IP Exclusions

    This should help align the visitor numbers more closely with your actual authenticated users. I’ll be looking forward to hearing back from you on how it goes.

    Best regards,
    Mehmet

    Mehmet

    (@gandomi)

    Hi Dilip,

    Thank you for your follow-up and for sharing the screenshot. Unfortunately, I wasn’t able to view the screenshot you attached here. Since the WordPress.org forums don’t allow direct attachments, you can instead upload the image to an external service (e.g., Imgur, Dropbox, Google Drive) and share the link with us.

    Regarding the Anonymous Users option: since this is an internal portal and all users authenticate via SSO, in principle there are no anonymous visitors. That means enabling the Exclude Anonymous Users setting is not strictly necessary. However, it also won’t cause any issues if enabled, and in some cases it can help make your statistics more precise.

    I’d also recommend reviewing the IP addresses being logged in your visitor statistics. Sometimes internal services such as monitoring tools, health checks, or other automated processes can generate requests that are counted as visitors. If you notice any such recurring IPs, you can exclude them by going to:
    Statistics > Filtering & Exceptions > IP Exclusions

    This should help narrow down the discrepancy and ensure the reported statistics reflect your actual user activity more closely.

    Thank you again for your detailed input, and I appreciate your patience while we work through this together.

    Best regards,
    Mehmet

    Mehmet

    (@gandomi)

    Hi @ranveig,

    Sorry for the delay in getting back to you, and thank you for your patience.

    From what you described, it looks like the WP Statistics CSS/JS files are not loading in your dashboard. This usually happens because of:

    • Cache/CDN or security rules blocking the plugin’s styles and scripts.
    • Conflicts with other plugins or the theme (even if WP Rocket is off, other plugins may interfere).
    • File permission issues on the server that prevent CSS/JS from being read.

    Could you please help us by:

    • Opening the Statistics page → press F12 → Console/Network and check if there are any errors or blocked CSS/JS files (404/403).
    • Temporarily disabling all other plugins except WP Statistics to test.
    • Letting us know your WordPress, PHP, and WP Statistics versions.
    • Sharing a screenshot of the broken page and the console if possible.

    This info will really help us identify the root cause and guide you to a fix.

    Thanks again for your patience!

    Best regards,
    Mehmet

    Hi @schwefel,

    The chart you’re looking for is still available, just in a slightly new location in version 14.x. You can find it by going to:

    Statistics → Content Analytics → Pages

    On this page, you can:

    • Select the date range you want
    • See the top pages
    • View the number of visitors and page views for each day

    I hope this helps you find all the info you need.

    Best regards,
    Mehmet

    Hi @medway,

    Thanks for reaching out.

    Could you please clarify a bit more about the mismatch you’re seeing? For example, could you send a screenshot of where you see the total visitors vs. the geographical visitors?

    Sometimes in the Geographical stats, there’s a “not set” category for visitors whose location can’t be detected. Also, it’s possible the historical data is being included somewhere, or there could be a misunderstanding about which widgets are showing which numbers.

    A screenshot or more detail about the exact widgets or pages you’re looking at would help us pinpoint the issue.

    Best regards,
    Mehmet

    Hello @toxicum,

    Thank you very much for providing these details and testing all those steps.

    We’ll continue investigating the issue on our side and will get back to you with an update. I’ll follow up with you as soon as we have more information.

    Thank you again for your patience!

    Best regards,
    Mehmet

    Hi Dilip,

    Thank you for reaching out with such detailed information.

    The visitor discrepancy you’re seeing may be due to:

    1. Bots or crawlers: From August 5th, automated bots or monitoring tools may have started checking your site more frequently. If bot filtering isn’t enabled, they will be counted as visitors. You can manage this here:
      Statistics > Settings > Filtering & Exceptions > Robot Exclusions
    2. Visitors ≠ Logged-in users: WP Statistics counts each page load or request from an IP as a visitor. This can include multiple sessions from the same person, proxy users, or users whose IPs change. SSO, on the other hand, only counts authenticated users. If you want to track only logged-in users, go to:
      Statistics > Settings > Filtering & Exceptions > Anonymous Users
      and check this option to exclude anonymous visitors.

    Applying these filters should help the reported visitor numbers align more closely with your actual user activity.

    Best regards,
    Mehmet

    Hello @toxicum,

    Thank you for your update and for sharing the new screenshot.

    Could you please try clearing your cache if you’re using one? Also, if possible, kindly disable the Autoptimize plugin temporarily to check if the issue might be related to caching.

    In the meantime, we’ll continue investigating this on our side and keep you updated.

    Thank you again for your cooperation and patience!

    Best regards,
    Mehmet

    Hello @qerghgfjkgk,

    Thank you so much for your kind words!
    It really means a lot to hear that, and we truly appreciate your patience and understanding while we worked on the fix.
    You seem like a really thoughtful and nice person, and it’s been a pleasure helping you.

    Best regards,
    Mehmet

    Thread Starter Mehmet

    (@gandomi)

    Hi @juaancmendez,

    Thank you so much for providing the code! I really appreciate your help.
    I’ll check it and let you know how it goes.

    Best regards,
    Mehmet

Viewing 15 replies - 151 through 165 (of 410 total)