How to find pages published to STAGING but not to LIVE?

Question

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

Answer 1

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.

Answer 2

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)

Answer 3

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.

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).

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.

Answer 4

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.

Answer 5

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
   Next
   For Each iSubSG in parentSG.GetItems(4)
      If iSubSG.IsPublishable Then
         loadPageArray(iSubSG.id)
      End If
   Next
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
   Next
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

Answer 6

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.