Announcement

Collapse
No announcement yet.

File attachment oddness

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bill
    replied
    My first bug report. I tried to make it as simple as possible https://tracker.vbulletin.com/vbulle...sues/VBV-19259

    Leave a comment:


  • Wayne Luke
    replied
    You'll have to submit a bug report with exact steps to recreate in a list order starting from pressing the New Article button to causing the error. Then we can have the developers look at the issue.

    https://tracker.vbulletin.com/vbulletin5

    Leave a comment:


  • bill
    replied
    I understand about PDF and other non-image files not being meant to be placed inline. It took me a bit to understand the issue in regards to the vB WYSIWYG.
    I am not trying to place thumbnails of these types of files into the page. Rather I am trying to place a link in the body of the page to the file for download by the visitor.

    I get it now, but it is going to take some explanation by me to the maintainers of the pages that this is how the vB WYSIWYG works. It's not really intuitive in the vB when creating "pages/articles" as the operation seems to work as expected initially: Images are included as thumbnails, and other files simply become filenames. This works as might be expected (after your tweaks to my system)
    The problem does however resurface upon subsequent editing of a page.

    I made a new Test page, Uploaded several PDFs, Inserted links from the upload attachments area at the bottom of the page, and Saved the page as a Draft. The grey attached files box did not show at the bottom of the resulting page. However, the links to the files in the page worked.
    Code:
    https://example.com/filedata/fetch?id=12345
    That was fine.
    Then I edited the page and saved it as a Draft again. Now the links to the files in the body of the page are broken, but the attached files show at the bottom of the page. The links to Inserted files in the body of the page get transformed to
    Code:
    https://example.com/core/filedata/fetch?id=12345&d=1553067968
    and break.

    So, it appears that your switching off PDF thumbnail generation does initially work. But the page can't be edited if we want to keep those links working.

    If vB did not rewrite and break these links after edits I don't think there would be an issue any longer. Your tweaks to the thumbnail generation of images fixed things for images. Your subsequent tweaks to the thumbnail generation for PDFs does seem to initially work.

    Leave a comment:


  • Wayne Luke
    replied
    The issue is caused by two issues..
    1. PDF Files are not meant to be inserted inline. They would be listed at the bottom of the content in the attached file area.
    2. You're trying to insert PDF Thumbnails that are generated by the system.

    I've turned off PDF Thumbnail Generation for your system. This should prevent the issue with NEW content. It will not fix old attachments or content.

    Leave a comment:


  • bill
    replied
    Wayne helped me fix some issues with thumbnails not displaying properly. That seems to have helped with the problem of actual image files becoming 'corrupt' (The files are not renaming themselves to image_1234.jpg ). I can now place these images into the page using the WYSIWYG toolbar, and they seem to be retaining their original file names, and the links to the files remain intact.

    The other issue I was having was with non-image files, like PDF, ZIP archives, which I need to attach to these pages.
    I have found that if I simply attach these sorts of files they are fine as long as I do not try to Insert them from the Attached Files at the bottom of the page.
    The problem arises if I do Insert the files and save the page. After saving the page, the links to these attached files generated by vB break, and the files listed in the Attached Files section are renamed to something like
    Code:
    image_1234.pdf
    The links generated by vB to non-image files are in this format:
    Code:
    https://example.com/filedata/fetch?id=12345
    When inserting the files via the WYSIWYG the links are in this format:
    Code:
    https://example.com/core/filedata/fetch?id=12345&d=1553067968
    These links lead to Invalid Page URL errors.

    My kludge to work around this is to make plain text into hyperlinks to the files. If I do this, then the files are not renamed to image_1234.pdf format. Also, the hyperlinks lead to the files.

    After many attempts I find this behavior reproducible. Although I have a somewhat usable work-around that I can use, my users who maintain these pages are going to be a bit confused when attempting to maintain these pages.

    Leave a comment:


  • bill
    commented on 's reply
    Wayne, I have sent you a direct message about these pages. They are in a site that is not publicly available without an account, and they are saved as Drafts.

  • bill
    replied
    <delete>
    Last edited by bill; Mon 18th Mar '19, 5:59pm. Reason: delete

    Leave a comment:


  • Wayne Luke
    replied
    What are the links to the articles exhibiting this behavior?

    Leave a comment:


  • bill
    replied
    I tried removing all of the Image, PDF and ZIP files from the article page. As suggested, I then used the toolbar to try to insert about 25 files into the page via the WYSIWYG.
    Instead of saving the page as a Draft, I did a normal save.

    The result was worse.

    None of the images are visible. The file names of the images show up. All of the links from the file names to the image files are broken, and lead to a page with no formatting showing only "Invalid File Specified"

    I have been removing and inserting files with the same names multiple times. I wonder if this has any impact.

    Leave a comment:


  • Wayne Luke
    commented on 's reply
    There really isn't much functional difference between an image, PDF, or ZIP archive as far as the code is concerned.

  • bill
    commented on 's reply
    This isn't just happening to images. It's also PDF and ZIP archives. I'm also uploading 10+ files at a time to the page.

  • Wayne Luke
    commented on 's reply
    Technically yes. If you're storing on the file system. The file would be renamed %attachid%.attach

    But the original name should be retained for the user. It is placed in the title attribute of any img tag and the file would be renamed to the original name when downloaded.

  • In Omnibus
    replied
    I might be thinking of something else but doesn't every image uploaded as an attachment and saved as a filedata extension get renamed?

    Leave a comment:


  • Wayne Luke
    replied
    Can you try inserting the images using the "Insert Image" tool in the toolbar? The image will be inserted at the cursor when you use this and you can still upload images from your local machine.
    Click image for larger version

Name:	2019-03-01_9-45-38.png
Views:	124
Size:	41.9 KB
ID:	4409769


    I will work to recreate the issue with your steps and see if I can write a bug report on it.

    Leave a comment:


  • bill
    replied
    I upload the files from my PC, not from a URL. I will then Insert the files into the Page from the Attached Files section at the bottom of the edit window. At that time the links appear correct. The file names are unchanged. Then upon subsequent edits, again saving as Draft, some of the files will be renamed image_####.ext

    Links to files, although they appear to be correct will often result in an error:
    Invalid Page URL. If this is an error and the page should exist, please contact the system administrator and tell them how you got this message.
    Unfortunately the only way to determine if a link to an Attached File is not working is to click each one. This happens to both renamed files and files that have retained their original name.

    Also, after multiple edits, sometimes files that are linked in the Page will disappear from the Attached Files list. This happens a lot with images.

    In my Advanced Options for these pages I normally have BBCode rendering, but this happens if I use HTML in the source as well.
    • Enable Comments = No
    • Public Preview = No
    • Display Title = Yes
    • Display Author= Yes
    • Display Published Date= Yes
    • Display Pageviews= Yes
    • Display Comment Count = No
    It appears that multiple edits and saving as Draft is when this occurs. I have not done the same work on Published pages.

    Leave a comment:

Related Topics

Collapse

Working...
X