Is there a way to access a page's package from a component design for a component on the page? I have a page template with some TBBs to push several page-related fields onto the package. Later in the page template, I render component presentations. In the corresponding component designs, I would like to access some of the fields pushed onto the page template's package.

2 Answers 2


A way to pass variables across template scopes of the same rendering session is via Context Variables hash map. See Tridion docs for usage.

A mix of concerns is a caveat to consider here. So this kind of approach, my opinion, is tough on maintenance and not ideal.

Note, using this approach you will not be able to debug your CTs in Template Builder because there is no page available. So your CT will just crash when it will try to use those variables.

Perhaps to better separate concerns and make it look a bit more explicit on what's going on, have your TBB on the CT pulling what it needs from the Page, or use default values or throw exception if not-found in the TemplateBuilder context. This way when debugging the CT you'll explicitly see what the TBB that pulls the Page data is doing, as opposed to guessing why a DWT is crashing.

A couple of other Q&As have similar suggestions:

Accessing page object in C# TBB used in the component template




Because the page and the component presentations are separate render operations they each have their own package; as such variables pushed into the package in the page template are not visible or accessible to the component template (as it has it's own package; the same applies to sibling component templates rendered on the same page).

What you are looking for is called Context Variables and they are described in Nickoli's last link.

If you are just looking for accessing the Page item from the component template you can get it via

Page page = engine.PublishingContext.RenderContext.ContextItem as Page;

assuming it's a statically embedded component presentation and not a purely dynamic one of course (in which case ContextItem is always null).

  • Yes, in fact accessing the page was sufficient in this case. I used TemplateBase.GetPage(). I wonder if the ContextItem is truly always null for a dynamic component, or if I should check more expilicitly for that case... Commented Jan 23, 2015 at 14:20
  • 2
    ContextItem is non-null for statically embedded (dynamic) component presentations (I remember that if you call engine.RenderComponentPresentation() from a component template it will not have a ContextItem but perhaps this is no longer the case in 2013?). Of course if you run your CT in template builder it is not executed from a page template so ContextItem will be null making debugging a bit of a pain. In any case it is prudent to safeguard your code against an empty ContextItem... Commented Jan 23, 2015 at 14:45

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.