i want to have a report that shows which pages on each publication have different components than the US master pages? For example: US page has component ID’s 5,6,7,8,9 but the Spanish page has component ID’s 1,2,3,4,5 so four of them don’t match the US version. What i was thinking is get the parent and child pages (type 64):

parentItems = Client.GetListXml(txtParentTCMURI.ToString(), new OrganizationalItemItemsFilterData() { Recursive = true });

childItems = Client.GetListXml(txtChildTCMURI.ToString(), new OrganizationalItemItemsFilterData() { Recursive = true });

add CP's Name, TCM URI (and other info) as sub nodes to parentItems/childItems and then save it to the local machine as a xml file (since this is resource intensive). Then use something like "XMLDiff https://stackoverflow.com/questions/167946/how-would-you-compare-two-xml-documents " and generate a report of pages with same name and different CP's

Page | Parent Components TCM ID’s | Child Components TCM ID’s

Does this make sense, or is there any better way.


2 Answers 2


I agree with your approach of using the Core Service to get the IDs of all of the Components on the localised versions of the Page.

However, if you're just storing the IDs of the Components on the Pages, then I'd be tempted to do this (and the comparison to the US version) in objects in your application code and then write this out to the screen, rather than storing every localised page (that contains different content) as XML and then comparing these.

If you need to persist this information then you could write out all of the Pages' information to a single XML file or spreadsheet (possibly CSV) from your app.

You've only said that you're interested in different Components (on child Pages) in your question. However, if you're interested in whether the content is different on the published pages, then you may want to consider the scenario of localised child Pages that have the same Components as the US Page, but use different Component Templates for these (thus, potentially, rendering different content!).

Hope this helps!


The Publisher will package all the components used in a page as an XML and send it to the deployer (based on which publication you are publishing from). You can take a look at the transaction package and see that has all the information you need. If it does, the resource intensive (heavy lifting) is available to you.

You can write a simple deployer extension to read the pages.xml and components.xml and store that in your database. You can also add render instructions to the your component presentation package by using templating code. Your reports GUI can interact with the database to display the results in the manner that you would like.

The drawback of this approach is that you are required to republish the pages, load on the deployer and also the report will only consist of items that are published or unpublished and NOT all items drafted in the CME. If you need the report to be available in the CME itself, you can create a custom page.

Documentation on deployer extension can be found HERE and a quick guide to get started with a deployer extension is available HERE

Hope it helps!

  • Thank you Shiva, re-publish is not an option for me at this point
    – Harish A
    Jul 5, 2016 at 14:03

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.