grid_delete $this->content_id() not set
Developer Preview
When deleting a grid field with my field type in it, the function $this->content_id() in ft.fieldtype.php returns a 0 rather than the entry ID of the entry. Without the entry ID, I cannot get enough context to safely delete rows from my table for that grid field since all I get is the grid_row_id in the array. Can the field type method content_id() return the entry ID?
A Grid field is typically associated with more than one entry. To clarify, are you talking about when a Grid field is deleted or an entry is deleted?
Well dang. grid_delete is called when a grid row is deleted in an existing channel entry but the entry is not deleted — BUT ALSO when the channel entry is deleted. That’s unfortunate. I need some way of getting the content ID along with the row ID.
Ah ok I think I see where we’re explicitly setting that to zero. Kind of nervous to fix that in a 3.x release, maybe someone is relying on it to be zero to tell if we’re in a deleting state or something weird (we’ve seen it all). You should have the information you need to triangulate though. You should be able to grab the grid_field_id from the settings array, then query the channel_grid_field_x table for the row IDs you were passed to grid_delete to get the associated entry ID. It’s not great, but should get the job done and be a fairly inexpensive operation. Is that doable? In the mean time, I’ll see if I can get this fixed in our 4.0 branch.
Yep, that makes sense. I’ve actually already worked around it.
I actually think I see why we may have set it to zero in the first place. If you delete multiple entries, it looks like we’ll send the column type all the row IDs across the various entries, so all the row IDs you get may not necessarily be from the same entry.
I tested deleting multiple entries, and as far as I could tell, the method was run once per entry.
Ah yes I get that as well, behavior likely changed once we tied in fieldtypes to models. Ok will look into fixing for 4.0, thanks!