SharePoint Wiki Or Publishing Pages Part 2

Structuring the Wiki Page Library

A wiki page library is essentially a list which has various columns and the actual column that contains the content of a Wiki Page is held in the column named WikiContent.  You can also add to this Wiki Page Library more columns so that essentially you will be able to use the values placed in these custom columns to get more functional logic out of your wiki site.  So in the library I have created I have added the following columns:-

DisplayInContents – this is a Yes/No field and will be used to decide if the page should be listed in the main contents page.

PageNo – this is a numerical field that can be used to assign a page no to the wiki page so that we can use it to control ordering for the wiki pages.

Section – this is a choice field which I use to assign the Section heading that a wiki page will belong to.  So for instance the page

PrintView – a Yes/No field to indicate that you want the page to appear when creating a view for printing the wiki page library ( more on this later).

Creating the Pages and Setting their Properties

You have two choices in this matter – you can either create each page using the SharePoint interface and using the Wiki Page features like the place holders OR you can devise a way to create all your pages in one go through use of a Spreadsheet and some SharePoint server level programming.  In my case with over 100 pages to do – I had no choice but to go for the later method.

The approach you should think about using is devising a console application which will have the following:-

1)    A main program as is the default which will have various methods to create the pages and set their properties like the Page No.

2)    Various classes which will hold dictionary objects that can be used to set the properties.

Now to create the Wiki Pages I would like to refer you to a blog I did a few months ago which can be found at:-

http://mytechbook.info/create-wiki-pages-in-sharepoint-using-list-web-service/

In the above article I actually use the list web service to create all my wiki pages which have their names stored in a List object.

