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
.
