Search Results for 'Add Url'

Hi there,

I am having problems with downloading files from the frontend that are not locked but should be free instead. In the WP Error Log I am repeatedly receiving the following errors:

[07-Jan-2020 10:19:11 UTC] PHP Notice: Undefined variable: regurl in /var/www/…/…/…/wp-content/plugins/download-manager/tpls/wpdm-login-form.php on line 114
[07-Jan-2020 10:19:11 UTC] PHP Notice: Undefined variable: log_redirect in /var/www/…/…/…/wp-content/plugins/download-manager/tpls/wpdm-login-form.php on line 120
[07-Jan-2020 10:19:11 UTC] PHP Notice: Undefined variable: log_redirect in /var/www/…/…/…/wp-content/plugins/download-manager/tpls/wpdm-login-form.php on line 149

The DM is version 5.0.4 and runs with the following add-ons:

Advanced Custom Fields ( wpdm-advanced-custom-fields.zip ) 1.9.5
WPDM – Form Lock ( wpdm-form-lock.zip ) 1.7.0
WPDM – Form Lock ( liveforms.zip ) 3.7.3
Download Notifications ( wpdm-email-notification.zip ) 1.4.0

Wordpress Version is 5.3.2. PHP Version is 7.3

Is this a bug or a misconfiguration?

Best wishes

Thomas

Hi there,

this might be a request for the Pro version, let’s see.

Let’s assume I have a dozens of packages with dozens of files included.
General purpose: Download Area for a mid-sized PC/Laptop manufacturer. Each package is one individual PC/Laptop-Model.

The files have generic filenames like “myfile.zip”.
A lot of the dozens (if not hundreds) of packages link to the same files, becaus some drivers are generic and compatible with a wide range of models.
But some of them link to others, less generic, more specialized ones. The logic, which package links to which files, is exclusively represented in the backend configuration of each package. For the purpose of understanding the usage scenario, let’s say: 80% of the files in each package links to generic files and 20% link to specialized, unique files.

Now in the FTP, I might replace the generic “myfile.zip” with an updated version, but without changing the filename. (No version numbers in filenames)

This is cool, because with this single action I have automatically updated the content of dozens (if not hundreds) of packages without having to click around the backend for hours.

Problem: the end-user does not see that an update has taken place. When looking at a specific package, the user does not see the upload date (last modified date) for each individual file.

*** Proposal: the frontend should be able to display the ‘last modified date’ for each individual file. ***

This could be done in 2 ways:

Solution A) Real-time query

When the frontend is building a the page for a package for the end-user, it could use some scripting to query the real URL location of each file to read the “Last modified date” for it. This should be possible via “HTTP HEAD” request as outlined here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified

This real-time query should be optional because it might slightly slow down the parsing of the frontend page.

Solution B) Additional SQL column and Index re-build function

The “Last Modified Date” for each file could be stored in a SQL column. This way it would be quick and easy to parse during the end-user loading of the Package.
But if I replace a file on the FTP server (without changing the filename), the WordPress Plugin and SQL database will not take note of that change. Thus, you need a “Rebuild Index” or “Re-query last modified date” function in the backend. This could be a sample button that re-queries every currently known link (as in every unique wpdmdl=abc&ind=xyz combination), reads the “last modified date” for each file from the server and writes it into the SQL field for each such link. This query might take a few seconds and should probably only be done during low load time or maintanance.

*** Final thoughts ***

I have thought about this problem a lot and I’m 99% sure that my proposal is the only viable solution. The fact that this plugin currently cannot easily display the “last modified date” of individual files (without long, convoluted clicking through the backend for hours) is a big oversight in this otherwise extremely useful and highly functional wordpress plugin.

Please let me know what you think or if you have any questions. Thank you!

Best Regards,
Tom Fichtner, Germany

Hi

I have a category containing 13 downloads. In WordPress 5.3, and plugin version 3.0.5, I use this shortcode:

[wpdm_category id="Club documents" /]

The post appears with the first 10 downloads, which is as expected. Then I click on page 2 in the pagination controls, but when the page reloads, I am still on page 1.

I can see is that the following query parameter has been added to the URL, but I’ve not tried to trace where this is used in the plugin code.

?cp_Club%20documents=2

Is this a known bug? Can anything be done to make it work? I know one workaround is to increase the downloads per page to make pagination unnecessary, but I’d sooner not have to do that.

Thanks …