5

In addition to this old question: SetPublishedTo with CoreService

I have another question for the new Tridion 2011 EventSystem

I'm updating our EventSystem from the old TOM API to CoreServices... which's impact on re-work I greatly underestimated :))

With CoreService it is no longer possible to fake-publish a page, i.e. Page.SetPublishedTo();

This is something we used so content managers could:

  1. create component (ES automatically creates page, publishes to staging website, and set IsPublishedTo(live) property)
  2. check on staging website
  3. publish component to live website - component is publishable to live because we set Page.SetPublishedTo()

With CoreServices that "tweak/hack" is no longer available, meaning that our content managers won't be able to publish their components to live anymore. In stead they have to find the page that has the component on it and publish that.

Is there a viable work-around to save our servicedesk from countless of calls about 'components not publishing to live!' ?

Something like:

OnComponentPublishPre

  • get pages containing this component
  • if page is not yet published to target, then publish page to that target in stead of component

Or is this a wrong thought?

Or is it easier and still future proof to just use the older TOM.Net API for this?

Tnx for helping me out, Robin

Improve this question
4
  • I don't understand why you need step 3 to publish to live. Do they publish a whole Structure Group, and therefore the 'already published' flag helps? Also, there's an advanced option on the pub dialogbox to publish first-timers too
    – robrtc
    May 22, 2014 at 10:07
  • I also don't understand the need to fake the publish. Surely your event system can just leave it as-is in step 1 and then actually publish to live in step 3?
    – Peter Kjaer
    May 22, 2014 at 10:10
  • Also, you should probably use TOM.NET in the Event System - not the Core Service.
    – Peter Kjaer
    May 22, 2014 at 10:13
  • @PeterKjaer sorry, confused Core Service with TOM.NET API. I'm using the latter, to replace the deprecated TOM API. The fake publish was used as stated below by Bart Koopman, for editor's comfort.
    – ZonderZout
    May 22, 2014 at 11:34

1 Answer 1

Reset to default
3

In the 2011 and up event handlers you should use the TOM.NET API, no need to use the Core Service in there (it is possible, but is a bit of an overhead, the Core Service is meant for external applications).

But that won't help much with your question, since the SetPublishedTo() method is removed from the public API, as it was deemed not necessary anymore.

What I see is that you used the SetPublishedTo() method to fake the page was already published, so your Editors didn't have to Publish the Page first and can always publish a Page through its Components (even though it hadn't been published before).

To accomplish this behavior, you can create a Custom resolver, that will find all Pages the Component is used on, and then add those Pages to the resolved items, so it will be published. This way you are not faking a Page Publish action, but just handling the additional resolve options you want to implement.

See Nuno's blog post for more details on Custom Resolvers, or my Child Publications Only Resolver sample code (that removes items, but in a similar fashion you can add items).

Improve this answer
2
  • Sorry, I confused the new TOM.Net API with Core Services there for a bit. So I'm using TOM.Net API, as you suggested, in stead of the old TOM API.
    – ZonderZout
    May 22, 2014 at 11:29
  • And that's exactly what we used SetPublishedTo() for. Thanks for helping out! I'll try to figure out how to use Custom Resolvers for the rest of the day then. :)
    – ZonderZout
    May 22, 2014 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.