Publishing Page Settings Broken By Missing User ID

I recently tripped across an issue with MOSS publishing that caused considerable head scratching. Because the scenario that gave rise to this is (probably) quite rare, I doubt many people will encounter this in “real life”. So with that in mind, here’s what happened.

My current assignment is on a project where the previous consultants were let go. When the previous firm left, the only deliverable they gave to my client was a content database detached from the consultant’s MOSS development environment. No features. No solutions. Just a database.

This method of delivery had the unfortunate downside of leaving occasional “loose ends” in the database such as broken page layout links and references to user ids that don’t exist in the client’s environment.

Now the problem of broken page layout links arising in certain circumstances is well-known. Someone has even written a STSADM extension to deal with the problem: (http://stsadm.blogspot.com/2007_08_01_archive.html)

However, the user ids that no longer exist in the target environment can cause considerable consternation if they are removed from the MOSS “people and groups”. For example, if a “bogus” user id is deleted from the system, you’ll no longer be able to view the “page settings” for each publishing page that was originally created by the now deleted user id. (The MOSS stack trace clearly indicates that it’s looking for the now missing user id.) As far as I know, there is no “easy code fix” like there is for broken page layout URLs because the “created by” field associated with each page appears to be read only.

So, what to do about it? The only solution I found was to follow the following steps:

-- create a new page

-- copy the content in the various page layout fields from the old “broken” page to the new page

-- save the new page

-- delete the old

-- rename the new page to use the old name.

All this can be done via the browser (no need for SharePoint Designer). The process could also be automated with C#, but given the low number of “legacy” pages that we had, we just decided to stick with the manual process.