I'd recently written a SharePoint custom navigation object as the default functionality didn't meet the customers needs. It tested out perfectly, only displaying pages which the user was able to see and which were also published.

When deployed on the live server though, no matter what I did, it simply wasn't picking up the fact that some pages had been published, others had expired. It was displaying all content (apart from the hidden pages) in the publishing site.

What was going on?

For too long I focused on the way the dates were being handled by my control...but surely the PortalSiteNavigation provider should take care of this?!?!?? I even went so far as to load the corresponding page item for each SiteMapNode in the SiteMapNodes collection then checking the PublishingStartDate and PublishingExpirationDate (Scheduled Start Date and Scheduled End Date) - Imagine the hit on performance when I did that!

After a lot of hair ripping, and swearing(my boss must have thought I had come down with a case of Tourettes) I found the issue.

Stsadm extensions had been installed on the server- I had used them a number of times to publish content en-masse for the customer - but it never twigged with me that this might be the root cause of all my issues.

A normally super helpful command gl-publishitems was the culprit. Gary Lapointes code has helped me out a number of times, this is by no means a slight against his code - just an unforeseen issue arising from it.

Each time the gl-publishitems code was run against the WebApplication it was republishing the "expired" content. SharePoint doesn't actually use the dates at runtime to decide whether content should be displayed or hidden, it uses the dates as part of the Scheduled Unpublish and Scheduled Publish timer jobs to set the publishing status to published or draft.

The second issue was that not only was gl-publishitems republishing my content, but when the ScheduledUnpublish job would run, it would unpublish the content, however there were previous versions available in the system - and again SharePoint only rolls back the current version not all versions when the Scheduled Unpublish job runs.

So how did I resolve it?

By programmatically getting all versions of the "expired" document and setting them to Draft status using the File.Unpublish Command

I've included code samples in both C# and VB.Net here:

VB.Net

if (Convert.ToDateTime(Actual) < DateTime.Now) then
   rWeb.AllowUnsafeUpdates = true
   lItem.ModerationInformation.Status = SPModerationStatusType.Draft ' set the item to draft
   lItem.File.UnPublish("System Unpublished") 'unpublish the file

   'for each previous version of the file
   Dim objVersionColl As SPListItemVersionCollection = lItem.Versions 
   If objVersionColl.Count > 1 Then 
      Previous = "resetting previous versions"
      'Navigate to each version of the ListItem 
      For Each objVersion As SPListItemVersion In objVersionColl 
         Dim objLstItm As SPListItem = objVersion.ListItem 
    objLstItm.ModerationInformation.Status = SPModerationStatusType.Draft ' set the item to draft
    objLstItm.File.UnPublish("System Unpublished") 'unpublish the file with comment
    objLstItm.SystemUpdate(false) 'updates the list item without incrementing the version
      Next 'Next objVersion
   End If 'End of objVersionColl.Count if
   lItem.SystemUpdate(false)
end if 

C#

if ((Convert.ToDateTime(Actual) < DateTime.Now)) { 
        rWeb.AllowUnsafeUpdates = true; 
        lItem.ModerationInformation.Status = SPModerationStatusType.Draft; 
        // set the item to draft 
        lItem.File.UnPublish("System Unpublished"); 
        //unpublish the file 
        
        //for each previous version of the file 
        SPListItemVersionCollection objVersionColl = lItem.Versions; 
        if (objVersionColl.Count > 1) { 
            Previous = "resetting previous versions"; 
            //Navigate to each version of the ListItem 
            foreach (SPListItemVersion objVersion in objVersionColl) { 
                SPListItem objLstItm = objVersion.ListItem; 
                objLstItm.ModerationInformation.Status = SPModerationStatusType.Draft; 
                // set the item to draft 
                objLstItm.File.UnPublish("System Unpublished"); 
                //unpublish the file with comment 
                objLstItm.SystemUpdate(false); 
                //updates the list item without incrementing the version 
            } 
            //Next objVersion 
        } 
        //End of objVersionColl.Count if 
        lItem.SystemUpdate(false); 
    } 

A word of warning

The code I posted here does not differentiate between major and minor versions. You can only UnPublish Major versions so you will need to handle that yourself.

I used SystemUpdate(false) instead of Update as it doesn't increment the version count - I would recommend you use File.Update instead.

REMEMBER - ALWAYS TAKE A BACKUP!

You've spent the past four days writing the best code in the world to interface with MOSS 2007 and its publishing features. You run it and Argghhhhh! Whats going on, all your publishing data is not there!

Chances are you have done something like this to get the properties:
VB

dim startDate as DateTime = Convert.ToDateTime(item.Properties("PublishingStartDate"));

C#

DateTime startDate = Convert.ToDateTime(item.Properties["PublishingStartDate"]);

Instead, try accessing the properties like this:
VB

dim startDate as DateTime = Convert.ToDateTime(item("PublishingStartDate"));

C#

DateTime startDate = Convert.ToDateTime(item["PublishingStartDate"]);

Now get back to that killer code and get it fixed!

Ok, so you have developed your funky new SharePoint master page and new personal site template. You have set up all the permissions in the SSP to allow users to edit their own profiles and take the headache away from you.

But...

When a user clicks on Edit on the user display page they only see their network account listed. How do you fix it?

First, its nothing you did wrong with permissions or settings. Its down to the way that WSS and MOSS co-exist on the machine.

The resolution is really simple:

• navigate to the 12\templates\layouts hive
• rename the useredit.aspx file to useredit.old.aspx
• copy the editprofile.aspx file and rename the copy to useredit.aspx
  

Your users will now have a fully functioning profile editing page.