Fixed xf_post.attach_count incorrect value

[xfrocks]

This is a low priority bug but it should be fixed anyway. It's kinda funny:

File: ./library/XenForo/DataWriter/DiscussionMessage.php
Line: 574 (XenForo RC3)

	protected function _associateAttachments($attachmentHash)
	{
		$rows = $this->_db->update('xf_attachment', array(
			'content_type' => $this->getContentType(),
			'content_id' => $this->getDiscussionMessageId(),
			'temp_hash' => '',
			'unassociated' => 0
		), 'temp_hash = ' . $this->_db->quote($attachmentHash));
		if ($rows)
		{
			// TODO: ideally, this can be consolidated with other post-save message updates (see updateIpData)
			$this->set('attach_count', $this->get('attach_count') + $rows, '', array('setAfterPreSave' => true));

			$this->_db->update($this->getDiscussionMessageTableName(), array(
				'attach_count' => $this->get('attach_count') + $rows
			), $this->getDiscussionMessageKeyName() . ' = ' .  $this->_db->quote($this->getDiscussionMessageId()));
		}
	}

The database update will store incorrect value for attach_count because after this line

$this->set('attach_count', $this->get('attach_count') + $rows, '', array('setAfterPreSave' => true));

The internal value of attach_count is already increased by the number of rows (new attachments). But in the database update query, that number of rows is added AGAIN. That means if a post has 1 attachment, the attach_count is 2. If the post has 5 attachments, attach_count will be 10.

 

[Mike]

Good catch, fixed now. Unfortunately, we don't have a great process to update the incorrect rows (I suppose we could divide by 2 across the board, though this was working at some point I imagine ). The only side effect should be a wasted query if someone uploads an attachment and then deletes it.