Inconvenient PublishingScheduleControl

, , ,

Screenshot scrape showing the scheduling end date control with the wrong "Expire Immediately" label Microsoft Office SharePoint Server (MOSS) 2007 ships with a rich Web Content Management (WCM) System functionality. Among lots of functionality which simplifies managing content on websites, MOSS 2007 allows you to schedule the publication of your Publishing Pages. The process is as simple as enabling versioning, approval and items scheduling on the Pages Library and editing the desired publication and expiration dates on the Publishing Page. Could you imagine that even something as simple as that can get confusing to the end users?

Expire immediately!

MOSS 2007 allows you to define the publication and expiration date and time for every Publishing Page. As soon as you finish editing the page and save your changes SharePoint will take it over from you and will publish the page on the given date.

You can provide the publication date and time using the so called Publishing Schedule Control:

Scheduling Start Date control 

A similar control is available to enter the expiration date:

Scheduling End Date control 

Have you noticed that SharePoint asks you whether you want your page to expire Immediately? Something seems to be wrong here.

SharePoint allows you to set the schedule for a Publishing Page in at least three ways.

First of all you can go to Page > Page Settings and Schedule page. In the schedule section you will find date and time pickers to enter the publication schedule information:

Page Settings page with the Publishing Scheduling controls 

Did you notice that the first option for the End Date says now Never instead of Immediate? Let’s check it in one more place.

Another spot where you can edit the schedule information is the Page Properties page:

Page Properties page with the schedule controls 

Also here you are able to make your page never expire. So how come the users see the Immediately label while editing the scheduling information through a Page Layout?

Is it that simple?

MOSS 2007 ships with two controls responsible for rendering the schedule picker. There is the PublishingScheduleFieldControl which can be used on Page Layouts and the PublishingScheduleControl which SharePoint uses on the List Forms and on the Page Settings and Schedule page. The PublishingScheduleFieldControl control is nothing more than a wrapper for the PublishingScheduleControl. On page load it retrieves the value from the attached Column and passes it to the PublishingScheduleControl. So how come things get wrong on the Page Layout?

The PublishingScheduleControl has the UseAsEndDate public property (not documented in the MOSS 2007 SDK) which is responsible for rendering the proper label on the first radio button. If it’s a publishing start field it renders Immediately and if it’s a publishing end field it renders Never. As I mentioned the PublishingScheduleFieldControl uses the PublishingScheduleControl as the data input interface. Unfortunately it doesn’t provide any way to set the value for the UseAsEndDate property which therefore remains set to false.

The challenge

When things go wrong in SharePoint I usually try to fix it using the simplest solution possible with as little custom code as I can. The more you develop, the bigger the chance that you will introduce a brand new issue yourself.

So first of all I thought about creating a new Field Control, inheriting from the PublishingScheduleFieldControl, overriding the CreateChildControls method and getting the things right. Using a public property I would make it possible to set the value of the UseAsEndDate property of the underlying PublishingScheduleControl. Unfortunately, the PublishingScheduleFieldControl is sealed so you cannot inherit from it.

Another solution I had in mind was to create a new Field Control which would include all the functionality that the PublishingScheduleFieldControl has and then extend that with my custom UseAsEndDate property and some extra logic in the CreateChildControls method. Unfortunately for me it turned out, that the underlying PublishingScheduleControl is public but doesn’t provide a public constructor. It seemed like I would have to create a new control for this as well… So is it even possible to solve this issue without rebuilding a dozen of SharePoint controls?

The fix

Then I stumbled upon yet another idea: why not use a Control Adapter to set the property correctly? Initially I came up with the following piece of code:

public class PublishingScheduleFieldControlAdapter : ControlAdapter
{
  protected override void CreateChildControls()
  {
    base.CreateChildControls();

    PublishingScheduleControl scheduler = Control.Controls[0] as PublishingScheduleControl;
    if (scheduler != null)
    {
      scheduler.UseAsEndDate = true;
    }
  }
}

It worked but the problem was that it got applied to all PublishingScheduleFieldControls: both for the start and the end date. So how we could distinguish one field type from another? Adding another property is not an option since the PublishingScheduleFieldControl is sealed. We could wrap it in another control and then using the Parent property determine whether we should process it or not. I thought of an easier way though and yet quite elegant one if you ask me.

I extended the code of my Control Adapter as follows:

public class PublishingScheduleFieldControlAdapter : ControlAdapter
{
  protected override void CreateChildControls()
  {
    base.CreateChildControls();

    BaseFieldControl schedulerFieldControl = Control as BaseFieldControl;
    if (schedulerFieldControl.CssClass.Contains("UseAsEndDate"))
    {
      PublishingScheduleControl scheduler = schedulerFieldControl.Controls[0] as PublishingScheduleControl;
      if (scheduler != null)
      {
        scheduler.UseAsEndDate = true;
      }
    }
  }
}

