I want to get all published pages to a specific publication target within a specific publication.

In Tridion 2013 SP1 there is this static method to do so: Tridion.ContentManager.Publishing.PublishEngine.GetPublishedItems()

However, GetPublishedItems() seems to always return page and component items. I could not find a way to filter on ItemType.Page.

Below is my attempt to filter on ItemType.Page, but the returned result contains both page and component items.

var filter = new Filter();
filter.Conditions["ItemType"] = ItemType.Page;

var publishedItemsFilter = new PublishedItemsFilter(filter, Engine.GetSession())
    ForPublication = Publication,
    PublicationTarget = ContextPublicationTarget,
    IncludeTemplates = false

IEnumerable<IdentifiableObject> publishedItems = PublishEngine.GetPublishedItems(publishedItemsFilter);

The resulting publishedItems contains both pages and components. From here I do the filtering to get the published pages.

As you can see, this is not very efficient. In our case the code above takes +/-35 seconds to execute. We have a lot more published components than pages.

I believe I'm doing something incorrectly or missing something here.

Can someone please point out a correct or a more efficient way to get published pages?

2 Answers 2


The PublishedItemsFilter(Filter, Session) is created because of the deprecated loosly typed filters. It is basically there for when you are upgrading code and want to create a strongly typed filter based on your original Filter object.

So you are encouraged to use the PublishTransactionsFilter(Session) constructor for creating your filter, and there you will see that indeed there is no option to filter on ItemType (hence your option was ignored).

That all being said, we didn't really get you any further than you already are (just explained why it didn't work). But I'm afraid that is just the situation, you could investigate if the PublishEngine.GetListPublishedItems(PublishedItemsFilter) returns the results faster for you, but you will in any case have to filter out the Pages yourself (which can easily be done with an XSLT when using the GetList method). When testing either method on my system, I get very similair performance results out of each, if using them both after eachother, the second call is always faster (which is due to database caching), regardless of which method I use.

So the 35 seconds it takes for you, might not just be related to the method used (and the lack of filtering), I have a feeling you might also encounter a bit of a database issue. So in any case I would consider checking your database maintenance, and make sure its indexes and statistics are up to date.

  • Thx for the explanation. GetListPublishedItems() and GetPublishedItems() behave the same in this respect. VbScript gets the same result much faster on the same Tridion system. I think it's in the way how .NET API implements GetItems/GetListItems.
    – hoang
    Commented Sep 26, 2014 at 15:29

The last line is the culprit:

IEnumerable publishedItems = PublishEngine.GetPublishedItems(publishedItemsFilter);

It gets the actual IdentifiableObject set. This internally most likely makes all kinds of DB calls to populate the objects. A more efficient way is to use the GetListXml method and work with the XmlElements via linq, and only pull the actual IdentifiableObject iff you need it via engine.GetObject (by ID found in the XmlElement).

As for why you're getting components with pages doesn't make sense since you're filtering on ItemType.Page. Can you not apply that condition directly to the PublishedItemsFilter? Note, the non-typed Filter class is deprecated as of Tridion 2011 in favour of typed filter classes.

  • 1
    PublishedItemsFilter has no filtering option for ItemType. XML list approach is possible (PublishEngine.GetListPublishedItems()), but not faster. In fact it's slower. (This is confirmed by people at SDL).
    – hoang
    Commented Sep 26, 2014 at 13:02
  • I've never seen a list be slower than loading the individual objects - when loading the objects it actually starts by getting a list then iterating through it, so I cant really understand why it would be slower...
    – Nuno Linhares
    Commented Sep 26, 2014 at 14:18
  • I don't see any real huge performance differences between either one of those methods, the way the TOM.NET API is optimized, getting items (objects) or an XML list should not really matter as the objects are only instantiated when actualy used. Commented Sep 26, 2014 at 14:22
  • 1
    GetListItems() slower than GetItems() yatb.mitza.net/2013/08/…. (Read the comment by Rick).
    – hoang
    Commented Sep 26, 2014 at 15:11
  • Awesome @hoang. I just learnt something new! +1 for the question. Commented Sep 26, 2014 at 17:32

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.