after_channel_field_save is called too soon for Grid fields
Developer Preview
I’m trying to add the lang_id and status columns to the Grid tables to Publisher can do its thing and I tried to use the after_channel_field_save hook to do so, but the actual channel_grid_field_x table does not exist yet. The row is in the channel_fields table though. The table creation is getting called after the hook fires, so the Grid isn’t entirely saved yet. Is there anything I can do to call a function after that table is created? Right now I have a function called on every single CP page load to verify that the lang_id and status columns exist in each grid table, and if not it adds them. While this works its less than ideal and not very performant, though I could live with it if need be.
Maybe at the end of grid_model->create_field() an event hook can be triggered?
ee()->dbforge->add_field($db_columns);
ee()->dbforge->add_key('row_id', TRUE);
ee()->dbforge->add_key('entry_id');
ee()->dbforge->create_table($table_name);
// trigger hook event here?
return TRUE;
Hey Brian,
We really don’t want to add a hook that encourages modifying first-party tables. Are you able to create and use a kind of lookup table instead? Something that stores the language ID and status and correlates it with a field ID and row ID? Sorry it’s not as convenient, but we currently don’t see ourselves officially supporting this kind of thing. There’s nothing stopping you from continuing to check for these columns on every page load, of course, other than we just strongly prefer you finding another way to store this information.
Totally understand. TBH I had a hell of a time getting it to work as is… so going down the path to create a lookup table does not sound appealing, especially when I know it works this way.
Understandable, I’m sure you’re looking to get this out ASAP, too. And thanks for understanding!
I’m willing to take a look at the option. Another option would be to create clone tables, e.g. exp_publisher_grid_field_x and use those. I’ll keep these in mind for something down the road. Right now I’m more in the mindset of “if it ain’t broke…”
At minimum, I’d recommend making sure your column names are prefixed, lest they cause some fatal collision for the end user down the road with a native column addition, or one from another add-on that has the same idea.
Yeah, I have them prefixed with “publisher_” to avoid conflicts.