And then changed the PublishingScheduleFieldControl markup in the Page Layout:

<PublishingWebControls:PublishingScheduleFieldControl FieldName="PublishingStartDate" InputFieldLabel="Scheduling Start Date" runat="server" />
<PublishingWebControls:PublishingScheduleFieldControl FieldName="PublishingExpirationDate" CssClass="UseAsEndDate" InputFieldLabel="Scheduling End Date" runat="server" />

And this is the result:

Publishing Schedule controls rendered with correct labels

Using the CssClass property of the control I was able to distinguish the publishing start date control from the publishing end date control and apply the custom logic only when required.

To attach the Control Adapter to the PublishingScheduleFieldControl control I have used the following .browser file:

<browsers>
  <browser refID="Default">
    <controlAdapters>
      <adapter controlType="Microsoft.SharePoint.Publishing.WebControls.PublishingScheduleFieldControl, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" adapterType="Imtech.SharePoint.Controls.PublishingScheduleFieldControlAdapter, Imtech.SharePoint.Controls" />
    </controlAdapters>
  </browser>
</browsers>

Possibly related posts

9 Responses to “Inconvenient PublishingScheduleControl”

  1. Peter vd Berg Says:

    There's another thing I bumped into when working with the publishing schedule controls on the pagelayout:
    If you've published a page through the publishing schedule controls through the pagelayout (start date and end date included) things go well. But then, for instance if the end date is passed and you want to reschedule the page, like re-publish it using the publishing schedule controls on the pagelayout, things go wrong. The page will not be published (approved) and giving a error friendly message. Apparently the only way to re-publish the page is by going to the page properties page or the page, page settings and schedule page and there you can give the start and end date and the page will be saved and published.

    Did you experience this same issue? And with your solution mentioned above, was this fixed?

  2. Waldek Mastykarz Says:

    @Peter vd Berg: as far as I can tell the UseAsEndDate property is being used for more than rendering the label only. Although I haven't experienced the issue you have described (having to do with the fact that most customers don't use the approval workflow/item scheduling), the solution I presented might be just the thing you're looking for.

  3. Peter vd Berg Says:

    @Waldek. My situation is the same as you described in je first part \"The process is as simple as enabling versioning, approval and items scheduling on the Pages Library and editing the desired publication and expiration dates on the Publishing Page.\". I don\'t use extra workflow scheme\'s. But thx for you solution anyway because it gave me new insights in this matter.

  4. Anthony Southworth Says:

    Hi Waldek,

    I'm trying to use your solution with the app_code folder but I'm getting an error PublishingScheduleControl is not defined. Which namespaces are you importing?

  5. Waldek Mastykarz Says:

    @Anthony: This code compiles:

    using System.Web.UI.Adapters;
    using Microsoft.SharePoint.Publishing.WebControls;
    using Microsoft.SharePoint.WebControls;

    namespace ClassLibrary
    {
    public class PublishingScheduleFieldControlAdapter : ControlAdapter
    {
    protected override void CreateChildControls()
    {
    base.CreateChildControls();

    BaseFieldControl schedulerFieldControl = Control as BaseFieldControl;
    if (schedulerFieldControl.CssClass.Contains("UseAsEndDate"))
    {
    PublishingScheduleControl scheduler = schedulerFieldControl.Controls[0] as PublishingScheduleControl;
    if (scheduler != null)
    {
    scheduler.UseAsEndDate = true;
    }
    }
    }
    }
    }

  6. Paul Says:

    I can\'t work out how to get the scheduling controls onto my article page layout. They\'re not there by default and I\'d assumed they would be added at run-time once scheduling was enabled on the library.

    I added them myself in SharePoint Designer but then I have the problem that they also display on the publsihed version!

    Am I missing something here??

  7. Waldek Mastykarz Says:

    @Paul: you should add the scheduling controls inside an Edit Panel. If you want to know how it works exactly, you can examine one of the standard Page Layouts like ArticleLeft.aspx.

  8. Sander Schutten Says:

    The official solution (a workround) is described here: http://support.microsoft.com/kb/940957
    The workaround is somewhat useless.

  9. Sander Schutten Says:

    Microsoft gives a (crappy) workaround: http://support.microsoft.com/kb/940957

Leave a Reply

Security Code:

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS
Copyright © 2007 - 2010 Waldek Mastykarz

Creative Commons License