rolled back to 4.5.99

I will add some details of my use case, just in case it may be useful.

I don’t really look at stats, just the number of downloads… from time to time I see a large number of data points, which I don’t use, so I delete them all and the download numbers does not change.

Yesterday, this number changed drastically, it seemed that the older downloads were more affected by the slash, probably the newer downloads had all their data points still there…

I don’t know just and idea.

Hello,

You can use this filter dlm_count_meta_downloads located here & here to return true, which will add the post meta count to the logs count, but from 4.6.0 the post meta count will not be incremented anymore and the result will rely on the logs count.

So let’s say you have 20k downloads in post meta and in logs you have 500, the final result will be 20500 downloads.

If you deleted some/large part of the logs I think it’s better to delete them all ( so that it won’t interfere with the download count ), add the filter above and start the logs from 0, this way you’ll have a more precise download count and the reports page will be more relevant.

Hope this clears some of the fog that surrounds the 4.6.x update. We’ll also make a release post that will clear things out and explain more detailed what and why.

Warmly,
Razvan

Thank you for your answer, but I really did not get what is the use of that filter.

I noticed the official version was rolled back to 4.5.99

Thanks

That filter is for backwards compatibility for download count (in case users deleted logs or did not have them). If that filter returns true then it will add the post meta count to the logs count.

If in this table: {prefix}dlm_download_log you have 500 entries for a download (say with the id=5) and in this table: postmeta you also have the meta_key: _download_count which also has 700 downloads then the number displayed on the front will be: {prefix}dlm_download_log + _download_count = 1200 downloads

Warmly,
Mihaela

Thank you for your answer, but I really did not get where to place the filter or how to use it.

• This reply was modified 2 years, 1 month ago by Alain Aubry.

So, Alain Aubury … The thing is that they wrote a “Backwards Compatibility” into the code. But, it’s not an automated compatibility the plugin does on its own. … which doesn’t make sense to me, at all. And, at first, I didn’t get it, either.

Essentially, the backwards compatibility is turned off by default. Which I think is a horrible choice for them to do, But, still.

BACKUP THIS FILE, OR YOUR WHOLE SITE BEFORE DOING ANY OF THIS, just in case.

You must literally go into your File Explorer on your server, and find the file to update. At the top of those two links the creator shared, it has the location of it …
If you go to the “wpcontent” folder *on your server*, then go to the following subfolders named: /plugins/download-monitor/includes/backwards-compatibility/ …. and the file name you’re looking for is class-dlm-backwards-compatibility.php

You open that file on the server by right-clicking it, or you can do it by downloading it and opening it in a text editor offline, and change the line in the TWO LOCATIONS they showed in the links which say $count_meta = apply_filters( 'dlm_count_meta_downloads', false ); … and change the “false” to “true“.
It makes it say that it’s “true” to apply the filter for the “meta” count—the non-logged numbers we entered for the past downloads before they changed it.

If you did this on the server, it automatically should be applied by your server system. If you downloaded it and did it in a text editor, re-upload it back to the server in the same exact spot. Don’t overwrite the one there, unless you already have a backup copy of the original file.

That’s all there is to it … just change that one word.

• This reply was modified 2 years, 1 month ago by greyhawkonline. Reason: adding a "safety" statement to have a backup

WOW…

Hey @greyhawkonline ,

Thank you for the feedback. Yes, the backwards compatibility for the download count is off by default because we don’t know who have deleted what logs and when, and enabling it by default would give most people wrong download counts.

Also ( this involves @caban13 too ), it is highly recommended NOT TO modify plugin files, as with an update the modification will be gone, that is why we’ve introduced a filter there so users can hook to it and change its value. So, adding to your child theme’s functions.php the following code would do what @greyhawkonline informed, but without the negative part of loosing the modification after Download Monitor updates : add_filter( 'dlm_count_meta_downloads', '__return_true' ) – this will make that apply_filters hook to return true and take the post meta’s download count into consideration.

Hope this helps!
Warmly,
Razvan

Oh my god!
I have been waiting for a SIMPLE explanation like this for 3 weeks and 4 days!
I am still in 4.5.99 because of this issue, you are already in 4.7.1 …
Tomorrow I will experiment with this hint.
Alain

Hey Alain,

Sorry for this, seems like both me and my colleague missed to elaborate the “how to” information on adding the hook. I apologize.

Looking forward to hearing your feedback on the above.

Warmly,
Razvan

