_custom versus _pre and _post

[John.K]

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 =]

[John.K]

Cross-linking to a recent issue on the topic in JIRA: https://issues.civicrm.org/jira/browse/CRM-15261

[Coleman Watts]

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.

[Coleman Watts]

Related: https://issues.civicrm.org/jira/browse/CRM-16583

My 2 cents: getting rid of hook_civicrm_custom would be better for consistency and maintainability than introducing a new custom_pre hook.

[Erik Hommel]

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.

[rocxa]

My vote would also be for removing hook_civicrm_custom and just using _pre and _post consistently.  It will probably break many extensions and custom modifications people have done though which is why I thought just adding custom_pre was simpler as a short term (non breaking) fix.

On a side note, the hook_civicrm_custom has a params array and not an objectRef which have differently layouts of the data despite holding the same sort of information.

[Coleman Watts]

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.

[Coleman Watts]

John K do you want to create a PR for this?

[Coleman Watts]

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

[John.K]

Great, I've updated the issue here with the agreed proposed resolution: https://issues.civicrm.org/jira/browse/CRM-15261