In this article:
This new publish workflow ensures that your code doesn't get published until it's ready. It allows you to see what code has been published to each environment and easily compare code between drafts and environments.
Use drafts to maintain different versions of the code without affecting your published profile. Drafts are only published when you specify an environment using the Approve for Publish workflow.
Here's how it works:
Once a draft is published, the code is added to one of the utag files (depending on the scope). It's important to note that the code runs just as it appears in the code editor, but is wrapped in the following anonymous function:
The two parameters passed to the function are:
a - the event type ("view" or "link" or a custom value)
b - a reference to
utag_data allowing you to set UDO values as
Be sure to scope all of your variable references accordingly to avoid overwriting global variables.
Compare a draft or a publish environment to any other draft or publish environment. The comparison window displays the versions of the code side by side with highlights for each line that differs. For example, compare Prod vs QA, Draft 1 vs Draft 2, or Draft 1 vs Prod.
Before you begin, familiarize yourself with how extensions work.
Once the extension is added, create a draft as described below.
The following functions are available when working with a draft:
Files added through GitHub are read only and cannot be edited. To edit these files, edit directly in GitHub or copy the file to Draft mode and edit the draft copy.
Use the following steps to copy the file to draft mode, edit, and save prior to publishing:
If you choose to keep the same name, names remain the same as the file name. For example, if the GitHub filename is
Tealium.js, the first copy becomes
Tealium.js (if a draft with that name does not already exist). Subsequent copies are named
Tealium.js-2, and so on.
Publishing a draft is a two-step process. First, in the extension the draft must be added to the publish queue for the desired publish environment. Second, the profile must be published to the corresponding target.
Remember, by default, drafts are not included in a publish unless they have been explicitly queued for publish.
To publish a draft:
The following sections describe how to synchronize GitHub files in TiQ.
When working with GitHub files in TiQ, the filename you are working with always displays at the top of the interface. To view the full file path, simply hover over the filename.
Use the following steps to add a file from GitHub to TiQ:
Use the following steps to manually sync files, including those approved for publish:
Files queued for publish cannot be synced and display a lock icon to the right of the filename. If you attempt to sync a file that is queued to publish, an orange warning icon displays to indicate that the you are unable to connect to sync to new version.
Use the following tips to make the best use of this extension and avoid common mistakes:
utag_dataobject, such as
page_name, use the
bobject like this:
b['page_name']. Learn more about the b object.
Consider your environment and the following pros and cons prior to using this extension:
If you have a condition defined, the Pre Loader option is no longer available. In Pre Loader scope, the data layer is not yet populated so there is no data object with which to evaluate the conditional logic. Likewise, the Add Condition option is disabled when the scope is set to Pre Loader.
Both Pre Loader and Run Once Before Load Rules cause the extension to run once before the data layer is populated and before load rules are evaluated. The difference is that conditions are not supported in the Pre Loader scope.