Razvan—
There’s a pretty high likelihood here that you might be presuming something about your user’s ability to do coding.
This REALLY should’ve been something that was just a checkbox in the WP UI, and not hidden in the code. I can’t fathom why you’d literally take the time to create a Backwards Compatibility option that isn’t something most users would ever even know is there. Most of your users simply use the point-and-click interface in WP, and if the plugin doesn’t show an option there, they don’t know it can be done.
Additionally, the idea that we can’t simply click the blank box and manually type in a starting number for download count in the precise same way we used to, and yet the same function is still possible for Date and Version is simply confounding.
Making it something most users wouldn’t ever find buried in the code seems like the absolute most counterproductive means of doing Backward Compatibility. Especially considering it should be a feature you should consider keeping in the plugin.

Frankly, part of the reason I chose this particular plugin was the ability to do that. Consider a case like this: no one wants to advertise they have gotten no or few downloads. By starting at a number like 100 or 1,000, it’s still clear to the admin how many downloads there’s been, but it helps a site’s activity because people don’t assume a particular download isn’t popular just based on the logged number.
Or in a case, like mine, where we give users webspace to import their blogs from our community to keep content from disappearing—and when I upload individual downloads it’s not a batch or many at a time where I could add the filter in a column. I primarily only use the WP UI. One at a time, and I no longer have the option to easily account for the downloads on their previous site.
There’s a gazillion other uses for this, like using it to show a total download number which includes all downloads of a type—like using one button to show the current issue of a magazine, but making the count show the count of every issue altogether instead of just the ones for the most recent issue. Or appending a number to the beginning of a count to help easily denote when it was posted, like putting a date in front of it that users can see. Or wanting to be able to show totals from various places a file is available. Like if a user offers a PDF for free download, but it’s also available in Print-on-Demand from another site … it’d be nice to be able to include the PoD sales in the count.

While I understand your interest in not using it, I think you might not be considering how many of your users use that feature. You easily could have written that code snippet into a “Enable Manually Entered Download Count” checkbox to permit it for users who need it, while retaining a default which doesn’t use the meta_tag. It could be implemented right below “Ignore Admin Count”, “No duplicate download”, and “Count unique IPs only” in Advanced>Reports. We should be able to count or not count DLs as best fits our website.

@greyhawkonline – thanks for pitching in. Before we start, I’d like to acnowledge that I value every single input and while I might not agree with every single line of text you’ve written above, I do spend time thinking about what was said.

With that out of the way, I’d like to bring to the table the difference between could have and should have.

We’ve got a 3rd party analytics system that we rely on to do statistical analysis on what most of our user base uses / does with DLM. To that extent, it turns out MOST of our user base DID use the logging feature previously. So when rolling out the update, we decided to appeal to that user base instead of the minority of our users, which in turn, did choose NOT TO enable logging.

More so, to be able to ACCURATELY display data in the Reports table we didn’t want anyone to be able to tamper with the data (eg: manually editing download values). We’ve had numerous support tickets where people manually edited their download data to advertise a higher download count and after they’ve gotten enough “real data”, wanted a way to turn it off. That was simply not possible, as both edits were using the same post_meta fields and overwriting the ‘real values’.

Of course, you could argue that we COULD implement a feature to add back this behaviour, but my question would be SHOULD we though? Our promise is to try to deliver download stats that are as accurate as humanly possible. And we are committed to try, as hard as possible on that promise.

In your above message you’ve written: “there’s at least a gazillion use cases like this” – I’d challenge you to name 10 more.

I understand you MIGHT NOT agree with our choices, and that’s fine. We did add the functionality there, but it’s under a filter and NOT a checkbox. After building software for WordPress for over 6 years, we’ve come to the realisation that more options means more headaches. It’s more convenient, but it also raises the question of “honw long until this comes back to us and we want to introduce a potentially breaking chance that we can no longer do?”.

Since this is GPL software, you are free to take it, fork it and add to it whatever features you think make sense.

That’s the beauty of open-source. You don’t like something? You can an always fork it and add whatever you feel is missing to the code base.

Legally, no one’s stopping you.

I hope all of the above make sense to you too, as they did to me.

P.S: I want to make it clear that I find this a constructive conversation, I just don’t agree with your arguments as they stand.

Much love,
/Cristian.

Hi

I updated to 4.7.1 in my local install and I added the filter:
add_filter( 'dlm_count_meta_downloads', '__return_true' )
in my function.php file.

Problem, it instantly duplicated all my download values !

Please make this thing backwards compatible, I have used your plugin for many years (4 or 5) this is the first time I have issues.

Rolled back again to 4.5.99 and waiting.

Thanks
Alain

Hey @caban13 ,

