Our plan going forward is to improve the reporting feature. Part of that plan has been a complete overhaul of the initial underlying architecture.
In the past, DLM has relied on 2 (very different) methods of logging (tracking) downloads:
– post_meta -> highly unscalable and makes report loading REALLY slow, when you get over 20-100,000 records in your DB
– custom tables (logs) -> scalable but completely de-coupled from post_meta.
That has led to:
– inaccuracies w/ the reports, having 2 different values for the same file reported under:
-> download counts
-> reports section
Basically, a file would show various stats, inconsistent, because these two methods of logging data were not “coupled” together. More so, allowing users to either delete logs OR modify the “download count” values led, again, to inaccurate reporting – Download Monitor’s core promise and value offering.
With Download Monitor 4.6.x we decided to move to a more accurate reporting system – a real logging system that could be used for creating real reports. To achieve this, we updated the database and added a new table: dlm_reports_log. This newly added table stores the information necessary for the reports page’s chart. This information stored also contains the date the file was download on, as well as the download’s ID.
This new Reports update also mainly depended on the download_log table which had all the logs stored. However, after the update a new problem arose. Those logs could be deleted (before 4.6.x) and because of that the reports would not be very accurate. Also because logs could be deleted, after the update, users were reporting a smaller number of downloads, rather what they had before the update. After the update, another complication we did not foresaw was brought to our attention. Users that had a very large number of logs in the database were having performance issues.
To improve the plugin and solve the above complications, we came up with a solution (version 4.7.0) – which is introducing another table dlm_downloads. This new table is derived from download_log, which contains downloads’ ID entries, download logs, and versions download count. Another improvement was added in version 4.7.3 – to also get the count from post_meta and add it to the download logs from the custom tables and show that sum as the download count. We also returned the old download count from post meta under a new name, Manual download counts.
However, with this new change, the number of downloads from the front-end might be larger, maybe even double. To solve this, we create a simple free plugin – which will synchronize old download counts with the new ones. This will ensure the new sum will be the old download counts each user had before the update to 4.6.x.
To synchronize it please download the following plugin:
