Not a bug Copy posts functionality does not filter fields as present in the datawriter

Rigel Kentaurus

Rigel Kentaurus

Well-known member
The current _copyPost method (line ~1539 Model/Post.php) instead of using the DataWriter directly does a $db->_insert() call.

While I assume this is in purpose, add-ons can unintentionally break the functionality, which happened to me. I have an overloaded function on an Add-On that looks like this:

Code: 
public function preparePostJoinOptions(array $fetchOptions)
{
   $joinOptions = parent::preparePostJoinOptions($fetchOptions);
   $joinOptions['joinTables'] .= "
      LEFT JOIN xfa_blog ON xfa_blog.user_id = post.user_id
      ";

   return $joinOptions;
}

The short story here is that ...

  1. When the posts are loaded, it uses the prepare() methods in the model, and adds additional columns
  2. When the new post is saved back, it just tries to write everything in the array, which includes several columns that will not exist in the xf_post table since they were fetched with a join

While this is not a bug in the out of the box package, and it is caused by an Add-On, it does mean that every Add-On that extends the preparePostJoinOptions now or in the future will end up breaking the copy and move functionality unless the mod author explicitly compensates for that.
 
I don't think the issue is extending the join options function -- it's adding the data unconditionally whenever it's called. (I assume you've simplified the function, as your example wouldn't actually add any data to what's grabbed.) I can understand why you did it, but it's potentially breaking various assumptions about the data, though it likely won't come up in many cases.

I'm not sure if you're saying you run the preparePost() function or just the function you've mentioned above -- if you're running preparePost() then that's very much unexpected.

The thing is, we need this function to be "zero config" in the average case. We don't use the DW here intentionally, for speed and notification reasons, combined with the need for direct access to handle cases regarding add-ons that modify the post table.

Given this and that the _copyPost() function was actually written in such a way to be overridden for an event like this, I think that's what I'd have to recommend for your usage (you can unset the columns or change the values before the main function runs).

That said, if it's at all possible, I would look at an approach that doesn't add extra data unconditionally -- perhaps only add your blog information if the user data is being fetched as well.
 
Top Bottom