I’m having the same problem that mia is having – stats aren’t showing any data. But I am also having a more basic problem (which is probably related) and so I thought I would start a new thread.
In the podpress general settings, setting “Show Download Stats” to enabled doesn’t seem to do anything. I think in old versions of podpress that I used it wrote the number of downloads out after the download link in the post. That hasn’t happened for the last several versions. Sorry I can’t remember exactly which version I last saw it work in.
How do these stats work, do they require write access to the plugin dir? Do they use the db?
Must be forum issues, I posted this 5 hours ago and it still doesn’t appear on the forum – but I can see it through my user profile…
bump. almost 48 hours later I still don’t see this in the forum only on my profile?
almost 48 hours later I still don’t see this in the forum only on my profile?
You have forgotten to set the tag “podpress” to this thread. (I have set the tag just now.)
Without tags a thread is always visible in the general thread list of the “Plugins and Hacks” forum http://wordpress.org/support/forum/plugins-and-hacks but with the tag it appears also in this list: http://wordpress.org/tags/podpress?forum_id=10 (and I follow only the last one.)
BTW: I have found out that if someone adds this tag/token (I don’t know how you would call it) [Plugin: podPress] to the header of the thread, I can change the thread status, too. But the capitalization is important for this tag. It should be “podPress” and not “Podpress”.
But to the more important question:
If you set the option “Show Download Stats” to “Enabled” and it appears no number at the end of the podPress section in the posts then it is most likely that the counter does not count and the number of downloads is zero. The number of downloads appears only if it is greater than zero.
And if the media file does also not appear in the statistic table then it is a further sign for a not working downloads counter.
Is the stat method test successful?
How do these stats work, do they require write access to the plugin dir? Do they use the db?
podPress collects the stat data only in the db.
Counts Only in the db table wp_podpress_statcounts. Full and Full+ in the in the db table wp_podpress_stats.
(Yesterday, I looked into this stat mechanisms and changed again the explanation of the current 8.8.6 beta. The one from the first betas was not a 100% correct. I have changed also the appearance of the Quick Counts table (Counts Only logging method)).
I’m learning as I go. I figured adding the [Plugins:podPress] token was all I had to do to get it to show. But I didn’t know that case was important and I didn’t realize I could just add a “podpress” tag. Thanks.
Yes. The stat method test is successful. I have tried Count-only, Full, and Full+ and none of them seem to be recording stats. The download page in the plugin admin page says;
“We’re sorry. At the moment we don’t have enough data collected to display the graph.”
The dashboard widget in shows 0 for everything. And the download counts are not displayed in the posts even though I have enabled that feature on the general tab of the plugin.
I did try disabling all other plugins and I alaso checked permissions but no joy there. Now that I know table to look for in the db I will see what’s in there (I hope the db is not messed up – I’m scared of db problems).
By the way, one thing that I noticed was that on the general settings page where it says “feed caching” I have the dir path corectly entered but there is a “(1)” which appears after the text input field. Is that normal? Yes I verified the path is correct and permissions are correct.
One other thing – I am using feedburner as my feed url so I have that entered in on the feed settings. Do you think that would affect the stats? Here is the feed http://feeds2.feedburner.com/yokosukachurch
Well, I just browsed the database. Both the wp_podpress_statcounts and wp_podpress_stats tables exist but they both have zero records. How do you think I should proceed?
Hm … Maybe there is some kind of error on the attempt to store the download numbers in to one of these db table. If there is an error then it is logged in the error log of the server.
Which stat method are you using? “Use WP permalinks”?
You could also look how the query string looks like resp. whether the little redirect for the podPress statistic works or whether it is problem to write to these two db table.
Please, use Printphpnotices plugin (the one I have mentioned in this post) to log the strings of the db queries during the download counting.
For “Counts Only” insert the printphpnotices_var_dump call in line 915 and 917 of the podpress_functions.php file:
$sqlIoU = "INSERT INTO ".$wpdb->prefix."podpress_statcounts (postID, media, $method) VALUES ($postID, '$media', 1) ON DUPLICATE KEY UPDATE $method = $method+1, total = total+1"; printphpnotices_var_dump($sqlIoU); $result = $wpdb->query($sqlIoU); printphpnotices_var_dump($result);
and for “Full” in line 944 and 946 of the same file.
printphpnotices_var_dump($query); $result = $wpdb->query($query); printphpnotices_var_dump($result);
If the printphpnotices_log.dat file contains a line like this
'INSERT INTO wp_podpress_statcounts (postID, media, play) VALUES (51, \'hallo.mp3\', 1) ON DUPLICATE KEY UPDATE play = play+1, total = total+1'after you have clicked on the player of one of the episodes then you will know that all works fine until the db action.
If this string is followed by a false then something went wrong during the attempt to execute this db query. If it is followed by a 1 or a 2 then the statistic tables should contain non-zero values.
The (1) behind the feed caching folder name on the general settings page of podPress is a good sign. It means that this folder is writeable for the script. Until 8.8.4 this test printed only a message in case of an problem with that folder. The “(1)” is some kind of a debug information but I guess only for me. I will probably hide this again in 8.8.6.
The “Podcast Feed URL” should be the URL which you want to (or would) submit to the iTunes podcast repository. No, I don’t that using a feedburner feed address there can cause the problems with stats.
I’m hoping that the logs will bring us more information.
Well I am afraid that I need some more hand-holding in debugging this. I have enabled the Print PHP Notices plugin and added the call to printphpnotices_var_dump() in podpress_function.php but when I click the download link in a post I get an error:
“Call to undefined function printphpnotices_var_dump()” in podpress_functions.php. Why would the function be undefined if the plugin is active? Isn’t that what the plugin does? Before I had to insert some code into wp-admin/plugins.php is that still necessary? I tried to put it in but it looks specific to the previous problem we were working on, it doesn’t change the error and I am using a newer version of WP (3.0.1) and podpress (8.8.6 beta 4).
I have a shared host so looking at the apache error logs is only available through my control panel. According to that there are no errors. I will investigate whether I can find a mySQL error log somewhere.
Yes, I am using WP permalinks. I am trying to debug using Full for now (actually tried both but For some reason the printphpnotices_var_dump function is undefined).
About the (1) behind the feed caching folder name: Thanks for telling me what it means. IMHO feedback to the user is almost always a good thing so if its possible to replace the (1) (function result) with a green “OK!” or something it would be awesome but that is very low priority 🙂 e.g., if its a Boolean value True would print a green OK and False a red (not writable) – just a thought.
Sorry I couldn’t get this printphpnotices working. I have to go now, but I’ll try again later…
By the way I am using a custom permalinks structure:
That has not changed for years. But I have updated the permalinks just to see if that was the issue – no joy.
“Call to undefined function …” problem has probably something to do with the order the plugins get loaded by WordPress and that order seems to be the alphabetical order of the plugin folders.
Set some “a”s in front of the printphpnotices folder name (e.g. /plugins/aaaprintphpnotices/printphpnotices.php) and reactivate the plugin.
(If this is not working then you could insert the function and the definition of the constant from the plugin file to the podpress_functions.php.)
I have tested with your custom permalink structure. The download counter worked with that, too.
I’m going to change the “(1)”.
OK. The aaa in front of the plugin folder name worked. Now I am getting debug info. I clicked the download link and got a proper-looking INSERT statement but it says false afterwords. I will send you the printphpnotices_log.dat file by email so I don’t share my info with the world.
Is it safe to drop the tables wp_podpress_stats and wp_podpress_statcounts? Will podpress recreate these? There is no data in them at the moment anyway…
Yes, you can drop the tables. podPress creates these tables in case they are not existing when you reactivate the plugin.
It seems that dropping the tables and reactivating the plugin fixed the problem. So did the schema change since older versions of podpress? I have another site with the same issue. I can compare the tables if it is useful to you.
By the way, I just read an article that said it it useful to store your plugin’s version info in the table so you know when to update the schema. I know you didn’t create this plugin and you are trying not to change it too much, but IMHO that who stats feature should be re-worked so that there is just one table for podpress, all info is stored and the user can decide what to display on the admin page and elsewhere (counts, full or full+ all come from the same table).
Thanks for the help in debugging this. I will move on to another problem 🙂
It is great that it works now.
I have not changed the schema in the stable versions and not at all for the wp_podpress_statcounts table.
8.8.6 beta 4 creates a wp_podpress_stats table with a further column on reactivation. This “completed” column is for the Full+ logging method. In all podPress 8.8.x version was no line of code which would add this column. Not on first installations and not during reactivation. As i understand it, there is only one situation in which podPress would add this column and that is an upgrade from an old version and podPress 7.9.
I have adjusted the function which creates these tables on plugin reactivation because I wanted to see if and how the Full+ logging method works.
Until 184.108.40.206 this logging method is in the result the same as Full. It does definitely more things than Full but when it tries to write into the not-existing “completed” column it goes on without a notice. It does not create this column.
But I’m pretty sure that this not-existing column did not caused the problem because you have written that none of the logging methods have worked and the Counts Only method writes into a different table.
Sure, the statistic feature needs more adjustments e.g. unique media file identifiers and not only the file name (without the path or the URL as it is now) but this is nothing I want to change in 8.8.6.
So, when you try to recreate this effect in a different blog then use 220.127.116.11 to re-create the tables on reactivation. That should work also and if it has something to do with the new column 8.8.6 beta 4 creates in the wp_podpress_stats table.
I will try with 18.104.22.168 first but I don’t think that new column is the problem either. I haven’t used podpress stats in a *long* time (years). I just realized that the stats and show download counts have been on on this blog and never worked. This blog’s db had no data in those tables and I have had podpress running on it for about 4 years. So in all that time not one insert went into those tables. I have always used feedburner to look at stats for my podcasts.
Now that stats are working, I will use them. I will try to get some error messages out of the second blog tomorrow just in case it is useful for you. But the main thing, as far as I’m concerned, is that this plugin is working better than it ever has. Thanks for your efforts.
- The topic ‘[Plugin: Podpress] "Show Download Stats" not working’ is closed to new replies.