Cannot access any Reports on Drupal 7

got the same problem.
Checked the database ( table pop_link_stats ) and that table is empty. so the click is not even recorded.

konrad can you check if the clicks are recorded in your database?

Make sure you have views and views ui enabled see: #1343448: views needs to be enabled to show the "admin/reports/pop_links" link in the reports section.

I've manually inserted some values in the database and they show up in the report section ( admin/reports/pop_links )
So I think the issue is really the recording of the external click.

Will keep you posted if i find anything that will fix this.

I cannot seem to find any code that is altering the links or adds the class 'pop_links' to the html elements (a) so the clicks can be recorded.

Also if you look at the source code from your web browser the external links should eventually have given the class 'pop_links-processed' and an attached jQuery function that registers the click. But since the elements never get the pop_links class, elements are never processed and no 'click attachment' is created.

Any help is welcome but for now I'm gonna build it myself since the last update of the maintainer is from sept 2010.

Found a bug that is causing that no clicks are recorded:
In javascript (jQuery) in Drupal.settings.pop_links the used 'selector' is set to #node-1 #node-2 etc In my case I need it to be #article-1 #article-2 etc

I have set the 'node types' to 'article' OR to all content types in admin/config/services/pop_linksbut that doesn't help drupal.settings.pop_links still contains node numbers.
I think this is due the change in drupal 7 where al content items are nodes if I'm not mistaken.

As stated before In my case I needed the hook to look for articles instead of nodes.
Turns out I was right.
Changed the code in the pop_links.module.
on line 79 in the pop_links_node_view function of the current version.

removed @ line 79:
'#nodes-' . $node->nid => array(
added @ line 79:
'#article-' . $node->nid => array(

now it works for me.
Although this is not a great solution because now I broke it for node type content.
Next step is to build in a check which content should be checked. but for now I'll use this because this works for what I need.

To check what content you need to be checked for clicks, look in the html source code of the page where the content is on. There should be a html element around each content with something like 'article-1' 'article-2' as id of that element.

Hope this helps someone and saves them the hours searching for the problem ;)

I installed this module on a fresh D7.12 install and see no tracking happening as well for both links in body content and url field types, both in node display and view displays.

could be that you didn't set permissions to allow tracking of your used user role?

Same problem here. No blocks. No reports. Permissions were configured,

On my setup I can see that no data is being logged in pop_link_stats (same problem as scuba_fly )

If you manually insert a blank record (using phpmyadmin or sequelpro), you will see that this is listed in the reporting ( at admin/reports/pop_links/log )

So clearly while the reporting work the root cause is actually that the record is not getting entered in the first place.

Confirming that the module deliberately does not record links for user1 (admin) - code in pop_links.module checks for this:

function _pop_links_track($user) {
  $roles_to_track = variable_get("pop_links_track_roles", array(1 => 0, 2 => 0));

  if ($user->uid == 1) {
    // don't track the admin/webmaster
    return FALSE;
  }

So, as thisiskonrad says, one must ensure testing is done with a non-admin user for the logs to be generated.

Enabling permissions also mentioned in previous comments - need to ensure logging is enabled for appropriate roles in the usual people settings.

Given the root cause is that the record is not getting entered in the first place, I would suggest that this issue be closed and our discussions continue in an issue already raised:

https://drupal.org/node/1269290

scuba_fly's investigations and workaround remedies (thanks) are useful in helping us find a full solution.

Interim solution provided here: https://drupal.org/node/1269290#comment-7625019

Credit and thanks to Clive for providing a way to access the Drupal node id for a page here: http://drupal.stackexchange.com/a/78667/1082