in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

Toth’s Tales from the Trenches

Practical SharePoint experience articles, tips, and frustrated rants and ravings.

October 2007 - Posts

  • Using named anchors in SharePoint Wiki pages

    If you've ever tried to add a named anchor hyperlink in a MOSS/SharePoint Wiki page, you'll find that the SharePoint rich text editor does not support adding named anchors (hyperlinks to areas in the same HTML document) via the toolbar buttons (you'll get an error dialog). I was able to find one workaround here, but it didn't quite suit my needs. Following is possibly an easier workaround using root relative urls. To get this functionality, you first need to switch to source view and add some html code by hand.

    Add Anchors

    Click the source button to switch to HTML source view. Add your anchor wherever you need it in the source, for example:

    <a id=”nameofanchorname=”nameofanchor></a>

    When done adding anchors, click OK to go back to the rich text view.

    Linking to Anchors

    To create links to the anchors you just created, you can do this easily from the rich text toolbar by clicking on the Hyperlink button.

    In the Hyperlink dialog, for the Address, specify the root relative URL for the page, in the following format:

    /firstsubsite/secondsubsite/wiki page library name/Name of Wiki Page.aspx#nameofanchor

    You can get this url by going out of edit mode on the page, and back to viewing the page in regular view mode.

    1. Copy the URL from the address bar
    2. Remove the first domain name part of the URL (e.g. http://domain.com)
    3. Add the named anchor portion (e.g. #nameofanchor) to the very end of the url.

     

  • Nice SharePoint error message

    Just for laughs, I thought I'd post this nice error message from SharePoint. Love the slash n's in there. Smile

     

  • Migration Stories - Part 1: Migrating forms to MOSS 2007

    Overview

    The current migration project I am working on is migrating a very large, 8 year-old portal and all its contents from an archaic BroadVision platform to MOSS 2007. BroadVision is absolutely one of the worst portal software packages I have ever seen, and is proving to be quite difficult to migrate into MOSS 2007. This is part 1 of an ongoing series of stories about this project and its challenges.

    Migrating Forms

    BroadVision has support for a crude version of custom web forms, that can be used to collect data and either email the data or save it in a database. These forms are standard html forms with html form tags, and almost all of them have a spot at the top of the form where some introductory html is placed to instruct the user on how to use the form, the form's purpose, etc. This project has about 200 of these forms, for almost every department in the organization.  These forms have very little workflow, with just some primitive options to email or CC people when new forms are submitted. There is no easy way to automate this migration.

    Below is an example of one of these forms, which is a form to update an employee's address:

    InfoPath vs Custom Lists vs ASP.NET Web Applications

    The first decision to be made in migrating these forms is choosing the right technology. I presented 3 options to the customer:

    • InfoPath - Pros: Flexible, supports validation, custom actions and workflows, can save data to sharepoint lists, libraries, and external databases. Cons: Requires training and design skills, and sometimes coding and development efforts
    • Custom SharePoint Lists - Pros: Anyone can do it, easy repository for data, built-in export to Excel, Datasheet view, MOSS 2007 workflows. Cons: Limited validation support, little or no design control, data can only be placed in SharePoint
    • Custom asp.net web application - Pros: Complete control over design and storage. Cons: Requires development effort

    With over 200 forms to migrate, very little resources, plenty of new forms yet to be created, and lots of forms that need updating or reviews, the customer wanted every department to own, migrate, and create their own forms. The best solution in this case was the one that empowered the end users to create and manage their own forms as easily as possible.

    For 90% of the forms, the custom list was the right approach, unless a form needed advanced features like validation, pre-population, etc. The only stumbling block then was having the ability to edit the form that is displayed when you create a new item (NewForm.aspx).

    Introductory Text and HTML

    Every form in the old portal had a space at the top where introductory HTML could be placed to provide instructions. Since a custom SharePoint list uses the default NewForm.aspx page when adding a new item, there is really no place where this intro HTML could be placed. To solve this, we used a special querystring to put the NewForm.aspx page into edit mode, where we could add a Content Editor Web Part above the form's contents.

    Following is the method for getting this to work:

    1. Go to the custom list and click the menus to add a new item.
    2. On the New Item form, add a querystring parameter to the end of the url, and hit enter. For example, a typical New Item form's url might be:

      http://intranet/Docs/Lists/Tasks/NewForm.aspx?RootFolder=%2fDocs%2fLists%2fTasks&Source=http%3a%2f%%2fintranet%2fDocs%2fLists%2fTasks%2fAllItems.aspx

      Add the following text to the very end of the url: &ToolPaneView=2

      The new URL becomes:

      http://intranet/Docs/Lists/Tasks/NewForm.aspx?RootFolder=%2fDocs%2fLists%2fTasks&Source=http%3a%2f%2fintranet%2fDocs%2fLists%2fTasks%2fAllItems.aspx&ToolPaneView=2
    3. This puts the page into Edit mode, and displays the Add Web Parts toolpane. Click Next until you see the Content Editor Web Part. Drag it into the Web Part Zone at the top of the page.


    4. In the newly added part, click the link to open the Tool Pane ("To add content, open the tool pane and then click Rich Text Editor.") , and paste your introductory text into the Rich Text Editor. When done, click OK, your instructions are now live on the Form.

    Granted, telling an end user to hack a querystring to add a web part is not the most user friendly approach, but it is certainly something that can be documented well, and is certainly easier than InfoPath training. Of course this step could also be done easily with SharePoint Designer, but that is another layer of complexity that the users don't need.

     

  • Apostrophes in Community Server

    I noticed that the RSS feed for this blog had a screwed up blog title because of the apostrophe in it. It seems that community server is htmlencoding the blog title, and that is getting passed through to the RSS feed as "& # 3 9 ;". This was supposed to be fixed in a service pack, but doesn't seem to have made it in yet on this particular blog.

    In the meantime, I found a workaround. Open your Windows Character Map, and choose the following character:

    Select it, copy it, and paste it into the text box for your blog title. It's a good substitute, and doesn't get encoded. I'm not sure if the same problem exists for post titles, so this workaround may be applicable to those as well.

  • No spell check for wss blog postings

    After creating a blogging site in MOSS 2007, I noticed that there is no Spell Check option when creating a new blog post. That stinks, and so far, I haven't been able to figure out a way to get this working. After looking through the spell check system in MOSS, my head is just spinning, and hopefully someone else can shed some light on how to do this. 

    No spell check on sharepoint blog template

    First thing I did was log an issue on the Community Kit for SharePoint for inclusion in the Enhanced Blog Edition. Please vote for the issue if you want to see this included.

    Next, I started looking around a bit at the various spell check implementations in MOSS 2007, in order to see what is currently in the box, and what I might need to do to get this working for the blog template. I found that there are three different places where spell check is implemented:

    • As a toolbar button on various new/edit item forms (such as the announcements list shown below):

    • As a Button on various new/edit item forms (such as the one on the New publishing page form shown below):

    • As a spell check button shown on the rich text editor (such as the one in the Content Editor Web Part's rich text editor):

    Maybe someone on the SharePoint team can explain why they have these three different implementations?

    Anyways, first thing I did was look for the files that make up the blog template, to see if I could edit the NewPost and EditPost pages to include the spell check button. I dug into C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\Blog\Lists\Posts, and opened up newpost.aspx, and editpost.aspx, and found nothing of interest, just a bunch of asp:content tags.

    Next, I opened up the schema.xml file in the \Posts directory and looked for anything that related to spell check or a toolbar. Down at the bottom of the file, I found this xml, which defines what forms should be used for display, new, and edit forms:

        <Forms>
          <Form Type="DisplayForm" Url="ViewPost.aspx" WebPartZoneID="Main" />
          <Form Type="EditForm" Url="EditPost.aspx" ToolbarTemplate="BlogEditFormToolBar" Template="BlogForm" WebPartZoneID="Main" />
          <Form Type="NewForm" Url="NewPost.aspx" ToolbarTemplate="BlogNewFormToolBar" Template="BlogForm" WebPartZoneID="Main" />
        </Forms>

    The ToolbarTemplate caught my eye, so I searched the /web server extensions/12 folder for "BlogEditFormToolbar" and found it in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES\DefaultTemplates.ascx user control file.

    <SharePoint:RenderingTemplate ID="BlogEditFormToolBar" runat="server">
     <Template>
      <script>
       recycleBinEnabled = <SharePoint:ProjectProperty Property="RecycleBinEnabled" runat="server"/>;
      </script>
      <wssuc:ToolBar CssClass="ms-toolbar" id="toolBarTbl" RightButtonSeparator="&nbsp;" runat="server">
        <Template_Buttons>
         <SharePoint:EditSeriesButton runat="server"/>
         <SharePoint:DeleteItemButton runat="server"/>
         </Template_Buttons>
      </wssuc:ToolBar>
     </Template>
    </SharePoint:RenderingTemplate>

    Notice the Template_Buttons section. There is no <SharePoint:SpellCheckButton> or anything like that in there. So, next, I wanted to see what the default template was like for the plain old EditFormToolbar, which items like the Announcements list uses:

    <SharePoint:RenderingTemplate ID="EditFormToolBar" runat="server">
     <Template>
      <script>
       recycleBinEnabled = <SharePoint:ProjectProperty Property="RecycleBinEnabled" runat="server"/>;
      </script>
      <wssuc:ToolBar CssClass="ms-toolbar" id="toolBarTbl" RightButtonSeparator="&nbsp;" runat="server">
        <Template_Buttons>
         <SharePoint:AttachmentButton runat="server"/>
         <SharePoint:EditSeriesButton runat="server"/>
         <SharePoint:DeleteItemButton runat="server"/>
         <SharePoint:ClaimReleaseTaskButton runat="server"/>
         </Template_Buttons>
      </wssuc:ToolBar>
     </Template>
    </SharePoint:RenderingTemplate>

    Still no SpellCheck button, and really the only difference appears to be that the blog toolbar template is simply trying to remove the <SharePoint:AttachmentButton> so that you aren't able to add attachments to blog posts. Ok, so I wondered if a <SharePoint:SpellCheckButton> even existed at all. Looking at Reflector in the Microsoft.SharePoint.WebControls namespace, I was able to see all the button controls such as the AttachmentButton, but no spell check button.

    Alright, now I'm pretty confused. MS gave us an easy way to add toolbar buttons to the toolbar via this rendering template and bult-in button controls, but they didn't include Spell Check in this same framework. So where the heck does the spell check functionality come from?

    It turns out Spell Check is actually a Feature, and is located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\SpellChecking. Here we go I thought, now I'm on to something. I opened the SpellChecking.xml file, and noticed this:

     <CustomAction 
      Id="CmsCheckSpellingEditForm"
      Location="EditFormToolbar"
      Sequence="10"
      Description="Add spell checking for all list items"
      RegistrationType="ContentType"
      RegistrationId="0x01"
      ControlClass="Microsoft.SharePoint.Publishing.WebControls.SpellCheckToolbarButton"
      ControlAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">
     </CustomAction>

    So, first, I tried creating a new custom action in this file, that points to the BlogEditFormToolbar:

     <CustomAction 
      Id="CmsCheckSpellingBlogEditForm"
      Location="BlogEditFormToolbar"
      Sequence="10"
      Description="Add spell checking for all blog items"
      RegistrationType="ContentType"
      RegistrationId="0x01"
      ControlClass="Microsoft.SharePoint.Publishing.WebControls.SpellCheckToolbarButton"
      ControlAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">
     </CustomAction>

    No dice. Next, I decided that I would simply try adjusting the Blog template to use the EditFormToolbar template instead of the BlogEditFormToolbar by editing the schema.xml file for the blog template:

        <Forms>
          <Form Type="DisplayForm" Url="ViewPost.aspx" WebPartZoneID="Main" />
          <Form Type="EditForm" Url="EditPost.aspx" ToolbarTemplate="EditFormToolBar" Template="BlogForm" WebPartZoneID="Main" />
          <Form Type="NewForm" Url="NewPost.aspx" ToolbarTemplate="NewFormToolBar" Template="BlogForm" WebPartZoneID="Main" />
        </Forms>

    Still no dice. If you've made it this far, any thoughts? Or any explanations as to why this is so damn convoluted?


Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts