4.0.5.1 Attachments

[Ocean West]

Would like some guidance and clarity on the file storage and management of the latest version - that gong forward will not require updating post table should url change. 

I have tested 4 different uploads and how the raw data is stored:

1. a PNG uploaded and attached to the post, the file path stored in core_attachements is monthly_2015_05/fmf_email.png.e35cee8e01d485cce21eef39b97899de.png

<p>Attached</p><p> </p><p><a class="ipsAttachLink ipsAttachLink_image" href="/monthly_2015_05/fmf_email.png.e35cee8e01d485cce21eef39b97899de.png"><img data-fileid="22838" class="ipsImage ipsImage_thumbnailed" alt="fmf_email.thumb.png.296cfaca8390706447e6" src="/monthly_2015_05/fmf_email.thumb.png.296cfaca8390706447e662d4b1309c3d.png"></a></p>

2. a PNG uploaded and not attached to the post, the file path stored in core_attachements is monthly_2015_05/fmf.png.fbe8f32e05c391187dfcb2ae7d249641.png​

<p>not attached </p><p> </p>

<p><a href="/monthly_2015_05/fmf.png.fbe8f32e05c391187dfcb2ae7d249641.png" class="ipsAttachLink ipsAttachLink_image"><img data-fileid="22842" src="/monthly_2015_05/fmf.thumb.png.f16dc8c1c642797da0349166884ebf31.png" class="ipsImage ipsImage_thumbnailed" alt="fmf.png"></a></p>

3. a Zipped file uploaded and attached to the post, the file path stored in core_attachements is monthly_2015_05/fmf_email.png_zip.d20345ef86d340a41e56fc114407106f

<p>Uploaded and Attached</p><p> </p><p> <a class="ipsAttachLink" href="https://invisioncommunity.com/applications/core/interface/file/attachment.php?id=22839">fmf_email.png.zip</a></p>

4. a Zipped file uploaded and not attached to the post, the file path stored in core_attachements is monthly_2015_05/fmf_email.png_zip.30421640ef6d1bbeb877762390412841

<p>Uploaded Not Attached</p>

<p><a class="ipsAttachLink" href="http://fmforums.com/applications/core/interface/file/attachment.php?id=22840">fmf_email.png.zip</a></p>

you will noticed that in version 4 there is no referential path like  https://invisioncommunity.comthe current url is hard coded if they fail to attach the file. Thus breaking if the base url changes.

how are the md5 value generated are they generated based on what values - id / filename / path or some arbitrary value?

 

 

[Ocean West]

just fyi these "abstract links" are not present on core_messaging - it's still using hard-coded urls.

 

 

[Ocean West]

Curious why is "ANY" path stored in the post content? 

When the person makes a post and submits it where ever in the post they designated an attachment / smiley etc. why not just place a MARKER of some sort there with the unique identifier, and type. 

then when displaying editing the data is translated / exploded out to the given URL / path as needed.

any storage changes would not ever have to rebuild the content fields. 

 

[Ocean West]

i am just looking at the fall out of upgrading from 3x - 4 there was some initial issues that wasn't discovered until well after i went live, preventing me from downgrading.

the upgrade process or the changeurl script or move process had totally butchered the file names in the upload folder - in fact it never completed moving files half were left in the root uploads the some were moved to the new /attachments/ directory that I setup. Most that were moved the file name no longer has any value that can easily be traced back to the record in the database or anything identifiable without consulting the database. 

I was hoping my (escalated) ticket would have been resolved by now - as still files are not 100%;  people have been telling me they can't download this file or that file
 

I have been finding them as they come in and comparing the old file paths and then either editing the post and re uploading the file, or fixing the file name via FTP and updating links in the database. (VERY TEDIOUS)

None of the update scripts modified the "alt" tags on any of the attachments. So the alt tags stored in the database has the old un-altered name along with the altered name

Sample content - the file name is 1244328669-Before.jpg and 1244328685-After.jpg

please see the attached; I 'Photoshopped' a vertical rule in the After.jpg file.</p><p><a href="/monthly_12_2010/_ost-25356-129144.3b6f53ebf9416130876da62dc6268ece"><img src="/monthly_12_2010/_ost-25356-129144442535_thumb.1ccd75bd9ccceaa3c5c22165f876752f" data-fileid="13027" alt="post-25356-129144442535_thumb.jpg"></a></p><p><a href="/monthly_12_2010/_ost-25356-129144.60415e667ee259bf6c85e369607afda1"><img src="/monthly_12_2010/_ost-25356-129144442551_thumb.7d60d38369f892f1a29cee58b803e90c" data-fileid="13028" alt="post-25356-129144442551_thumb.jpg"></a></p>

Also another somewhat serious issues that something i had not realized - that since 2010 when i upgraded to IPB only created NEW folders going forward and did nothing with historical posts or file location (but yet changed names and updated post content)

So i have over 20k attachments in one folder trying to find things in this directory thru ftp is not easy - possibly partly why the move failed? I also discovered < 12 legacy files that had an illegal character like ' or \ and had to use a terminal command to resolve it and then manually fixed the file paths in the database.

I managed to generate a folder structure on my desktop in the monthly_YYYY_MM format and based on the database I have was able to move the files in to the directory based on their creation date and also generated a unique id and then md5 that so that it matches the current file store pattern. Which i assume is only to allow for the the possibility for multiple identically named files to be uploaded in the same Year/Month.  

so from this:

monthly_12_2010/_ost-25356-129144.3b6f53ebf9416130876da62dc6268ece
monthly_12_2010/_ost-25356-129144442535_thumb.1ccd75bd9ccceaa3c5c22165f876752f

to this:

monthly_2009_06/Before.jpg.0eaaf5f6b7a22d41baa9bb5b794d8e0a.jpg
monthly_2009_06/Before.thumb.jpg.a1dbbdbf0c183ed323a87bdfb4a905d2.jpg