• Resolved jenskettler

    (@jenskettler)


    Hi,
    I use version 3.3.4 of Awesome Support. When a user creates a ticket and attaches a file (we tried various formats: .xlsx, .jpg) it is not possible to download the file: the downloaded file has 0 kb. The filename is correct. Also the user who submitted the ticket/uploaded the file, and the support user have this same issue.
    There is no error message or so when the file is uploaded, and the attachment is correctly displayed with the download link.
    We use the standard list of allowed file types.
    We added some additional CSS to our theme:
    #wpas_files_wrapper .wpas-help-block {
    display:none;
    }

    this disables that the list of supported file types is displayed. We disabled this additional CSS but it does not change the error I described above, it seems this is not a problem.
    Our theme is Support Desk.
    Any ideas?
    Best regards
    Jens

Viewing 15 replies - 1 through 15 (of 15 total)
  • Plugin Author awesomesupport

    (@awesomesupport)

    Hi:

    Lets check to see if the file is located where it shoudl be on your server. It should be in uploads/awesome-support/ticket_nnnn where nnnn is the ticket number. If you see the file there then try to download it using the direct URL and see if that works.

    Also, might want to check the consistency of your website url under the WordPress settings menu – make sure both entries are http or https.

    Finally you can try disabling all the other plugins and switch your theme to 2015/16/17 to see if that eliminates a conflict that could be occurring.

    Thanks.

    Thread Starter jenskettler

    (@jenskettler)

    Hi,
    thank you for the quick reply. The files are actually available in uploads/awesome-support/ticket_nnnn
    and I can download them with ftp or with the correct link,
    https://<my domain>/wp-content/uploads/awesome-support/ticket_659/RO-with-star.jpg
    The link in the support ticket goes to e.g.
    https://<my domain>/?wpas-attachment=660
    where 660 is _not_ the ticket number but ticket number + 1.
    When I manually change the number to the ticket number (in the example above:659) I get a message: “The file you requested is not a valid attachment”
    So I think the URL in the ticket is wrong.
    I have not seen where I can change that URL.
    Best regards
    Jens
    The files in the upload directory look like this:
    https://www.dropbox.com/s/bo5nztidne1s6bj/Bildschirmfoto%202017-05-05%20um%2012.46.35.png?dl=0

    Plugin Author awesomesupport

    (@awesomesupport)

    Hi:

    660 is not the ticket number – its just a random number that has no relation to the ticket number. Internally it refers to the real file name.

    Have you tried turning off plugins/themes to see if this fixes the issue? If that doesn’t do it then I would suspect that there is a server configuration that is causing this behavior. Who is your hosting provider?

    Thanks.

    Thread Starter jenskettler

    (@jenskettler)

    Hi,
    I did try to deactivate other plugins but did not help. Our site is hosted here:
    https://www.hetzner.de/ot/
    Our website is remedyne.help

    I can download the files with ftp or with the correct link,
    https://<my domain>/wp-content/uploads/awesome-support/ticket_659/RO-with-star.jpg
    The link in the support ticket goes to e.g.
    https://<my domain>/?wpas-attachment=660

    I also noted that uploading more than 1 attachment to a ticket does not work properly:
    when a user adds a 2nd file, only the last filename is shown and then attached to the ticket. the first upload file is “replaced” by the second.

    Plugin Author awesomesupport

    (@awesomesupport)

    Hi:

    You can select two files from the file dialog box but, yes, if you try to select two different files at two different times only the last one will be selected.

    Regarding the download issue – I’m out of suggestions – I suspect it’s related to how the server itself is set up but we’re not equipped to troubleshoot server specific issues in this free forum. Maybe someone else who is adept at server setups can jump in and offer some suggestions.

    Thanks.

    I have the same problem and still no luck with the new version either. @jenskettler have you fixed the issue?

    Thread Starter jenskettler

    (@jenskettler)

    not really fixed this. A consultant fixed it (both issues, downloads and adding multiple attachments), but the change will be lost when we do an upgrade of the plugin. Now considering what our options are.

    Plugin Author awesomesupport

    (@awesomesupport)

    Hello @jenskettler:

    Can you please let us know what changes the consultant made – especially if he/she made code changes to the core plugin? We have not be able to reproduce this issue so it would be great to see what was changed.

    Thanks very much.

    @jenskettler It would be so kind of you to tell us what has been done to fix this problem.

    Thread Starter jenskettler

    (@jenskettler)

    Hi,
    the consultant changed 1 line:

    in class-file-uploader.php line

    readfile( $attachment->guid );

    replaced with

    echo readfile( $_SERVER[‘DOCUMENT_ROOT’] . parse_url($attachment->guid, PHP_URL_PATH) );

    Thank you @jenskettler
    Unfortunately this didn’t work for me. Are you sure that just this one line has to be changed?

    Thread Starter jenskettler

    (@jenskettler)

    yes, but could depend on php version and server configuration.
    I can put you in touch with the consultant, send me your contact details if you are interested. You would have to pay him.

    I definitely would pay if I could. But I’m living in a part of the world that has no connection to international payment systems, is it even believable??!
    Anyway, as you have kindly given the plugin authors a clue, I hope they can fix it for good. @awesomesupport please tell us your idea and what we can do further.

    Thanks very much Jens,
    I followed your advice (or… the consultants) and voila, it works!
    But I do have a remark for mpeivandi because the code you posted was not placed in code style, so there were errors in it. The apostrophes were replaced by left and right single quotation marks.

    So in class-file-uploader.php line 499:

    readfile( $attachment->guid );

    needs to be replaced with

    echo readfile( $_SERVER['DOCUMENT_ROOT'] . parse_url($attachment->guid, PHP_URL_PATH) );

    By the way, I was looking for a way to solve the error messages I got on my webserver. The error message was:

    PHP Warning: readfile(): https:// wrapper is disabled in the server configuration by allow_url_fopen=0 in [..]/awesome-support/includes/file-uploader/class-file-uploader.php on line 252

    No more error messages now. So thanks again!

    • This reply was modified 7 years, 1 month ago by janpaulkleijn.
    • This reply was modified 7 years, 1 month ago by janpaulkleijn. Reason: google search
    • This reply was modified 7 years, 1 month ago by janpaulkleijn.
    • This reply was modified 7 years, 1 month ago by janpaulkleijn.

    Same issue here on a new server, changed line 251 to use “attachment” as Content-Disposition instead of “inline”

    header( "Content-Disposition: attachment; filename=\"$filename\"" );

    Not sure where my settings are wrong to cause this to be needed, but the above works.

    CentOS 7.4.1708 with Apache 2.4.6 and PHP 7.2

    • This reply was modified 6 years, 7 months ago by agcyphers. Reason: Notifications
    • This reply was modified 6 years, 7 months ago by agcyphers. Reason: System specs
Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Download of attachment: downloaded file 0 kb’ is closed to new replies.