Advansys
Forum Replies Created
-
Forum: Plugins
In reply to: [Download Monitor] Access Denied to this fileI experienced the same problem because my download directory is outside my WordPress subdirectory.
To resolve the access denied error for my existing downloads, I edited the absolute path and changed it to a relative path:
From: /home/[domain]/public_html/downloads
To: ../../downloads
This fixed the issue for my configuration. I simply guessed the number of .. (parent) levels I had to use in the path relative to my WordPress subdirectory.
If the Download Monitor plugin developers change the ‘current directory’ variable to a different value, this solution may break.
Forum: Plugins
In reply to: [WooPayments: Integrated WooCommerce Payments] Question about refund processThanks @battouly, appreciated.
Forum: Plugins
In reply to: [WooPayments: Integrated WooCommerce Payments] Plugin Change logThanks Jeremy, was just curious and didn’t know if you guys were aware.
Cheers,
Greg
Hi @nicw,
Thank you for your quick reply and the information. I like the idea of the WooCommerce dashboard integration and wanted to be sure it didn’t require additional security steps (over and above the Stripe Standard plugin) to benefit from the features.
Thanks again.
Forum: Plugins
In reply to: [Download Monitor] zip files corruptingThanks Harish, I appreciate your comments.
The main observation which doesn’t make sense to me is the fact that the browser reported download size when using DM is always and consistently incorrect for these large files, in this case by 1 MB, i.e. 205 MB instead of the real file size being 206 MB.
How could it be a memory or timeout issue when the browser immediately reports the wrong file size immediately at the beginning of the process?
The browser always downloads exactly the amount of data as reported at the beginning of the download process initiated by DM. It is not stopping at any point during the download because the browser downloads exactly what it displays it’s going to do… download 205 MB displayed using DM and not the correct 206 MB when using direct https.
The fact the browser reports an initial 205 MB file size and not 206 MB when using DL is likely the key clue to finding the cause.
Do you know which part of the DM download process is responsible for reporting the initial file size to be downloaded? Do you know where can I review/research this process?
Thanks,
Greg
Forum: Plugins
In reply to: [Download Monitor] zip files corruptingHi Harish,
Thanks very much for the “Redirect to File” suggestion, which does work around the problem! 🙂
The symptom I don’t understand, when not using redirect to file, is why Chrome reports 205MB when using Download Monitor (DM) and yet a direct https link reports 206MB, which is correct and the downloaded file opens just fine.
In both cases, the Chrome browser downloads the reported amount of data (i.e. the download stats shown in the download display area in the bottom bar of the browser), it’s just that when using DM without redirect to file, the file size reported is incorrect.
How could using DM influence the initial file size reported by the browser?
Kind Regards,
Greg
Forum: Plugins
In reply to: [Download Monitor] zip files corruptingThanks for your quick reply Harish. This issue is baffling at present. Cannot see anything relevant in the logs and am also communicating with the host provider, although nothing obvious discovered at this stage.
I upload the file using FTP directly to the target directory. I do not upload it using Download Monitor, I manually enter the path to the file location after it is FTP’d.
This is the same approach I’ve used for all downloads for years and which work AOK except for these large files. I tested a small zip file and it works AOK. So it seems only very large files are impacted, the one tested is 206 MB and DM serves 205 MB instead, resulting in an invalid ZIP file.
As mentioned, downloading the same file via a browser using the direct URL works AOK, so it cannot be the source file, it has to be related to the PHP serving process. However, the host provider and I are not aware of any php.ini settings which impact the download process.
There is likely to be a simple explanation… once it is known!
Cheers,
Greg
Forum: Plugins
In reply to: [Email Before Download] Download doesn’t showI have the same problem. It looks like this plugin is not maintained any more. 🙁
Forum: Plugins
In reply to: [bbPress Notify (No-Spam)] Reply creation issues since recent updateHi Vinny,
Updated to 2.1 and still have the same issue when using the subject encoding option. I will review the logs when I get the opportunity. Currently unchecking the subject encoding option solves the issue.
Thanks,
Greg
Forum: Plugins
In reply to: [bbPress Notify (No-Spam)] Reply creation issues since recent updateThanks very much Vinny, will do!
Cheers,
GregForum: Plugins
In reply to: [Email Before Download] rest_no_route messageI fixed this issue… I think it was the incorrect download ID, although I did try the correct one previously and it hadn’t worked… must have been a different issue (was making many changes attempting to get it to work).
All good with respect to this particular issue now.
Thank you to the M&S team for all your efforts.
Forum: Plugins
In reply to: [Email Before Download] rest_no_route messageAfter upgrading to the above versions, I am also receiving this error. It cannot find the download and the [Download Not Found] link points to the “rest_no_route” message as in the above post.
Forum: Plugins
In reply to: [Email Before Download] Errors on PHP7 platformEmail Before Download requires Download Monitor and Contact Form 7 plugins. It can use the latest version of both of those plugins (I do so on several sites).
That’s really interesting dtynan, thanks for this information.
I was caught with this one too after the 4.4 upgrade. I agree that a note or legend about the meaning of the red color would be helpful.
Highly useful plugin, thank you!
Forum: Plugins
In reply to: [Email Before Download] Not working on WordPress.org 4.4?@m&S Consulting: It would be most appreciated if you could confirm whether or not you have been able to reproduce the problem based on the information provided in this thread? If so, what is the next step to finding the cause and hopefully a suitable resolution rather than the work-around?
While the renaming of the Contact Form 7 email field to the default seems to be a work-around, until the cause is known, there cannot be any confidence that another issue related to the same cause may arise during a future WordPress update.