If it DUPLICATED all your values means that you have the same amount of downloads in logs as you have in post meta, I’m a little confused. Could you give us an example of a Download that had its download count slashed after the update? And could you give us exact numbers, like it went from 200 to 16.

As seeing you deleted the logs and don’t really care about the reports you can do the following:
– If using version 4.5.99 delete all logs
– Update to 4.7.1/4.7.2
– Go to dashboard > Downloads > Settings > Advanced > Miscellaneous > Recreate the upgrade environment and upgrade the DB again ( this will delete the counts created by the logs, so you’ll have 0 counts from the new system )
– Go to functions and re-add the filter I gave you before, so that you can rely on the post meta.

Now, you should have 0 logs/new downloads and should rely for the download count only on the counts from the post meta. After this update ( 4.5.99 -> 4.7.x ) the counts from the post meta will be the same and the increase of the download count will be based on the new system, this way you should have the correct count number.

Does this make sense to you?

Warmly,
Razvan

@cristianraiber-1 …
Good morning!
I understand this is a difficult conversation, because it’s about something you had a hand in creating, so I appreciate that you’re taking the time to talk about why you made the choices you did.

One of the first questions I’d have is why the User you described didn’t simply change the meta count to “0” when they decided they’d gotten enough downloads.

Regarding your “challenge” to think of more examples, I don’t find that constructive or particularly helpful to the conversation. It’s inherently dismissive of the examples I already gave. My saying there’s “a gazillion” other examples is clearly hyperbole, and “challenging” me to find a comparably small number more carries with it the connotation that you didn’t listen to those I gave. But, I can just presume it was simply a poor choice of words.

The “choice” you’re presenting goes directly back to my point—you’re presuming your Users have a far higher degree of technical knowledge or ability about coding that simply isn’t the case. Saying I could always do it myself is disingenuous, at best. If I (or any User) had the time and skill to write code and maintain a plugin ourselves, we likely would’ve done so, in the first place. You’re saying you created Backwards Compatibility, but not making it something your Users could actually see (or even know is there) simply turns it into something your Users don’t know they can even do, and a choice they can’t exercise. While I don’t disagree that putting in any option means you have to accept that you may have to consider something could break it later on, and you’d have to fix Users’ problems using it. But, it seems to me that if your analytics has indicated that a download count is something the predominant number of users want, then you wouldn’t preemptively take away one of your core features of being able to do so, and decide all Users should primarily use it in the same way without offering a clear way to use the compatibility you designed. That’s the problem—your assertion that you created backwards compatibility, but we don’t know that and it’s egregiously difficult (for us) to be able to do.

To paraphrase an old adage:

“An option that someone isn’t free to exercise isn’t an option.”

You’ve created, essentially, is referred to as “Hobson’s Choice”. What you’re saying, or to be specific, the tone with which you’re saying it is “take it or leave it”, or more accurately “take it or do it yourself”. That’s not a choice we’re free to exercise.
And telling us only after the fact that it’s there but hidden makes it not an option, as well.
And telling us that we must know how to do coding in order to implement it makes it not an option, as well.

Think about it like this: Your partner tells you they made you dinner. But, you don’t see it in the kitchen or dining room, and they don’t tell you where the food is. Then, their response is that you can either eat what they made or cook for yourself. … is it really an option to have eaten the meal in the first place?
It’s an imperfect analogy, but I’m hoping you take my meaning. You’re doing something great for us in creating compatibility for the plugin that we have a great need for. And it’s not just “food”, but it’s a great meal that is akin to our favorite thing to eat for dinner. But doing so in a way that makes it either ponderously difficult to use it or prevents us from using it entirely, simply means that we can’t use it. I had to go through dozens of webpages, video tutorials, and ask an IT friend just to be able to give Alain (@caban13) that explanation.

Lastly, telling me I can “legally” make my own plugin and that “no one is stopping me” is, again, not particularly productive. It reads as though you’re taking personal offense to my comments, and are lashing back because of it. Let me assure you, I chose this plugin for a reason, and it’s my considered opinion that it’s the absolute best for my needs.
That being said, the tone with which you have responded frankly makes me wish I’d simply given the technical advice rather than attempt to offer opinions, because they were clearly not well received, despite assertions to the contrary. I guarantee IAlain and I are not the only ones to have had this issue. One can almost always assert in any industry that for each report of an issue received that there’s 10x or more instances which go unreported. Consdidering your 100,000+ Users, I would hazard a guess that it’s even higher than that.
… and you’ve just told us all “eat what I made, or cook for yourself”.

• This reply was modified 2 years, 1 month ago by greyhawkonline.