Drupal 7 port of Download Count

Thanks! subscribing

I've just committed an initial d7 version based on the output of http://upgrade.boombatower.com (before I saw this issue). The dev snapshot should be available in a few hours. If you've already got a port started, just post the patch and i'll commit it.

Subscribing...

Really looking forward to seeing some light at the end of the tunnel on this D7 release :) Subscribing!

Subscribing...

Subscribing...

Subscribing

Subscribing...

Subscribing.

Subscribing

subs

Subscribing - any progress on this? :)

subscribing

very much looking forward to seeing this version. thanks for the work!

Just updating title to make it easier to track.

thanks for the patience-- i hope to finally have this ready to post this weekend-- barring unforseen disturbances or more hurricaines, lol

great, will be happy to test out and report. Thanks!

Checking back in... any status updates?

Thanks,
Ben

I'd be interested in contributing to this port to accelerate the process. anybody else?

I really apologize for this taking so long-- contributions won't help me much, unless they're for someone that already knows the new systems in d7,lol. I've been working on it-- it's just turning out to be a lot more work than I had anticipated. It's basically a complete rewrite to take into account fields in core, the new file field, entities, and the completely new file api-- all of which I'm learning as I go as well.

The good news is-- with there being 1 single mechanism for file fields (as opposed to the core upload and contrib filefield modules previously supported), the module will be a lot leaner and cleaner.

There's definitely been progress-- it's just a little slow as I get up to speed on all the new stuff. I'll try to keep this post updated with progress.

oh, wrong vocable. I really meant chipping in to help out development.

Found a core bug that needs to be addressed as part of this upgrade: #1143460: hook_file_download_access_alter missing entity argument.

LOTS of progress today-- for the first time I actually have the download counter working and collecting the proper info. I just need to fix up the block and data pages, and views 3 integration.

I appreciate your work and am designing a site that hopefully will use this.

Do you know if the download count will work on either the private files or the public files? My site will be set up to use private files.

This module always requires private files -- for d7 that means individual file fields set to 'private'. There's another module, pubdlcnt, for public files.

Ok -- i've just committed a basic, partially functional rewrite for d7 in a new 7.x-3.x branch. Download tracking works, but the export and details functionality is still non-functioning. Also no views integration or blocks yet-- they're on the way.

FYI-- the new version is a drastically rewritten and much simplified version (which will make maintenance and future updates much easier). Part of the reason this was such a bear to upgrade was all the non-core functionality the module included.

Fair warning-- the module will rely on views to provide most of the data output.

Closing this issue-- from now on just create new issues against the new branch.

just committed basic views support so the d7 version is pretty much feature complete at this point (still need to add some good default views though).

It's been stable and notice/error free for me so any testing and evaluation would be great (especially the views integration).

And if anyone creates a nice view be sure to create an issue and submit it for inclusion as a default view!

Is it possible to add a relationship to the node that the file was attached to?

There's a relationship from the download to the file info so once you add that, you should be able to chain a relationship back to the entity (not necessarily always a node) on top of that. Though currently i'm getting a sql error (which I'm trying to track down now) when I try it.

Until you want to remove the "not suitable" message from the project page, I would consider this still active. And then you say you're getting a SQL error any way.

I tend to disagree. For me, the 'version X' issues for 'version X+1' updates should be closed once there's a dev version since that's when the the ability to open issues directly against the proper version becomes available.

imo keeping the version update request issues open only serves to offer a place to post misplaced questions/bugs that should have their own issue (as #28 demonstrates) but i'm willing to keep an open mind and try to leave it open until an official release is created. However, if it does indeed become a dumping ground of comments that should have their own issues I will close it.

just a quick status update-- afaik, the only remaining item I need to finish in order to create an official release is the views relationship issue. I've spent quite a bit of time on it, but for the life of me i cannot figure out why chaining on top of the existing file relationship doesn't work.

another update.

There's a bug in the views file)usage relationship.

So, currently, an official release of this module is contingent on resolving two issues:

#1409454: File Usage: Content relationship broken
#1143460: hook_file_download_access_alter missing entity argument

I'm not sure if this will help out, but when I installed it, and set files to be stored in private, I get the following error....

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'id' cannot be null: INSERT INTO {download_count} (fid, uid, type, id, ip_address, referrer, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => 10 [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => node [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => 127.0.0.1 [:db_insert_placeholder_5] => http://romanos:8888/?q=node/3 [:db_insert_placeholder_6] => 1328740750 ) in download_count_file_download_access_alter() (line 177 of /Users/joshbgosh9/Sites/romanos/sites/all/modules/download_count/download_count.module).

Also, I think a bit of people would like if public files could be counted in drupal 7.

@joshbgosh10592, thanks for the report but see #1344850: PDOException: SQLSTATE[23000]: Integrity constraint violation for the resolution to that known error (it's related to the core issue I linked above).

And public file counts can always be bypassed via the browser, so imo they don't really provide much value. Also, with d7's per file field privacy settings, the biggest impediment to using private files no longer applies. In any case, they've always been outside the scope of this module and likely will be for the forseeable future.

I'm a little lost:
Right now I'm using the 7.x-3.x-dev verison of Download Count and as mentioned it does not work due to the pending bugs. However, I cannot apply the provided patches from #1143460: hook_file_download_access_alter missing entity argument because they are target at 8.0, right? I would appreciate any bump into the right direction.

Just an idea but the issue #1143460: hook_file_download_access_alter missing entity argument could perhaps be temporarily fixed until the issue is resolved by storing the entity somewhere (perhaps in a static variable) between hook_file_download_access and hook_file_download_access_alter. When a fix for this issue is released you could then remove the unnecessary code. Tried it at my end and it works, also keeps the fix inside this module.

awesome idea-- can you post a patch of your changes?

This probably needs some tidying and there is probably a better way of handling it but here goes.
I also have an example module for my idea here http://drupal.org/node/1457866 but that is very rough with no views integration or anything. What are your thoughts on that?

Finally some real progress on the views issue-- #1409454: File Usage: Content relationship broken. The patch in comment 16 on that issue seems to fix all the problems and I just committed some further views integration refinements. I think views integration is just about complete. I just need to do some decent default views and then I can turn my attention to getting the core bug fixed.

way off topic, but in response to robwithhair, see: http://www.istos.it/blog/drupal/drupal-entities-part-1-moving-beyond-nodes

and awesome series on entities that answers most of my questions. Looks like the next major version will be an entity implementation. I'll open a feature request for it once i get a beta of the current version done.

Yes, that's a good one. I stumbled upon that one but it doesn't address any of the CRUD features of Entity API so I'm not 100% that it's up to date. Couldn't see anything about EntityAPIController class.

I found this link most useful Understanding the Entity API Module and this one Creating your own entities with Entity API although the example code is far too in depth for what I needed to do and much could be left out. In general I think the docs here are the easiest to follow but they could do with some more detailed info which I could only get from looking under the hood of the commerce module at present.

The views issue has been fixed in views itself and download_count views support is pretty much complete.

The core bug issue is taking a different approach than I originally posted, which is better, but breaks download_count in the meantime.

So I'm maintaining a functional patch in #1484206: use this required core patch until the core bug fix is committed.

Is there Anybody having an idea when this patch is solved in a core bug fix? Seems to me that there is completely stand still? We switched off the use of this module a couple of months ago after this bug appeared, but I definitely will use it again when this is fixed. I'm not very fond of making changes in the core, but I must admit I never tried, is it difficult?

after much weeping & gnashing of teeth and lots of waiting for a core bug fix, the official d7 version has been released.