How to find out what are the pages published to STAGING but not to LIVE? We need to roll out new features and publish all the pages, but they are some pages which are not ready for PRD yet and we should not publish them. It would be difficult to manually tracking them.
I believe running a database query will do the job, is there any other way? Can you please share the SQL query for this purpose? Thanks

  • 1
    Thanks everyone for the answers! I am expecting a simple answer, apparently it is not that simple. We have some tolerance for certain content in a page get published, so I will take the "publishing the structure group" as the answer. Building workflow seems very involving and time consuming to manage. We are more concerned about certain "new" pages which should not to live before a certain date. Thanks again for all the answers.
    – charles
    Commented Jan 28, 2014 at 18:26

6 Answers 6


If you want to republish all pages which were previously published, you can also publish a structure group.

Republishing a Structure Group will only re-publish pages already published to the selected target.

  • 1
    Be careful with this solution. If pages or components have been modified since they were last published to Live, then they will also be republished. So there is a risk that unapproved changes would go live (unless you have workflow in place) Commented Jan 28, 2014 at 12:50

Like mentioned above avoiding the database is a pre.

A solution that you could take in consideration is writing a core service application. You can choice in the application to republish pages that meet a certain requirement. (Or write them in a log)


If you want to ensure that the new/updated Pages are not published to Live until they are completely ready, then I would recommend using the SDL Tridion Workflow.

You can set a Minimum Approval Status on your Live Publishing Target, and then only once the new/updated Pages have undergone the Workflow Process, and been approved, can they be published to Live.

Tridion - Publishing Target - Minimum Approval Level

Once you have done this, you can use the Workflow option within the Advanced Search to find all items that are within a specific Workflow Process (and Activity).

Tridion - Advanced Search - Workflow Option

If possible, I would recommend upgrading to SDL Tridion 2013 (SP1), as this will give you greater control over the items sent to the Workflow Process, and allow you to use Bundles.

I know that some people will avoid using Workflow, due to the overhead and training needed to implement it. However, if there is a critical (offline) workflow process required (content needs to be completed/approved before it is published to Live), then it probably should be managed through workflow within Tridion.


Please keep in mind, that directly accessing the database is risky, and possibly invalidates your support contract. So be very careful approaching the task in this way. you would be better served writing a script using the APIs to access the data.

That said, Tridion keeps track of what items are published to which targets. So if you publish a Structure Group (or Publication) to live, it will only "re-publish" items that have already been published to that target (unless you un-check the 're-publish only' check box on the publish dialog. So quite possibly your challenge is solved out-of-the-box.

Whether you choose to use the default behavior or write your orn scipt (with SQL or API) , please keep in mind that you should account for updated pages and content which have not been published to live. There is a chance that pages (or components) could have been modified, but not pushed live yet. This will mean that even though the item has a status of 'published to live', it only applies to previous versions. So if you really want to avoid releasing recently updated content, you will need to check when the page and all of it's dependencies were last modified, and try to compare that to the last published date for the item in question. Unfortunately , that will be quite a complicated piece of code to write.


I had reason to create an internal audit screen a couple of years ago which lists all pages and which environments they're published to. This was very useful recently when we moved to new infrastructure and needed a list of which pages were published to which environments much like the OP.

I built a front end screen that reads from XML files generated from Tridion. The XML files are generated by trawling the Tridion publication to create an array of structure groups and then for each structure group I used GetItems(4) to get all pages within and then GetXML(8200) to retrieve all the publish information for each page.

Then it's just down to you to create a front end that can read all this data and present it in a usable form. Mine is nicknamed the BlameThrower™ as more often than not it is used to see who published something in error :)

Anyway, here is a snippet of the XML generation code to get you started:

'Create an Array of all Page Ids
Function loadPageArray(SGId)
   Set parentSG = GetTOMObject(SGId)
   For Each iPage in parentSG.GetItems(64)
      aPage(count) = iPage.id
      count = count + 1
   For Each iSubSG in parentSG.GetItems(4)
      If iSubSG.IsPublishable Then
      End If
End Function

'Creates XML for each Page Id in the array
Function writePageXML(fileNo)
   startPage = ((fileNo - 1) * maxPages) + 1
   endPage = fileNo * maxPages 
   For i = startPage to endPage
      If aPage(i)  "" Then 
         Set pageObj = GetTOMObject(aPage(i))
         repStr = "<?xml version=" & Chr(34) & "1.0" & Chr(34) & "?>"
         XMLString = Replace(pageObj.GetXML(8200),repStr,"")
         vSGPath   = replace(pageObj.OrganizationalItem.GetPath, "&", "&")
         vURLPath  = Replace(pageObj.Info.PublishPath, "\", "/")     
         vFilename = pageObj.Filename & "." & pageObj.FileExtension 
         Writeout "" & vSGPath & "" & vURLPath & "" & vFilename & "" & XMLString & "" & VbCrLf
      End If
End Function

btw, I had to split the data into several files to avoid exceeding our 15 minute publishing limit - hence the extra code for startPage/endPage/maxPages


My suggestion is to write a script that fetches all the stuff currently marked as published, using the coresSrvice. It would only take an hour or so to write such script, and you will utilize the API, which is much cleaner.

  • We also built a page to list all the pages which have been published to staging and live. We are thinking to enhance it to list pages not publishing to live, still working on that.
    – charles
    Commented Jan 29, 2014 at 17:10

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.