Back From Bootcamp

I’ve just returned from a two day bootcamp hosted by Nuno regarding the new upcoming tool formerly known as SiteEdit. That’s right, I’m talking about SDL Tridion UI 2012 (which will probably still be referenced as “SiteEdit 2012″ for years to come by all of us who have used it up until this point), and if you haven’t heard any news at all about it, you can check out Nuno’s post on it here. Nuno did an excellent job walking us through the new features and dynamics of this completely revamped tool, and I would like to share some of these new features with you!

Not a proxy anymore!
The days of SiteEdit running as a proxy site is no more. Tridion UI runs directly from your Staging site!

Live editing… from the CME?
Clicking the Tridion button (previously the button labeled “SiteEdit”) loads the Staging page into an iframe… within the CME! Remember though, the Tridion UI Dashboard is not equal to the Tridion CMS Dashbard, and has options and settings directly related to SiteEdit only. Also, because of how Tridion UI works, this means that you now have the option to build GUI extensions for Tridion UI!

Built in options and settings
No more will we have to find workarounds to configuring our SiteEdit settings. Where once we’d have to add every setting into a TBB or create Page Types in a special location within Tridion, we now have built in options! You can enable/disable live editing directly from the Publication Target. You can enable/disable fields for inline editing directly from the Schema. You can change all the normal settings (like borders, color, etc) right from a Settings section within the Tridion UI dashboard. You can mark items as being Page Types right from the Page, and can set the icons displayed for templates in Tridion UI right from the Template itself. You can even configure Content Types right from the Publication properties!

You just mentioned… Content Types?
That’s right! While the concept of Page Types existed, it is now possible to define Content Types as well! Think of Content Types as the mixture of a Component and a Component Template, that you can set rules to.

Dynamic Editing
The new Tridion UI 2012 allows you to use a oData webservice and a session preview. What does this mean for you content authors? This means no more waiting for the publishing queue to see your changes! And for those of you who don’t wish to use this new feature, you absolutely don’t have to! Tridion UI will behave similar to the way it did before (via publishing).

As the title suggests… Regions!!!! Not to be confused with a Template Repeat area of your DWT. A Region in Tridion UI is an area that you can just drag and drop content to. For example, if you have a right column, you can define a Region in that area and give it rules that only Right Column Templates can go there, as well as the minimum number of items and maximum number.

Of context menus…
You can even enable/disable the Tridion UI context menu. Very useful when you need to do a Right Click -> Inspect Element!

And so much more…
Tridion has done an awesome job with revamping SiteEdit. Two days was definitely not enough time to get to play with it, and I personally can’t wait for its release to start playing with it again (and perhaps even blogging a tutorial on creating an eXtension for it!).

Tridion PublishEngine – Of Transactions and Publish Information

Today I thought I would give some examples of querying publish transactions (publishing queue) as well as getting publish information from specific items, like seeing which Publication Targets a page has been published to and when, or just seeing if an item has been published in general. This post is inspired by a recent question asked in the forums, but I have noticed it come up from time to time. Luckily this task is easy using the TOM.NET API and the static PublishEngine class.


One task you might need to attempt in your Tridion development day to day activities is to check to see if a given item has been published, or published to a particular Publication Target.  PublishEngine contains the following overloaded methods.

bool IsPublished(IdentifiableObject item)
bool IsPublished(IdentifiableObject item, PublicationTarget publicationTarget)
bool IsPublished(IdentifiableObject item, PublicationTarget publicationTarget, bool isPublishedInContext)

The first IsPublished method is useful if you just want to see if an item is published, regardless of which Publication Target it has been published to.

if (PublishEngine.IsPublished(page))
    // This page has been published. Do cool stuff here.

The second IsPublished method will return true only if the item has been published to the Publication Target passed in the 2nd argument. If the 2nd argument is null, then it’ll act just like the first method and return true if the item has been published to any Publication Target.

if (PublishEngine.IsPublished(page, pubTarget))
    // This page has been published to a specific publication target. Do cool stuff here.

The third method allows for even finer control. I haven’t personally played with this one as of yet, but the documentation for the isPublishedInContext argument states “Indicates if state should be returned regardless of the context Publication. true only check if item is published in the context Publication; otherwise, false.” I’m assuming this means that, if this argument is set to true, the method will only pass if the item is published to a particular Publication Target, and only if the item is published in it’s own context Publication.


What if you need to get more information about an item? Like, what if you not only wanted to see what Publication Targets it was published to, but at what time too? That’s where the following method comes in hand.

foreach (PublishInfo info in PublishEngine.GetPublishInfo(page))
    Console.WriteLine("Published To: " + info.PublicationTarget.Title);
    Console.WriteLine("Published At: " + info.PublishedAt); // The time the page was published
    Console.WriteLine("Published By: " + info.PublishedBy.Title); // The user who published
    Console.WriteLine("Rendered With: " + info.RenderedWith.Title); // The title of the template used

The above will loop through each Publication Target that the item has been published to and give you some useful information about the publishing.


And what if you actually need to check the publishing queue to see if an item has recently been published in the past hour? The PublishEngine allows you to also query the publish transactions.

XmlElement GetListPublishTransactions(PublishTransactionsFilter filter)
IEnumerable<PublishTransaction> GetPublishTransactions(PublishTransactionsFilter filter)

Note that the above methods will throw an AccessDeniedException if the user is not a System Administrator or have PublishManagement rights in any publication. That means if your code relies on always needing to be able to check the transactions, regardless of rights, you’ll need to impersonate.

Session session = new Session("DOMAIN\username"); // Impersonate System Admin or at minimum user with PublishManagement rights.
PublishTransactionsFilter filter = new PublishTransactionsFilter(session);
filter.StartDate = DateTime.Now.AddHours(-1); // Add some criteria for when the publishing was started.
filter.PublishTransactionState = PublishTransactionState.Success;

IEnumerable<PublishTransaction> transactions = PublishEngine.GetPublishTransactions(filter);

foreach (PublishTransaction transaction in transactions)
    // Check cool stuff with the transaction, like the transaction.Items property.

The above will loop through all the successful transactions that has happened in the past hour. Notice the PublishTransactionState property… it allows you to only filter based on one state. But what if you need to grab anything that’s not Success or Failed perhaps, or any other combination of states? You’ll have to grab the items and filter programatically.

PublishTransactionsFilter filter = new PublishTransactionsFilter(session);
filter.StateDate = DateTime.Now.AddHours(-1);

IEnumerable<PublishTransaction> transactions = PublishEngine.GetPublishTransactions(filter)
    .Where(t => t.State != PublishTransactionState.Success && t.State != PublishTransactionState.Failed);

foreach (PublishTransaction transaction in transactions)
    // Do cool stuff with transactions that are not Success or Failed

And with that I leave. Happy developing everyone!