HIKASHOP ESSENTIAL 60€The basic version. With the main features for a little shop.
HIKAMARKETAdd-on Create a multivendor platform. Enable many vendors on your website.
HIKASERIALAdd-on Sale e-tickets, vouchers, gift certificates, serial numbers and more!
MARKETPLACEPlugins, modules and other kinds of integrations for HikaShop
-- url of the page with the problem -- : example order -
smoothchords.com/administrator/index.php...d=1869&order_id=5566
-- HikaShop version -- : HikaShop Business: 2.2.3
-- Joomla version -- : 2.5.17
-- PHP version -- : 5.4.24
-- Browser(s) name and version -- : any (tested in Firefox 26.0 and Chrome 32.0.1700.102)
-- Error-message(debug-mod must be tuned on) -- : "Firefox can't find the file at
smoothchords.com/administrator/index.php...d=1869&order_id=5566
."
This site sells downloadable products consisting of zip, mov and mp3 files. For some of the orders, the purchased downloadable product link is not working and we're getting, ie, "Firefox cannot find the file at 'download_url'". The database records look intact and I'm not seeing any signs of database corruption and the file is there in the media/com_hikashop/upload/safe directory.
In our testing the only files having the issue are certain mov files. The zip files I've tested are working. I've ensured that the HikaShop configuration allows for the mov file type. I'm not sure what is the issue is for these orders. I thought it might be the size of the files that is the issue (400MB+) so we tried modifying the server configuration's execution time and allowed memory but that didn't have any result on the issue. Also, the 'cannot find the file' error doesn't seem to related to a server configuration issue. The error we see when logged into the Joomla backend, viewing the order, and clicking the download link is the same one that would be seen if you just tried to browse to the download link URL without authenticating to Joomla.
Please Log in or Create an account to join the conversation.
Hi,
We will need some credentials in order to see the problem directly.
Some database information will be required too, like the line content of the id 1869 of the table hikashop_file
Regards,
Please Log in or Create an account to join the conversation.
How should I supply that information to you?
Please Log in or Create an account to join the conversation.
You can send via our contact form:
www.hikashop.com/contact-us.html
Please also provide a link to this thread in your message
Please Log in or Create an account to join the conversation.
I've sent you the admin url and credentials. I'm attaching a screenshot of the database record.
Please Log in or Create an account to join the conversation.
Hi there,
I was about to do some testing but I can't find the huge file you are talking about.
Could you give me more informations about it and maybe prepare a link to the page where I can try to download it?
Please Log in or Create an account to join the conversation.
Hi, I supplied URLs in the original post above. You can log into the backend and go to HikaShop > Orders. Edit an order and try clicking on the link for the file purchased. Example URL/Order below:
Order: 5566
smoothchords.com/administrator/index.php...d=1869&order_id=5566
I was asked to send login credentials to you via the support form, which I did last week.
Please Log in or Create an account to join the conversation.
Hi, I have the same problem here, is there a solution?
Please Log in or Create an account to join the conversation.
I have not received a solution yet and I posted the ticket almost two weeks ago. I have a client with a very active store, whose customers cannot download their products so this is very critical. HikaShop??
Please Log in or Create an account to join the conversation.
Hi,
The way that your server return a not-really-blank-page does not look like as a direct return of HikaShop.
I think that it could have some kind of permission problem or PHP error.
Having access to the PHP error log or having a FTP access in order to activate some debug trace in the "sendFile" function will help us to better understand the problem ; and fix it.
Regards,
Please Log in or Create an account to join the conversation.
Jerome - I've just sent FTP credentials over to you via private message. I do not believe its a permission problem because zip files and smaller mov files are working. Its just the large mov files that are around 400MB+ in size.
Please Log in or Create an account to join the conversation.
Hi,
I made a lot of tests and the problem is related with your web hosting.
HikaShop right open the file and start to send it but, your server stop the PHP process if we send too much data.
More than stopping the process, nothing is send to the client, like if the buffer if too big, it send nothing at all.
Like I said, I made a lot of tests in order to find a way to bypass it, and I found nothing.
Even if I do not use the "output buffering" of PHP and I use the direct output, I can't send the complete file.
I could send some (very) smaller data but that's all.
Please see with your web hosting for this limitation.
Regards,
Please Log in or Create an account to join the conversation.
We've tested the hosting server settings; adjusted PHP execution times and memory and none of the PHP adjustments have made any difference. As a test I added one of the same large mov files within a different Joomla extension on the same website and I'm able to download the file without an issue. The download process is being successfully processed through PHP and I was able to download a 1.5GB mov file through the other extension just fine.
Please Log in or Create an account to join the conversation.
Hi,
Are you really sure that you download 1.5GB through another extension and not download the file directly in the server ?
Because there is a huge difference between calling a PHP page which will send you "manually" a file (with the time limitations we know) and download a file directly in the web server (without time limitation because there is not PHP, it is a classical download).
Redirecting the user to another url works but it is not something safe because everybody can access to the file with the right url.
What I can propose you is a little patch in order to use "readfile" instead of reading manually the file.
I know that there is something strange with the output buffering so we can try to avoid it.
You have to make some replacement in the "administrator/component/com_hikashop/classes/file.php" file.
header("Expires: 0");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="' . $name . '"');
header('Content-Length: '.($seek_end - $seek_start + 1));
header("Cache-Control: maxage=1");
header("Pragma: public");
header("Content-Transfer-Encoding: binary");
$fp = fopen($filename, 'rb'); header("Expires: 0");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="' . $name . '"');
header("Cache-Control: maxage=1");
header("Pragma: public");
header("Content-Transfer-Encoding: binary");
if($seek_start == 0) {
header('Content-Length: ' . filesize($filename));
if(!ini_get('safe_mode')){
set_time_limit(0);
}
while(ob_get_level() > 1)
ob_end_clean();
flush();
readfile($filename);
exit;
}
header('Content-Length: '.($seek_end - $seek_start + 1));
$fp = fopen($filename, 'rb');Please Log in or Create an account to join the conversation.
Yes, I'm sure the download from the other extension was not a direct download from the server. I setup it up as a test of the server's configuration for this purpose. The URL for the download was not like domain.com/file.mov but rather something like domain.com/index.php?option=com_component&task=download&format=raw&id=432947832947owjresfjdkslau398473294u3289
Please Log in or Create an account to join the conversation.
I've made these modifications to file.php but it made no difference. I'm still getting the same 'file not found' error when trying to download the large product downloads. It seems to begin having an issue at around 150MB.
Please Log in or Create an account to join the conversation.
Hi,
There is no logical reason that your server accept sending "small" files and completely block while sending big files.
Please provide more details about the component which work for you. If you want us to find a solution, we need more details because I have activated/deactivated all buffer settings and it does not change anything.
Regards,
Please Log in or Create an account to join the conversation.
Hi, Jerome -
The component I used for testing was Zoo. I setup one of the large product files as a download in a Zoo item using the Download element in Attachment mode.
Its possible that the correlation is not file size, but file size seems to be the common denominator with regard to files that work vs files that do not.
Please Log in or Create an account to join the conversation.
Hi,
I finally got a working association, forcing the time_limit and the output buffering:
if($seek_start == 0) {
header('Content-Length: ' . filesize($filename));
session_write_close();
set_time_limit(0);
ini_set('output_buffering', 0);
ini_set('zlib.output_compression', 0);
while(ob_get_level())
@ob_end_clean();
flush();
readfile($filename);
exit;
}Please Log in or Create an account to join the conversation.
That worked! Thanks so much! So, basically, we need to set output_buffering = 0 and zlib.output_compression = 0 in php.ini?
Output buffering and zlib.output_compression are currently turned off.
Please Log in or Create an account to join the conversation.
