Mehmet

Hi @cmedya,

Thank you so much for taking the time to translate WP Statistics into Turkish!

We really appreciate community contributions like this.

To make sure your translation gets officially included in the plugin and is maintained across future updates, we recommend submitting it through translate.ww.wp.xz.cn (GlotPress), which is the official WordPress translation platform.

You can find a step-by-step guide on how to do this here:

https://wp-statistics.com/resources/how-to-translate-wp-statistics-plugin/

This way, your translations will be automatically available to all Turkish-speaking users when they install or update the plugin.

Thanks again for your contribution!

Hi @lodree,

Thank you for the update and for taking the time to investigate this so thoroughly, it’s great that you got a clear answer from IONOS.

It’s unfortunate that shared hosting limitations prevent them from adding ModSecurity exception rules. As you’ve concluded, the most reliable solution would be to move to a hosting plan that allows custom ModSecurity configuration (a VPS or managed hosting where whitelist rules can be applied).

If you switch hosting providers and encounter any further issues with the plugin, please don’t hesitate to open a new topic and we’ll be happy to help.

Thanks again for your patience throughout this process!

Best regards

Hi @lindseyt,

Thanks for reaching out!

Since this only affects one specific client’s number, the issue is almost certainly something in how that number is stored or formatted on that contact’s record.

Could you check the following:

1. Look at the raw value, go to wherever that client’s phone number is stored (WooCommerce order, user profile, custom field, etc.) and check if there are any extra spaces, dashes, brackets, or invisible characters around the digits.
2. Delete and re-type the number, don’t paste it, type it manually in the correct format (61476xxxxxx) and test again.
3. Check the form field, if the number comes from an Elementor Forms submission, check the entry in the form submissions log to see the exact value that was submitted.

Since all your other clients work fine, this is isolated to the data for this one contact rather than a plugin configuration issue.

Let us know what the stored value looks like and we can help from there!

Best regard

Hi Christian,

Thank you for the detailed follow-up and for sharing your hosting specs.

You’re right, your server resources are more than sufficient, so that’s not the cause here.

Before we rule out everything on your end, could you check whether there might be a plugin
conflict on that specific site?

Since the migration worked fine on your other 2 websites, something unique to this site’s setup may be interfering with the migration process.

To help us investigate, could you share:

1. A list of active plugins on the affected site (especially any that interact with the
   database, caching, or cron, e.g., object caching plugins, database optimization tools, or
   security plugins)
2. The approximate size of your visitors table on this site.

This information will help us narrow down whether something specific to this site is causing the
migration to behave differently.

Best regards

Hi @tjoseph,

Thank you so much for the kind words and the detailed review! It’s great to hear that WP
Statistics is covering all the analytics needs you were looking for.

We put a lot of thought into making sure site owners can answer the questions that actually
matter, so it’s really rewarding to hear that comes through in your experience.

If you ever have any questions or suggestions, don’t hesitate to reach out.

Thanks again for the support!

Best regards

Hi @taojing10,

Thank you for your patience and for the detailed follow-up, that really helps us narrow things
down!

You’re right, this is a bug. The [wpstatistics stat=visits time=total] shortcode is not
including historical data in its total.
We’ve identified the root cause in our code and I’ve escalated this to the development team.

I’ll follow up with you here once the fix is available.

Thanks again for taking the time to report this!

Best regards

Hi @taojing10,

Thank you for your patience and for the follow-up.

We’ve tested the Historical Data feature on our end with v14.16.1, and both Historical Total Visitors and Historical Total Site Views are working correctly and reflecting in the totals.

https://mega.nz/file/5wpgDSRa#cDJWj-fjVDvPJ-B7cP1ZWXNZy6rs-FIiRPzNkioBXqo

Could you please try the following steps:

1. Go to WP Statistics → Optimization → Historical Data and re-enter your Historical Total Site Views number, then click Save Changes.
2. Clear any caching you may have (caching plugin, server-side cache, or CDN).
3. Go to Optimization → Plugin Maintenance and click Refresh Summary Totals under Data Migrations.
4. Clear your browser cache and reload the Overview page.

After these steps, check if the Total Site Views now includes your historical number.

Best regards,

Hi @cortlieb,

We’re sorry about this experience. We’ve identified the root cause, the background migration process can overwhelm the database on certain hosting configurations, which is what caused your site to become inaccessible.

This problem is often related to hosting resource limits. Before applying the fix below, we strongly recommend checking the following with your hosting provider to prevent it from happening again:

• PHP Memory Limit: Should be at least 256M. You can check this in Tools > Site Health > Info > Server once your site is back up. If it’s lower, ask your host to increase it or add define('WP_MEMORY_LIMIT', '256M'); to your wp-config.php.
• PHP Max Execution Time: Should be at least 120 seconds.
• MySQL Max Connections: On shared hosting this can be very low. The migration runs many database queries in quick succession. Ask your host if there is a limit on simultaneous database connections or queries per second, and if so, whether it can be increased.
• WP-Cron: The migration relies on WordPress cron. Some hosts disable or throttle WP-Cron. Ask your host to confirm cron is enabled and not rate-limited.

To restore your site, please follow these steps using phpMyAdmin:

1. Log in to your hosting control panel and open phpMyAdmin
2. Select your WordPress database
3. Go to the SQL tab and run the following queries one by one:

-- Step 1: Remove all queued migration batch data
  DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_visitor_columns_migrator_batch_%';
  DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_update_visitors_source_channel_batch_%';

  -- Step 2: Remove process locks
  DELETE FROM wp_options WHERE option_name LIKE '%wp_statistics_visitor_columns_migrator_process_lock%';
  DELETE FROM wp_options WHERE option_name LIKE '%wp_statistics_update_visitors_source_channel_process_lock%';

  -- Step 3: Remove status flags
  DELETE FROM wp_options WHERE option_name IN (
      'wp_statistics_update_visitors_source_channel_status',
      'wp_statistics_visitor_columns_migrator_status'
  );

  -- Step 4: Reset migration tracking
  DELETE FROM wp_options WHERE option_name = 'wp_statistics_jobs';
  

Note: If your table prefix is not the default wp_, replace wp_options with your actual prefix (e.g. xyz_options). You can check this in your wp-config.php file under $table_prefix.

4. If you previously deactivated WP Statistics via FTP, you can now reactivate it from Plugins > Installed Plugins in your admin. The migration will no longer auto-run.
5. The migration prompt may reappear in the admin area. Please do not start it again until you’ve confirmed the hosting resources above are adequate, or until we release an update with improved handling for large databases.

We’ve escalated this matter to our development team and we will follow up with you once a permanent fix is available. We understand how critical site availability is and we take this seriously.

Please let us know if this resolves the issue or if you need any further assistance.