The spread sheet that needs to be created will contain the names of each of the pages, and also certain properties which can only be manually entered in. From these values in the spreadsheets – we can create the necessary formula columns which will have code elements (in C#) that we can copy and paste into a class file.  The screenshot below is taken from the spreadsheet:-

 Spreadsheet1

 

From the above I have in column E just defined an entry that can fit straight into a Dictionary object listing as follows:-

public static Dictionary<string, long> myOrder 
                        = new Dictionary<string, long>()
{
   {"CRM",10},
   {"Customizations",11},
   {“Marketing Lists",12},
   {"Reports",13},
    ……
}

Once you have defined the above you can then start to code a method which will process through the Wiki Page library, and identify each of the page names defined in the above Dictionary object and set the page number property as the sample code below shows:-

private static void WritePageNumbers()
{
 const long EMPTYNUMBER = -1;
 using (SPSite site = new SPSite("{your site}"))

{

  using (SPWeb web = site.OpenWeb("{your web}"))
  {
    SPList list = web.Lists["Wiki Lib Name"];
    if (list != null)
    {
      if (list.ItemCount > 0)
      {
        int x = 0;
        while (x < list.ItemCount){
          // find the entry in the array and get the page number...
          SPListItem item = list.Items[x];
          string pageTitle = item.GetFormattedValue("BaseName");
          Console.WriteLine("Searching for page: {0}", pageTitle);
          long value = EMPTYNUMBER;
          if (MyPageOrders.myOrder.TryGetValue(pageTitle, out value))
          {
            if (value != EMPTYNUMBER)
            {
             Console.WriteLine("Found page - 
                  it has order number: {0}", value);
             Console.WriteLine("Adding to SharePoint....");
             item["Display Order No"] = value;
             item.UpdateOverwriteVersion();
            }
          }
          x++;
        }
       }
     }
   }
  }
}

The code above is very simple – it will just process through the pages in the wiki library, and if the ‘BaseName’ property value of the wiki page matches the name supplied in the Dictionary object then the associated page number property will be set.  You can use this same technique to setup the other properties.

Coding the Next and Previous Links

You will have noticed in the spreadsheet sample above that I have in column F created an entry that will go into a class file containing another Dictionary object for purpose of creating the Next and Previous Links for a page.  That is for later use when I will discuss using publishing pages, but for our normal Wiki Page there are some complications involved … namely the underlying HTML.  The Wiki Page layout that I have selected compromises the layout with two columns as shown below for the CRM.Aspx Content page in edit mode:-

CRMInEditMode

As you can see above the Next /Previous links were created using the in-built links functionality available for Wiki Pages using the square bracket notation.

The layout of the wiki page was selected because the pages generally look neater, with  some simple code we can examine the underlying HTML using the following method:-

public static void GetPageListings()
{
 using (SPSite site = new SPSite("http://{site:port}/MyPubSite/MyEntSite"))
 { 
  using (SPWeb web = site.OpenWeb("MyPubSite/MyEntSite"))
  {
   Console.WriteLine("Found Getting [BaseName] properties");                  
   SPList list = web.Lists["Site Pages"];
   if (list != null)
   {
    if (list.ItemCount > 0)
    {
     int x = 0;                         
     while (x < list.ItemCount)
     {
      SPListItem item = list.Items[x];
      Console.WriteLine(item.GetFormattedValue("BaseName"));
      if (item.GetFormattedValue("BaseName").Equals("CRM"))
      {
       Console.WriteLine(item.GetFormattedValue("WikiField"));
      }
      x++;
     }                      
    }
   }
  }
 }
}

The output from the above includes the content of the Wiki (the internal name for the Wiki Contents is called WikiField as shown in the code above).  The contents of the Wiki HMTL turns out to be:-

WikiHTML

From the HTML we can see that the layout of the page is based on a HTML table definition.  So our logic when creating the Wiki Pages would have to take into account ensuring that the correct page layout is selected and then applying the necessary HTML so that images, and links go in the correct area of the page.  The actual coding process could get messy as it did for me and at times produced unpredictable results.

It was also at this point where you need to think about the end-user and the issues that they may face where they are not so technically orientated. It is OK to program these pages but ultimately the content management of the Wiki’s will have to be managed by the users and this means the following:-

1)      They would need to understand te intracacies of adding the necessary links using the Wiki Page Square braket syntax.

2)      They would have to understand using the ribbon interface to edit the page so as to add images and also placing it in the correct place.

In my case the users were not satisfied with the general Wiki Page layout structure – and said they needed some guidance when creating these pages.  This is where I had to swtich to the publishing pages method.  But before going onto part 2 of this article we should still look at the common features of both Wiki Pages, and Publishing Pages in developing the content.

Defining the Contents Pages

The contents page (Context.ASPX) page is based on a web part page which exists in the Site Assets library.  The page as shown earlier consists of  a Content Query web part which is used to display the contents page for each of the defined sections as illustrated below:-

WikiContentsPage

If we look at the Content Query settings:-

ContentQueryEditorSettings1

The content query editor is set to pickup properties from the Wiki Page library (the SitePages list) and the filtering is setup to be such that the DisplayInContents property of the Wiki Library is used to display items where the value is set to ‘Yes’.   The ‘Appearance’ settings are setup as follows:-

ContentQueryEditorSettings2

We are as illustrated above setting up the content query editor to create groups by the name of the Section property we added to the Wiki Page Library.  Next we must set the acutal links to display under the related groups.  In the examples that I have setup – we want to only list under the Section headings the pages that are the main Content pages for our various Wiki topics.  The following are the settings:-

ContentQueryEditorSettings3

The Link value of ‘FileRef’ contains the actual URL link to the necessary file, and the BaseName value in the Title property contains the name of the ASPX page without the ASPX extension.  Out of interest I managed to retrieve these ‘Static’ column names of the Wiki Page library by using SharePoint Manager.

By setting up the Cotent Query editor in this way – it should just update automatically each time a new Wiki Page is added to the library with the necessary properties so that it will display.

Printing Wiki Pages

This was probably one of the trickiest requirements  of this whole project.  What I found from my research was that the cost free implementation to allow printing was best served by creating a special printing view for the Wiki Page Library, and ensuring that the view is ordered based on the values set for the Page No. property of each Wiki Page.  Now the view can be further controlled in terms of what it displays by making use of the PrintView property of the Wiki Page library.  By having a value set in this property you can control which Wiki Page content you want to appear in the Printing View to be created.  You can set these up by switching to the list view of the wiki page library which can be got to by clicking on the Pages tab of the ribbon menu when you view a wiki page and select the option to ‘View All Pages’ as shown below:-

ViewAllPagesWikiLib

You should then switch to the editing view of the wiki page list view as shown below:-

Spreadsheet2

The view above is shown in a Datasheet view which allows for easy editing.  From the screenshot above we have ticked PrintView setting for all our CRM related articles.  So now from the may Library settings we can create a view using the following properties:-

1)      just display the Wiki Content column in the view – i.e. tick the Wiki Content field

2)      select all the records where the PrintView is set to ‘Yes’/ticked.

3)      order the displayed records using the PageNo property.

4)      Set the style to Newsletter

Once you have created this view it should display with a horizontal line between each of the wiki pages.  Now if you right click anywhere on the view and click on ‘Print Preview’ option – you should be able to see the content in the preview mode like any other document.  In this view you can adjust the header/footer, add page numbers and also shrink or expand the content using the ‘%’ option.  The following is an illustration of the view:-

PrintPreviewCRM

Now for some this may not be the ideal solution but it is the best we can do without any specialised programming.  However, what is glaringly obvious is the presence of the Next/Previous links and for some even the images may not be a wanted content.  To overcome such problems you would have to place the Next/Previous links within a Summary Links web part, and also the image would need to be placed in an Image Editor web part.  If you do that, then you will find that the content of Web Parts do not display in the view.  Infact if you did a contents page using a normal wiki page and placed a Content Query web part and set it up to display links to the contents (i.e. the wiki pages and their links) then in the print preview you would not see anything listed.

By introducing web parts onto Wiki Pages the user experience becomes more complicated as adding future content becomes more involved  because the user needs to select the necessary web part and then configure the Next/Previous links, adding images, and then protect the content by setting the properties of the actual web part.  In my case it was an unacceptable solution, and at this stage it is time to switch to carrying out this same work using Publishing Pages.

SharePoint Wiki Or Publishing Pages Part 3 >>>

SharePoint Wiki Or Publishing Pages Part 1 <<<

 

:

Leave a Reply