Fixed Legit attachments sometimes marked as "unassociated" and disappear after 24 hours

I also got 2 cases with unassociated attachments again. I uploaded the fix early in the morning and since then didn't check for it until now.

1614381076031.png
 
I just applied the fix. Logged out, closed my browser. Relaunched browser, logged in....

I am able to reproduce it 3 times in a row by doing this.

quote a post
click insert quotes
click remove (don't insert it)
upload image
insert an image as full size
click post button

I get the image link that goes to the
Oops! We ran into some problems.
You do not have permission to view this page or perform this action."
Click to expand...

UPDATE: I did the same thing on another PC and I could not reproduce it again. :unsure:
 
Last edited:
@PASS I'ld recommend rebuilding XF master data (this can be done via CLI), or installing/updating an add-on. This will force the javascript version stamp to be updated which will ensure browser caching is bypassed.
 
Idhae said:
Temp hash must be specified if no content is specified.
src/XF/Entity/Attachment.php:270

​

Stack trace​

#0 src/XF/Mvc/Entity/Entity.php(1355): XF\Entity\Attachment->_preSave()
#1 src/XF/Mvc/Entity/Entity.php(1208): XF\Mvc\Entity\Entity->preSave()
#2 src/XF/Service/Attachment/Preparer.php(267): XF\Mvc\Entity\Entity->save()
#3 src/XF/Service/Attachment/Preparer.php(29): XF\Service\Attachment\Preparer->insertTemporaryAttachment(Object(XFMG\XF\Attachment\Post), Object(XFMG\XF\Entity\AttachmentData), '[{"id":"1516294...', Object(XF\FileWrapper))
#4 src/XF/Attachment/Manipulator.php(170): XF\Service\Attachment\Preparer->insertAttachment(Object(XFMG\XF\Attachment\Post), Object(XF\FileWrapper), Object(XFMG\XF\Entity\User), '[{"id":"1516294...')
#5 src/XF/Pub/Controller/Attachment.php(89): XF\Attachment\Manipulator->insertAttachmentFromUpload(Object(XF\Http\Upload), NULL)
#6 src/XF/Mvc/Dispatcher.php(350): XF\Pub\Controller\Attachment->actionUpload(Object(XF\Mvc\ParameterBag))
#7 src/XF/Mvc/Dispatcher.php(257): XF\Mvc\Dispatcher->dispatchClass('XF:Attachment', 'Upload', Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\Attachment), NULL)
#8 src/XF/Mvc/Dispatcher.php(113): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\Attachment), NULL)
#9 src/XF/Mvc/Dispatcher.php(55): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#10 src/XF/App.php(2326): XF\Mvc\Dispatcher->run()
#11 src/XF.php(488): XF\App->run()
#12 index.php(20): XF::runApp('XF\\Pub\\App')
#13 {main}
Click to expand...
Got the same error just today...
 
On which forum would that be? You appear to be running XF 2.1.7. This version is not affected by the bug reported here.
 
You'll perhaps have to get the admin of that site to submit a ticket so we can investigate further.

Currently there's no expectation that the fix doesn't work so either the fix hasn't been applied, hasn't been applied correctly, or there's some amount of caching still involved so the old file is being served.

Or it's an entirely separate issue.

Enough people have now confirmed that the fix resolves the issue so we likely need to start from square one with any further reports of it.
 
The site in question has the correct js file being served (I was the one who put the fixed file in place, and also had Cloudflare purge the edge cache on that specific file)

1614618381679.webp

I don't know if any further Cloudflare cache purge has been done though since the master data rebuild.
 
Last edited:
Thanks all.

There is one factor that may make the issue appear to stick, even after the file has been fixed.

If you have automatic draft saving enabled, it is theoretically possible for a garbage value to have been saved in the draft's attachment hash field before the fix was in place and then restored later. Posts created from these drafts that include attachments may well still present the issue.

However, due to the nature of drafts, this issue should resolve itself after the affected drafts have expired which is usually within 24 hours. Also, after the successful posting of a draft, that draft (and any garbage values stored within) are then deleted so anyone affected may still see the issue exactly one more time (per draft) and then after that it should be fixed permanently.

If you have your drafts retained for a longer time (specified in options) you may wish to reduce this value temporarily so that any outstanding drafts get cleaned up quicker but on the whole it seems like most users are no longer seeing the issue.
 
Not sure if that is the case. I got yesterday again 1 case of this and my drafts are set for 24 hours and since I uploaded the file days ago, It should have been fixed by now.

Just to be sure I will rebuild master data now and then keep observing my attachments. Due to not having a big board it may take a while until one of the users encounter this problem in my case.
 
Probably little point in "observing" the attachments, if you mean observing them from the Admin CP. You almost certainly will see "unassociated" attachments with some frequency. They are simply an indicator that someone has started to upload an attachment but haven't yet submitted the content. This is normal.

We're only concerned with users reporting that they have submitted a post and the attachment wasn't visible after doing so.

Besides that, despite the 24 hour draft expiry it can still be an issue. Each time the draft is edited, the expiry date changes. So if someone had the issue several days ago, came back to it the next day, and the next day and so on they could still face the issue today.

But, yes, rebuilding master data is an important first step.
 
Top Bottom