The behavior of the download link is not correct on non picture files. Instead of going to action.php with a Content-Disposition: attachment, the url directly goes to the file. In case of an mp4, the video opens in the web browser, which is really not a "download".
@modus75 as far as my invistigation went, you changed that behavior on Piwigo 2.4. Was it "on purpose"?
The behavior of the download link is not correct on non picture files. Instead of going to action.php with a Content-Disposition: attachment, the url directly goes to the file. In case of an mp4, the video opens in the web browser, which is really not a "download".
@modus75 as far as my invistigation went, you changed that behavior on Piwigo 2.4. Was it "on purpose"?
<!-- github-sync-id:132456078 -->
I don't remember the reason of the change. One explanation would be that I didn't like going through action for potentially large files and I'm pretty sure mp4 were not opening in the browser at that time...
I don't remember the reason of the change. One explanation would be that I didn't like going through action for potentially large files and I'm pretty sure mp4 were not opening in the browser at that time...
<!-- github-comment-id:181937015 -->
If the file transit via PHP in action.php we must use https://gist.github.com/awbush/1545535 for PHP < ?? (might find more info elsewhere)
<!-- github-comment-id:181939947 -->
@mistic100 ok, so let's use readLargeFile instead of readfile :-) but we should always go through action.php and not give file direct url.
@mistic100 ok, so let's use readLargeFile instead of readfile :-) but we should always go through action.php and not give file direct url.
<!-- github-comment-id:181951388 -->
@mistic100 : don't there is any problem with readfile. here is a comment from readfile doc:
"readfile() will not present any memory issues, even when sending large files, on its own. If you encounter an out of memory error ensure that output buffering is off with ..."
@mistic100 : don't there is any problem with readfile. here is a comment from readfile doc:
"readfile() will not present any memory issues, even when sending large files, on its own. If you encounter an out of memory error ensure that output buffering is off with ..."
<!-- github-comment-id:181963606 -->
I remember I used this trick for some misconfigured servers, something users can't configure themselves. I honestly don't remember what was the problem though.
I remember I used this trick for some misconfigured servers, something users can't configure themselves. I honestly don't remember what was the problem though.
<!-- github-comment-id:181965201 -->
I have encountered such problems (on Piwigo.com, for downloading 500MB zip files) but it was years ago and now I simply use a readfile.
Maybe we can wait for a bug report to implement readLargeFile instead of readfile. Maybe this problem never occurs with PHP 5.3+ (https://wordpress.org/about/stats/ says that 90%+ users are on PHP 5.3+)
I have encountered such problems (on Piwigo.com, for downloading 500MB zip files) but it was years ago and now I simply use a readfile.
Maybe we can wait for a bug report to implement readLargeFile instead of readfile. Maybe this problem never occurs with PHP 5.3+ (https://wordpress.org/about/stats/ says that 90%+ users are on PHP 5.3+)
<!-- github-comment-id:181967842 -->
@modus75 can you tell me what you think of https://github.com/Piwigo/Piwigo/commit/a684afbdc33fc904734ee63152e3040dbdbaa1bd ?
<!-- github-comment-id:218108813 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The behavior of the download link is not correct on non picture files. Instead of going to action.php with a Content-Disposition: attachment, the url directly goes to the file. In case of an mp4, the video opens in the web browser, which is really not a "download".
@modus75 as far as my invistigation went, you changed that behavior on Piwigo 2.4. Was it "on purpose"?
I don't remember the reason of the change. One explanation would be that I didn't like going through action for potentially large files and I'm pretty sure mp4 were not opening in the browser at that time...
If the file transit via PHP in action.php we must use https://gist.github.com/awbush/1545535 for PHP < ?? (might find more info elsewhere)
@mistic100 ok, so let's use readLargeFile instead of readfile :-) but we should always go through action.php and not give file direct url.
@mistic100 : don't there is any problem with readfile. here is a comment from readfile doc:
"readfile() will not present any memory issues, even when sending large files, on its own. If you encounter an out of memory error ensure that output buffering is off with ..."
I remember I used this trick for some misconfigured servers, something users can't configure themselves. I honestly don't remember what was the problem though.
I have encountered such problems (on Piwigo.com, for downloading 500MB zip files) but it was years ago and now I simply use a readfile.
Maybe we can wait for a bug report to implement readLargeFile instead of readfile. Maybe this problem never occurs with PHP 5.3+ (https://wordpress.org/about/stats/ says that 90%+ users are on PHP 5.3+)
@modus75 can you tell me what you think of https://github.com/Piwigo/Piwigo/commit/a684afbdc33fc904734ee63152e3040dbdbaa1bd ?
It's ok for me ...