Fixed Uninstalling XFMG does not remove attachments

Affected version
2.2.3

Jake B.

Well-known member
If you uninstall XFMG the xf_attachment and xf_attachment_data seem to remain. If you then reinstall XFMG and start creating media items the full image will show up as whatever matched up to that ID before you installed XFMG, but the thumbnail will be the newly uploaded image.

Steps:

1. Install XFMG
2. Upload media items (10 in this example)
3. Uninstall XFMG
4. Install XFMG again
5. Upload more media items than last time. The first 10 full images will be the old images from before it was uninstalled, and the thumbnails will be generated off the new image
 

Chris D

XenForo developer
Staff member
This likely applies somewhat to XFRM too and potentially other add-ons who have replicated our approach.

It is mostly expected.

During uninstall, because it wouldn't really be appropriate to do potentially massive file system operations, we mark the content type's attachments as unassociated.

They're then cleaned up in the same way as other unassociated attachments - the next time the hourly cleanup cron runs. However, only attachments which were created over 24 hours ago.

In your exact reproduction case, because the attachments are new, it would take between 24-25 hours until the attachments are cleaned up.

In a more typical reproduction case, the attachments are less likely to be new, so it would take no more than an hour (the next time the cron runs) before they're cleaned up. It can be triggered sooner than up to one hour if you just run the cron manually.

In an even more typical reproduction case, in the vast majority of cases, this is unlikely to be an issue whatsoever because generally if someone is uninstalling the add-on, they're unlikely to be reinstalling straight after.

In your case when XFMG is being re-installed, the new media items are inserted as expected with new attachments but the relation will most likely pick the first matching record that matches, e.g. content_type = 'xfmg_media' and content_id = 1. It doesn't take into account what the value of the unassociated column is, so it ends up picking the first attachment it finds which is the one that is now unassociated and ignoring the second matching attachment which would be the newest.

This fixes itself automatically when the unassociated attachments are eventually deleted.

Perhaps it would be better to take into account the unassociated state and I'll at least look into that but all things considered this isn't generally an expected scenario.
 

Jake B.

Well-known member
I don't think anyone would consider this behavior expected. Rather than only setting unassociated to 1 could it not also set content_id to 0? That'd completely resolve this issue with no changes to the behavior of the XFMG add-on itself. It'd essentially put all of them in the same state they would be if someone uploaded an image to create a new gallery item, but never actually submitted it.
 

Chris D

XenForo developer
Staff member
The expected part is that the approach taken is for specific reasons and we intend for the records to stick around for a period of time after.

Yep content_id 0 may be a good solution too. But, for now, given you know the cause and the reasons behind it, it should be possible to workaround it.
 

XF Bug Bot

XenForo bug fixer bot
Staff member
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.7).

Change log:
When uninstalling content type data during an add-on uninstall set the attachment content_id to 0 as well as unassociated to avoid conflicts if reinstalling. The files will be cleaned up later.
There may be a delay before changes are rolled out to the XenForo Community.
 
Top