Option to enable slideshow to increment "view count&
|
FOBioPatel
Joined: 2004-07-25
Posts: 26 |
Posted: Sun, 2004-07-25 14:55
|
|
I think it would be great if we could increment the view count (perhaps optionally, don't think everyone would like it) with the Slideshow. (Or does g2 do that already?) |
|
| Login or register to post comments |
Posts: 8598
No, it doesn't.. currently G2 increments the view count only when an item is accessed via the ShowItem view. This also means the hybrid/slider/tile layouts don't increment view counts for individual photos because they are displayed within the ShowItem view for the parent album, not as separate pages.
I like your idea for slideshow (and agree it should be optional).. I think it is something we should do unless we decide to increment view count for the DownloadItem view (ie when the browser actually downloads the image itself).. then view count would be incremented no matter where the image displayed (any layout, any module, even references from pages external to G2). Bharat, have you given this idea any more thought? Would this lead to view counts growing too quickly somehow?
Posts: 6019
I'd really like to increment the view count from DownloadItem, since I think that's a more accurate representation of how many times the image was viewed. I'm actually working on making this happen right now since I'm doing a pass over the way that DownloadItem works for speed. I'll see if I can move the counting code into that view.
What do you guys think we should do about the case where the browser sends the image request with an "If-Modified-Since" tag? The only time that can happen is in the case when the browser already has the image (in G2, derivative urls are immutable) so in that case we don't actually send the image we send a 304 and let the browser render the image from its cache. Should we be incrementing the view count for that also? Or only for the case where the image was actually downloaded?
Posts: 26
This could be put on hold, and a full blown stats tool could be integrated. Maybe something that can map visitor flow, most popular images, least popular albums, and so on.
It's easy for me to type this stuff up, I know it's gotta be a pain in the asphalt to code it up. I may be getting ahead of myself here...
Posts: 8598
I'd lean towards not counting the if-modified-since request as it's probably reviewing in the same session, right?... or, maybe look at how long it's been since "-since".. you could skip the count if the requests is within a few hours but count it if it's the next day? something along those lines....
Posts: 6019
I'm leaning towards not counting the if-modified-since requests either, since the file isn't actually transferred. I'm thinking that we mostly care about the number of times the server has actually sent the image to a client...
Posts: 8598
One more complexity... item types that don't have an actual file that goes through DownloadItem will need to continue to increment on ShowItem, right? (like an album!)
Posts: 6019
Right. I think that only AlbumItems should get incremented in ShowItem, and that only Resizes, Preferred derivatives and original items should get incremented in DownloadItem. I think that we definitely don't want to increment on thumbnail views...
Posts: 32356
create itemViewed and itemDownloaded events and another module can handle them, i.e. a download limit module would use itemDownloaded.
Posts: 8598
I created a task for this.
Posts: 8598
I went ahead and implemented this.. DownloadItem increments the item (or parent item for non-thumbnail derivative). ShowItem increments non-data items like albums.
Note that when DownloadItem::renderShortcut is used we now init the db and make an update; this type of request used to complete w/o any db interaction.. however, the data file is sent before any db operation so I think the browser will still get the result back about as quickly as before.. at least some tests with mozilla and adding sleep() calls after sending the data seem to indicate this.
Posts: 8598
For albums with multiple pages of thumbnails, it increments the view count each time ShowItem is used.. so if you flip through an album with 6 pages of thumbnails you'll bump up the view count by six.... (it was like this before my changes, I just didn't notice before)
Posts: 32356
but it adds load to the webserver / a db connection per downloaditem request is not neglectable.
we should benchmark the overall performance with small to heavy load with and without this change.
Posts: 10
Hi,
anybody Idea after the long time, to incement the viewcount of an item by downloaditem ?
I want to use it for Lightbox-Views
Thanks
Posts: 32356
@aquanox24:
doing any work in core.DownloadItem requests will clearly slow down your web server / user experience.
e.g. doing view counts there would mean to load the database abstraction layer, create a database connection and making a modification of database data. that's pretty heavy compared to a normal apache static file request.
we've optimized the core.DownloadItem requests to be about 10x as expensive as normal apache static file requests. that's pretty good for PHP driven request handling. i fear you'd add another factor 10 if you'd add view counting in this request.
if you rely on more accurate view counts, how about analyzing webserver access logs?
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage