Attached JPG file not viewable

[KenHaynes]

Script URL: http://support.primedefenseproducts.com
Version of script: 2.3
Hosting company: Bluehost
URL of phpinfo.php: http://support.primedefenseproducts.com/phpinfo.php
URL of session_test.php: ???
What terms did you try when SEARCHING for a solution: graphic jpg invalid

Write your message below:

Hi,

JPG files can be uploaded successfully as an attachment. Both Admin and Customers have access.

However, when either save and attempt to view the file, it cannot be viewed as the software does not recognise it as a valid format. The file size is correct but the dimensions of the file are show as 0 X 0 X 0 in my file viewer.

Any ideas?

Many thanks,
Ken.

[mkoch227]

If you could check a few things for me:

• Make sure .jpg is an allowed file extension under Settings --> Service Desk, under "Allowed File Types" (it is the second listed by default. In addition, HESK will look at .jpegs differently than .jpg in most cases.)
• Make sure the .jpg you are uploading does not exceed 1) the "File Size Limit (KB)" in Settings --> Service Desk, as well as 2) "max_file_uploads" size in your php.ini (yours is currently at 20MB).

If it still does not work, please let me know and I will open a test ticket on your help desk, in which you can send me a JPG. I will also run a test ticket on my server and see if I can view it (I am also hosted with Bluehost).

[KenHaynes]

Thanks for the reply Mike.

The file size of the jpg was 510kb.

I have confirmed the settings you mentioned and they are all correct.

Just to clarify, the error occurred when I filed a test ticket.

Many thanks,
Ken.

[mkoch227]

I ran a test ticket and everything worked fine on my end. Can you check one more thing for me? Make sure the "attachments" directory in your hesk folder (public_html/<hesk>/attachments) is CHMOD to 777. If it's not 777, HESK may not be able to write to it, causing attachment issues.

You can view my test ticket w/attachment if you like at http://support.kandbconsult.com/ticket. ... H-5UR-2ET3

[KenHaynes]

Hi Mike,

Thanks for the reply.

Nope, the directory was not set to write - D'oh! It is now but that did not resolve the issue.

Any ideas?

Thanks,
Ken.

[Klemen]

It's the same problem as with the security image - your server (or modified files) is adding byte order mark to files (a few "hidden" utf-8 related bytes at the start of each file).

For example I just uploaded a 4 byte test.txt file to your help desk, however when the file is downloaded it size is increased to 6 bytes.

[KenHaynes]

Hi Kleman,

Thanks for your help.

I ran a few tests and found that the attachments on my server were correct so I turned my attention to the download side of things.

I added the following lines of code to download_attachment.php and this resolved the issue:

ob_clean ();
flush ();

readfile($hesk_settings['server_path'].'/attachments/'.$file['saved_name']); // Not modified
exit ();

Regards,
Ken.

[Klemen]

Yes, but the underlying problem still is that either your PHP files are modified or your server is adding empty line to parsed pages - hence the security image isn't working.

[KenHaynes]

I don't quite get the "Yes, but".

This issue was not caused by my server, it was caused by the buffer not being flushed prior to the read. Even the example in the PHP Manual shows that. You informed me that it was DOM related which was clearly incorrect and I have no plans to resolve the other issue as I am using the text based CAPTCHA version which works just fine, as I have stated in my other thread.

[Klemen]

Whoa, hold your horses and don't get offended, my intention here is to help.

If you check your other thread I corrected myself there - the problem isn't BOM, but "0d 0a" (empty line) bytes at the start of the file.

These bytes are not included with HESK so you either modified files or for some strange reason the server is adding them. Obviously, the problem was file modification as can be seen from the output HTML source code that is not properly structured, as can be seen for example from the "Knowledgebase" page:
http://support.primedefenseproducts.com ... gebase.php

The reason you needed to add flush() are these exact two bytes "0d 0a" which were corrupting downloaded files.

So yes, what you did fixed the download problem. But no, this is not an issue with the original HESK files. These bytes did not come from the original HESK files and with the original files flush() isn't required. After all, the exact same code works flawlessly on thousands of servers.

Also, while this might have fixed your self-inflicted download problems, it won't fix other possible issues because of incorrect file modifications.

[KenHaynes]

I think we may of gotten off on the wrong foot, so to speak.

I posted my resolution to the issue I was having to help others. I can see how these misunderstandings happen but honestly, I was trying to be constructive and I felt that I was being put down.

My apologies for any misunderstanding. So ...

I took at look at the CAPTCHA issue and had the imagjpeg function write the graphic to the server. I can confirm the following:

• The graphic is correct and valid on the server

• The value in the graphic is correct and using the value, I was able to submit a query

So it is just not being displayed on the screen any ideas? I will look further when I get back from lunch.

Regards,
Ken.

[KenHaynes]

CAPTCHA issue resolved - see other thread.