CiviCRM Community Forums (archive)

CiviCRM offers the _pre and _post database hooks to alter data between the database, but they are not called for custom fields.

The _custom database hook is called after a custom field is written/deleted on the database.

Why is there a different hook for custom fields, rather than just implementing the _pre and _post hooks in place of _custom? (or as well as)

Here's the difficulty / inconsistency:

#1 If I use the JS inline editor for a contact and update a group of custom fields: _pre and _post are not called, but _custom is called.

#2 If I put custom fields on a profile, and update it: _pre IS called (for the 'Profile') entity, and contains the value of the custom field. Then _custom is also called. Then _post.

#3 API calls presumably (I haven't tested this) always trigger _pre and _post, and therefore also _custom, because they always target a Civi entity.

This effectively means that you can't rely on _post to pick up all database updates; and you can't really use _post and _custom because they might both be called.

Proposed resolution:

Wouldn't it make more sense to deprecate _custom, and just use _pre and _post? Custom fields are always attached to an entity, so we should be able to use the existing functions. The only trouble is making sure _pre and _post aren't called twice, like in example #2 above.

--

This is all very early days in the thought process, but I'd appreciate all your feedback and thoughts on this =]

I think yes those inline-edit forms for custom data really ought to be calling _pre and _post hooks.

I'm unsure about deprecating the _custom hook, not sure exactly the history behind it and who might be using it. Would be good to get some more feedback on that.

Agree with the principle: should be pre and post. We do have some extensions that use the _custom hook as it is what was available.

Sounds like we have general agreement.
@rocxa I think the original suggestion offers a non-breaking fix for both short and long term. It was to ensure _pre and _post are always called for custom data, but don't remove hook_civicrm_custom. We can deprecated it and give people time to migrate their code before we remove it down the road.

Or @rocxa I'm sure if you wanted to create the PR yourself John wouldn't mind