We have an ‘article’ schema and for each component created using this schema there are two dynamic component presentations used by various queries on our websites and we also generate a static ‘article’ page.

We have some applications to automate different content creation and publishing tasks such as a wordpress to Tridion content importer/publisher. Currently these applications publish articles by submitting two publishing jobs to the queue. The first contains the page and the second contains the component.

Prior to our Tridion 2011 upgrade, the publishing related services performed so poorly (relatively speaking) that submitting the page and component as separate publishing jobs worked ok for us. Our publishing systems were only capable of processing 1 or 2 items at a time and the page and components took about the same amount of time to render so usually they showed on the websites at the same time.

Since the Tridion 2011 upgrade, publishing performance has improved so much this approach is causing issues. Our publishing systems are processing many more items concurrently (12 I think) and the speed of component publishing has increased dramatically. Now the components for an article may publish 60+ seconds faster than the corresponding article page.

This results in articles showing up in the various query lists on our sites prior to their article page page being available on the site which causes our editors (rightly) to freak out.

So far we’ve tried a number of ways to prevent this. Our currently approach is to publish the page first and submit the article component as a scheduled publishing job for 60 seconds after the page is published. This however has still not completely resolved the issue and seems like a complete hack.

What I was wondering is, if we submit both the page and the component in the same publishing transaction like so:

string[] componentIds = new string[] { "page tcm", "article tcm" };
client.Publish(componentIds, pubData, pubTargetIds, PublishPriority.Low, null);

Will the resulting publishing task show up as one publishing job where both will make it through the publishing/deployment process at the same time? Or will these show up as two separate items in the queue?

I suspect the later as the page uses one storage type and the component presentations another although, with that said, publishing of binaries components in the same transaction doesn’t result in separate publishing tasks in the queue. If it did work this way, it would completely solve our issue and also provide a resolution to a related issue (what happens when the component publishes but the page fails or vice versa.)

Or (setting asside trying to figure out why page publishing is taking so long) are there alternative approaches to a problem such as this we should be looking into?

  • Did you even try this? You seem to have the code written already. Mar 8, 2013 at 18:34
  • @ChrisSummers point taken. We haven't tried it yet. I figured someone else probably had tried it before and could provide a quick 'it is/is not going to work' response. I shouldn't have assumed that given I couldn't find any addressing this when I searched for them. Mar 8, 2013 at 19:16
  • When you publish a page, any DCPs on it are also published per SDL Live Content. I believe it's part of the same transport package (you should be able to see them if you queue the page manually). Not sure on timing though-I'm not sure it's possible to still have the DCP "live" before the page. Mar 8, 2013 at 20:23
  • @AlvinReyes the DCPs in this case aren't actually on the page (only static CPs for the component are on it) but a good point about them being part of the same transport package. One of our devs is getting ready to test it now. Mar 8, 2013 at 20:29
  • Ah ok, then publishing the components would publish any of their DCPs (one per dynamic template) and re-publish any pages (only if the pages were published before). Publishing the page will render the static component presentations, but since they're not dynamic on the page, any related DCPS should not automatically publish. Mar 8, 2013 at 20:41

4 Answers 4


Another way of doing this would be to check if a link to the static article page is available on the front end. If you are already using the front end APIs to retrieve lists of articles from the Broker, you could test against the Linking API whether a link to the static page is available.

This will some some more overhead on the front end (but marginally if object caching is used), but it will also be a sure way to prevent having dead links on your site.

  • In the short term this is the approach we've decided to take although in our case we'll modify our stored proc's in the broker DB to not return items that don't have valid pages to link to. Mar 11, 2013 at 5:37

It sounds like you want to use a Custom Resolver to add the Components (DCPs) to the package when you publish the Page. Alternativley if you are willing to allowWriteOperationsInTemplates , you could call the publish action directly from your Page Template code for the DCPs.

  • Sounds like a good approach. If we do this do the custom resolvers know if the page is being published for the first time vs. a republish so we would be able to only adds the DCPs to the package in the first instance? Mar 8, 2013 at 19:19
  • you can certainly check the isPublished status of the page - so I imagine you must be able to do that with a resolver (and/or a template) Mar 8, 2013 at 20:54
  • The ResolvePurpose tells you if this is a Publish, Republish or Unpublish action in T2011
    – Nuno Linhares
    Mar 8, 2013 at 23:07
  • Dont forget you can just call RenderComponentPresentation in the Page Template code! See my answer... would be simpler than a resolver
    – Will Price
    Mar 11, 2013 at 10:38

If you 'know' which Component to publish from within the Page publish action then its as simple as calling RenderComponentPresentation from within a TBB in your PT/CT (and throwing away the returned output). For unpublish you would probably need the Event system.


You have mentioned that your current approach is to use scheduled publishing for the component. I think you should also consider separating the publication phases. So render everything in one publish action, and schedule everything to be deployed at some future moment when you expect all the rendering and transport will be complete. (I'm sure this isn't perfect either, but definitely worth looking into.)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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