Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Tables google_analytics_counter and google_analytics_counter_storage contain stats fetched for the period specified under "Start date for GA queries" on the settings page (admin/config/system/google_analytics_counter).
The problem at hand is that if one collects data for e.g. the past year, and then they choose to change and collect stats for only the past week, the data for the past week will be overwritten, but the old paths fetched before will still contribute to the counts.
Proposed solution: let's empty the stats tables if we change from a longer to a shorter collection period.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | start_date_change-2794797-15.patch | 2.79 KB | efpapado |
Comments
Comment #3
Vacilando CreditAttribution: Vacilando as a volunteer commentedOK now! If the start date changes to a more recent one, the stats tables are emptied. There's an informational message on the screen just after the settings form changes the date to a more recent one, and a watchdog informational message is emitted as well.
Fix pushed to 7.x-3.x.
Comment #4
loparr CreditAttribution: loparr commentedNow I am getting lots of logs like "The start date of the Google Analytics queries has been changed to a more recent one. The stats storage tables of this module had to be reset (they will repopulate during cron runs)."
which happens randomly. The numbers are reset however there is nothing updated during next cron run (or it is deleted right after) (the log says it has updated xy paths). I looked into db and tables google_analytics_counter, google_analytics_counter_storage are empty.
Comment #5
loparr CreditAttribution: loparr commentedChanging this to critical - dev module does not work at all for me - tables are empty. Something triggers "The start date of the Google Analytics queries has been changed to a more recent one. ..." on random pages.
Comment #7
loparr CreditAttribution: loparr commentedHi,
Current dev module breaks site with php error :
PHP message: PHP Fatal error: Call to undefined function user_is_logged_in() in google_analytics_counter/google_analytics_counter.module
Comment #8
Vacilando CreditAttribution: Vacilando as a volunteer commentedI've found out that the session cookie was being set even for anonymous users. Fixed in the latest DEV now.
Comment #10
Vacilando CreditAttribution: Vacilando as a volunteer commentedFixed the fatal error as well now, in DEV.
Comment #11
Vacilando CreditAttribution: Vacilando as a volunteer commentedDoes it work for you now, @loparr -- or do you still have a problem with populating tables google_analytics_counter and google_analytics_counter_storage?
Comment #12
loparr CreditAttribution: loparr commentedHi,
it worked for few days . checked the stats today and all of them are reset. Checking the log - one of logged in users triggered the reset of the stats. (I guess logging in triggers it) "The start date of the Google Analytics queries has been changed to a more recent one. The stats storage tables of this module had to be reset (they will repopulate during cron runs)."
Why the counts could not be changed every time cron runs only (reset just before new update from GA)?
Comment #13
asPagurus CreditAttribution: asPagurus commentedWe have 27K nodes on our site and after several hours fetching data from GA - bumps! - all reset!
I don't know why it's happens but it.....
After third attempt I disable 25-33 strings in google_analytics_counter.module.
And change in 17 string:
if ($authsession==5)
so that only for me this block is fired.
Sure - this must be done by right permission, but for me it helps.
I dont know - if this module works for me or not yet - all pageviews that it get was 1 for each page (135K pages from 317 at GA)
Comment #14
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedThe module in the dev version right now is useless. When fetching of the data finishes (for my case: after several cron runs), it directly truncates the db tables and starts populating them again.
I don't understand the logic behind the commits in this issue. Why did you add code into the
.modulefile that is not wrapped in a function? Couldn't those checks get applied either after the submission of the admin form, or on the cron run?This is considered to be very bad practice for Drupal, quick search: https://www.drupal.org/node/2597716
I suggest you revert the commits of this issue.
Comment #15
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedI'm proposing a patch that will solve the issue in a better way.
On the admin form, there's a new checkbox which is called "Clear stored data". If the user checks it, a new submit handler will truncate the tables.
Please note that this patch is built in order to apply on the latest stable version of the module, the 7.x-3.3 and NOT the dev.
I recommend that you revert the previous commits from this issue.
Also please note that there have been some commits which fix coding standards. The attached patch does not take them into account.
Comment #16
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedI second this. The whole session-based handling outside of a function doesn't seem to make any sense for me. Actually it leads to the situation, that every logged in user could force the truncate of the tables. Considering a dozens of users working with the system – there will be always someone resetting the data.
Comment #17
kaszarobertBecause of the Universal Analytics shutdown, version 7.x-3.x is no longer supported.
As Drupal 7 EOL is close, please consider upgrading to the latest Drupal and latest version of this module with Google Analytics 4 support.
If you are still here and experiencing problems with the latest version using GA4, then please open an issue about it.