CiviCRM Community Forums (archive)

I was working through a fairly simple task. When a pledge is entered, calculate a custom field on that pledges based on the total & one other custom field. However, I found that doing this through a hook caused a minefield of gotchas:

First up I tried writing a postProcess hook. I got the hook working testing on editing the pledge but I found the same hook didn't work for when they created the pledge (I gave up on this ages ago so I can't remember the details but I think the data prevented was different.

So, I concluded that exposing using jquery to pre-fill the custom field would cover both fields & would look prettier than fixing it on save. But then they came back & said that front end data entry (via the contribution form) wasn't being saved. I realised that there could potentally also be data going in by code so I decided the only way to be sure was to focus on when the pledge is created.

So, I tried the pre hook - no use there - the pledge isn't created yet.

OK, the post hook. I didn't have all the data available that I needed so I did a pledge_get & a pledge_create via the api but the custom field I set was lost each time. It turned out that although the pledge object had been committed to the DB the corresponding custom field commit was still about to happen so any change to custom fields made at this point gets overwritten

So, I tried the custom hook. This finally worked. Yes, I had to do a pledge_get & pledge_create to get the data but there was no other point in the process where I felt I reliably had this data so that was the same as anywhere else. My feeling is that I am going to increasingly focus on using the post & custom hooks because I'm not confident that when I use a form hook I'll catch all the ways data could be coming in.  The gotch here is to avoid a loop - set a static variable.

Not sure there are any useful lessons from this except - however long you think it will take to customise Civi - tripple your estimate!

IMO, something useful would be to provide an access to the context, eg.when you are in a contact create hook, knowing if it's because an admin creates it normally, through a profile, if it's because that's an event registration, if it's because you create an org because the current employer of the individual registering for the event...

Beside avoiding Eileen hammering the db to retrieve data that are already around, can allow to add a lot of intelligence to the system and act differently based on the context...

X+

In general if i'm manipulating a column in the DB, i prefer to use the post hook on that object (which for custom groups is the custom hook), primarily because there are many ways that object can be updated and hence form hooks are more limited

In general the hook system is not the most efficient system, but does provide a cleaner and simpler way of modifying the flow / data

do agree about context. would be good to incorporate some of larry's ideas from butler / drupal 8. check:

http://drupal.org/project/butler

lobo

this is a fairly big change and we'd prefer to do it in 4.1 and earlier in the development cycle rather than later

The pre hook still needs to be called from the BAO. The post hook can be called from the DAO, and we might want to do it selectively for the 20-30 tables that need it (rather than all 134 tables, since its a loop thru the module list, checking for a function existence in D6)

lobo