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.
The accesslog in the statistics module isn't the most elegant thing.
What it does is, each page view it writes to the database these items:
- Page title
- Path
- url
- hostname (IP addess)
- uid
- Session id
- Page load time via timer_read
- timestamp
Many of these can be gathered by free external tools such as google analytics. These services often offer custom variable tracking, so a contrib module could add this functionality.
I will work on a patch to strip out the accesslog features from statistics module.
Comment | File | Size | Author |
---|---|---|---|
#41 | drupal-remove_accesslog_changelog-1446956-41.patch | 540 bytes | iamEAP |
#36 | drupal-remove_accesslog-1446956-36.patch | 46.88 KB | iamEAP |
#36 | drupal-remove_accesslog-1446956-36.interdiff.txt | 8.17 KB | iamEAP |
#26 | drupal-remove_accesslog-1446956-26.patch | 40.02 KB | iamEAP |
#19 | drupal-remove_accesslog-1446956-19.patch | 40.55 KB | iamEAP |
Comments
Comment #1
timmillwoodI would still like to see this make it's way into Drupal 8 as I really feel the 'access log' gives little value, most of the value from the statistics module comes from the 'node counter'.
Comment #2
Dave ReidAgreed. Let's support the basic use case of counters for all entity types, but anything advanced should probably not be for core.
Comment #3
iamEAP CreditAttribution: iamEAP commentedThe node counter functionality of statistics is great for site builders / administrators (for, e.g., building a View of the most "popular" content).
While the access log is not immediately useful for the same audience, it's extremely useful (at least in my opinion) for developers.
Comment #4
timmillwood@iamEAP - I don't feel these useful items you mentioned really need to be in core and by moving them to contrib allows for better expansion on features and functionality. I really hope you could be one of many to help lead this effort with your already widely used contrib module.
Also to cover your last point about javascript. The node counter has already moved to JavaScript in Drupal 8 to allow it to give accurate results when using reverse proxy caching. If we were to keep the accesslog I would like to do the same with that and move it to JavaScript.
Comment #5
iamEAP CreditAttribution: iamEAP commentedI suppose accesslog isn't necessarily appropriate for core, especially with the direction node/entity statistics is going / has gone.
If you remove the accesslog, I'm happy to adopt its schema/table in an 8.x branch of my contrib module.
Comment #6
timmillwoodStarting with removing tests
Comment #8
timmillwoodComment #9
timmillwoodSo that's the tests sorted, now to do the rest.
Comment #10
timmillwoodRemoved the access log schema and settings form.
Little by little!
Comment #11
timmillwoodBad patch in #10
also removed most things now.
Comment #13
catchYes please. See also #1860026: Remove hook_exit() for cached page requests.
Comment #14
timmillwoodI am really keen to remove the accesslog, but there is a lot of code to remove and by the time I find it all, and test it all, core has changed so much that my patch doesn't work.
Changing the access log to use ajax is near impossible because of the kind of data it gathers, it would need to have a php built gif on the page that gathers the information much like Google analytics or other such tools.
Comment #15
iamEAP CreditAttribution: iamEAP commentedJust out of curiosity Tim, what advantage do you have in mind for a PHP-built gif over a regular AJAX request?
Comment #16
iamEAP CreditAttribution: iamEAP commentedKicking this back off again. Re-roll of #11.
Comment #17
iamEAP CreditAttribution: iamEAP commentedComment #19
iamEAP CreditAttribution: iamEAP commentedMissed a merge conflict in the re-roll. Also getting rid of another test that's not relevant anymore.
Comment #20
iamEAP CreditAttribution: iamEAP commentedUn-assigning Tim for wider review.
Comment #21
mondrakeHi, I tested and it looks ok to me.
I just wonder whether we should have an explicit dp_drop_table for accesslog in the update hook?
Cheers
Comment #22
timmillwoodEric,
Thanks for looking into this. All looks good to me, I am going to send as re-test to the testbot now before marking RTBC.
Tim
Comment #23
timmillwood#19: drupal-remove_accesslog-1446956-19.patch queued for re-testing.
Comment #24
timmillwoodLooking good!
Really excited to get this committed.
Comment #25
BerdirThese shouldn't use t()
Comment #26
iamEAP CreditAttribution: iamEAP commentedGood catch, Berdir. Fixing those here.
@mondrake In past upgrade paths, I believe accesslog has been truncated (maybe I'm imagining this); though there've also been cases (in Taxonomy, for example) where a table's been left behind for contrib to pick up. In any event, I think it's fine to leave it for now and address it when the upgrade path is being worked on.
Comment #27
mondrakeOK, thanks
Good to leave it there for contrib to pick up.
Comment #28
BerdirNow those lines are all unchanged. Looks good, was RTBC.
Comment #29
webchickHm. Assigning to Dries, since this seems to remove basically all of the usefulness of this module.
Comment #30
timmillwoodnode counter is the most useful part of this module, it counts all node views allowing for "Most viewed content" views to be generated etc. The access log just duplicates what any analytics or server access log does. It offers little or no functionality just statistical data that is better sourced else where. Access log doesn't work with reverse proxy cache and adds extra database load.
Comment #31
webchickYes, but I don't run external analytics due to privacy concerns, it is much easier to simply go to admin/reports than grep my Apache logs or install a third-party log visualization script, and I don't use a reverse proxy cache (along with 90%+ of the rest of the Drupal websites out there) so I don't care about that. :)
Anyway, let's see what Dries says.
Comment #31.0
webchicktypo
Comment #32
NITEMAN CreditAttribution: NITEMAN commentedI don't know if accesslog should remain in core or if it should be decoupled from node counter functionality but for me and many others provides invaluable information.
Right now it's one of the bests sources of information for server side performance monitoring and tuning... so, please, if it's finally removed provide a clean path to a contrib alternative.
Best regards
Comment #33
timmillwoodI would suggest a tool such as New Relic for performance monitoring and tuning, the accesslog in statistics module is going to cause more performance issues. You should see a faster site by disabling it.
Comment #34
iamEAP CreditAttribution: iamEAP commentedI understand the concerns mentioned by webchick and NITEMAN; I expressed similar concerns in #3.
I maintain Better Statistics in contrib. In D7, it support the default accesslog functionality, but also an API to allow collection of arbitrary data. On the roadmap is pluggable storage (e.g. a syslog for Statistics).
I could honestly go in either direction:
But as Tim Mentions now, it's not currently doing its job very well.
Comment #35
David_Rothstein CreditAttribution: David_Rothstein commentedThis patch doesn't look ready yet. Some quick things I noticed:
***
Also, I have no strong opinion on whether this should be in core, but it doesn't sound like there's a clear plan yet for maintaining this in contrib .... Is someone planning to maintain it as a standalone module?
I don't think it's accurate to say that the accesslog duplicates what analytics or server access logs do; maybe that's partially the case for anonymous users, but definitely not for authenticated users. The module provides deep integration of those statistics within your Drupal site itself. Example from the patch...
Comment #36
iamEAP CreditAttribution: iamEAP commentedHere's a patch that..
I mentioned earlier that I'd be willing to, at a minimum, maintain the functionality that we're ripping out here in the 8.x version of the Better Statistics module (I'd attempt to improve upon it there as well, obviously).
Comment #37
NITEMAN CreditAttribution: NITEMAN commentedEvery measurement tool has its performance impact (¿Heisenberg?), acceslog doesn't impact so much in a well configured dedicated InnoDB.
I know New relic... but IMHO we can't seriously solve everything using external black box services.
Best Regards
Comment #38
ParisLiakos CreditAttribution: ParisLiakos commentedLets get this done, we have a critical waiting on this..anyone who wants this functionality in d8 will be able to find it in contrib in Better Statistics module
Comment #39
catchNewRelic has nothing to do with this issue.
If you want performance measurement of page loads from within Drupal you can use http://drupal.org/project/performance http://drupal.org/project/xhprof and others.
Comment #40
Dries CreditAttribution: Dries commentedI agree that this no longer is core worthy so I committed this to 8.x. Not to mention it is often a source of problems. I do think we should add a 'CHANGELOG.txt' entry so I'm marking it 'needs work' on that basis.
Comment #41
iamEAP CreditAttribution: iamEAP commentedCHANGELOG.txt entry, per Dries' note. Also made a change record: http://drupal.org/node/1900384
Comment #42
dawehnerDon't we need a changelog entry for that?
Comment #43
effulgentsia CreditAttribution: effulgentsia commented@dawehner: what do you mean in #42? Do we now have some other process for making changelog.txt changes other than submitting a patch as #41 has done?
Comment #44
dawehnerYeah good question what I talked about, missed somehow the link on http://drupal.org/node/1900384 . I'm sorry.
Comment #45
effulgentsia CreditAttribution: effulgentsia commented#41 looks good. Thanks.
Comment #46
catchCommitted/pushed the follow-up, thanks!
Comment #47.0
(not verified) CreditAttribution: commentedis change to it
What it does is