Hi,
In the old SG config we used these pre/post publish hooks in tk-multi-publish:
primary_pre_publish.py
scan_scene_tk-maya.py
secondary_pre_publish_tk-maya.py
post_publish.py
We used them to run processes such as QC tools to check for errors before the file is published, or to export JSON files before and after publishing.
However, DefCon2 does not have any of pre/post publish hooks. How can we run pre/post processes in DefCon2?
Thanks for you answer in advance,
No idea what you mean by defcon2?
But tk-multi-publish2 has plugin hooks that attach themselves to items that have been collected by a “scan scene” hook.
Each of those plugins can have a accept and validation stage in which you can add QC logic.
It also has a post phase hook that can run at the end. Here is the app documentation on the hooks.
Hi Shervin –
A little more detail here: there isn’t a one-to-one relationship between old and new publish hooks, but here’s some background for how you could port over the business logic from your old hooks:
scan_scene
post_phase hook has methods that run after each of the above phases has run for all publish items.This diagram might be helpful to see how the pieces fit together.
And @Ricardo, DEFCON2 is just our shorthand for tk-config-default2 
I just wanted to add here, that we too miss the pre-publish logic in the publish2. It is rather handy if you need to generate/export multiple things prior to publishing.
Imagine a Maya Animation publish. We have 3 hooks: A playblast, a camera, the maya file.
With the old publish the prePublish hooks would first export the playblast, then camera and only when these 2 prePublishes were successful the 3 actual publishes would run. In case something broke (or the animator interrupted the playblast because he spotted something) nothing would be published.
With the publish2 there is the validate function, but that would also mean that the exports are triggered when the somebody clicks the validate button. And then again when he clicks publish.
Hi @Nico
I think you should be able to do what your after with the new publisher as well, but there is a different way of approaching this.
You should have three plugins set up in the order of playblast, camera export and then scene file publish. And you can store the results of one plugin on the item during the publish phase and then check for that in the next plugin before proceeding and bail if its not there.
I suppose ideally each plugin that depends on a previous plugin’s result would check that the plugin is on the item and is active before checking if the result was stored to the item. As you wouldn’t want to fail the scene publish if the playblast was deliberately left out.
As you can store values on the item and inspect the item’s plugins you should be able to maybe sort something out that is dynamic.
Ok, yes that would work if there is a linear dependency in the publishes.
Still if there are issues with the second export I’m left with a playblast publish that has no corresponding camera/maya publish. It would also break our numbering. We try to keep the published version numbers in sync.
I’d really like to do all of the heavy lifting (baking, exporting, conversions, etc.) before starting the actual shotgun/library interaction. The actual publish function should only contain a copy/move and a registerPublish.
I think I’ll either (mis)use the validate function for this and hide the button in the ui, or add another function between validate and publish into the publish class. On a first glance it doesn’t look too hard to do.
I would recommend using the post phase hook in that case then. During the publish I would collect all the data that is needed to publish in a dict and then store it to the item. Then the post_finalize() method on the post_phase hook can loop over the items and publish the data stored on them.
There is a post_validation() method as well, but validation shouldn’t really be used to modify or create data.