Creating an SEO Page Title

We needed to change all of our page titles to optimize them for the search engines (SEO) but we used the page titles in all of our site navigation and we didn’t want the SEO title used in our navigation. Here’s a fairly simple solution but you have to implement it very carefully because it’s really easy to bring your entire site down with one master page publish.

The overall solution is to add a new field to your pages and then tell your master pages to use that new field for the page title. Before you start this process you should 1. Make a list of all of the master pages that will use this new field and 2. Make a list of all of the page layouts that are used by those master pages. You will be modifying all of them!

Steps

  1. Create a new site column called SEOPageTitle
  2. Add the column to your document content type(s)
  3. Change the field where the master page is pulling the page title
     <title><asp:ContentPlaceHolder id=”PlaceHolderSEOPageTitle” runat=”server”/></title>
  4. Move the default page title placeholder to a hidden ContentPlaceHolder control
    Look for this      <asp:panel visible=”false” runat=”server”>
    Add this after it      <asp:ContentPlaceHolder id=”PlaceHolderPageTitle” runat=”server”/>
  5. Check-in the master pages and make sure nothing breaks 🙂
  6. Add a placeholder control to all of the page layouts that will be accessed by the master pages. We added this just above the PageTitle ContentPlaceHolder.
    <asp:Content ContentPlaceholderID=”PlaceHolderSEOPageTitle” runat=”server”>
     <SharePointWebControls:FieldValue id=”SEOPageTitleID” FieldName=”SEOPageTitle” runat=”server”/>
    </asp:Content>
  7. Check-in all of your page layouts

That should be it. If you did everything in the correct order, your site never went down. Just a warning… We had a lot of “strange” errors while we were making these changes. We seemed to get different results on test and production at times, so good luck… 🙂

Now you just need to update all of the pages with a new SEO title

Advertisements

Access Denied With InfoPath Content Types

One of the options for publishing an InfoPath form to a MOSS Forms Server is as a Content Type. When you publish the form, InfoPath asks for a location to publish it. The Content Type is published to entire site collection. When the form template is published to a forms library, the template and the columns in the content type are added to the form library. The form will automatically update the columns that correspond to the content type. The benefit of using a content type is that you can assign multiple form templates to the same form library.

The problem that we ran across was the location selected for publishing the content type. Even though the content type is published to the entire site collection and can be used anywhere in the site, the users appeared to need Contributor rights to the original published location of the content type. So if you published the content type to the a http://site/subsite then the user would need contributor rights to that sub-site or they would get an “Access Denied” when the form was submitted.

The key is to publish the Content Type to the exact location where you’re going to use it and make sure your users have contributor rights. For us it was a forms library.

Fix “Edit this task” In Outlook 2007

If you’ve used some of the out of box workflows in MOSS you’ve probably seen the email sent to approvers. The workflow creates a task, assigns it to the user and sends an email notification. When viewing the email in Outlook 2007 there is a button on the toolbar for editing the task. Viewing the email in any other email program will display the “Edit this task” as a link in the body of the email.

The problem is that the “Edit this task” button in Outlook 2007 doesn’t work some of the time. Clicking the button does nothing. This is apparently related to Outlook 2007 using InfoPath to display the approve/reject form. This form contains a CLSID of {00000000-0000-0000-0000-000000000000}. This CLSID is apparently “kill bitted” on some systems and is prevented from being displayed.

What’s the fix? Delete the registry key for that CLSID.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{00000000-0000-0000-0000-000000000000}

Event ID 6482 – Fix

If you see an error 6482 repeating in the event log on your MOSS server, it’s due to an IIS bug with MOSS. The fix was posted by Microsoft a while ago as KB946517. You can download it here.

The error will look something like this

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 6482
Date:  6/4/2008
Time:  5:15:16 AM
User:  N/A
Computer: <server>
Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchAdminSharedWebServiceInstance (8cd68973-ae31-46e0-ac37-0cfe4db282f0).

Reason: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Techinal Support Details:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Login Required on Anonymous Site

If you have a public web site you might have the ViewFormPagesLockDown feature turned on. This restricts access for anonymous users so they can’t access the pages in your libraries “Forms” folders. There’s a good description of the feature here http://technet.microsoft.com/en-us/library/cc263468.aspx.

If you’re accessing a libraries “Forms” pages, for example by using InfoPath Forms Services, you might need anonymous users to have access to the library.

With the following configuration the user could be prompted for credentials on an anonymous site when trying to access an InfoPath Forms Services form.

  • Browser-based InfoPath Form published to a Forms Library
  • Site has anonymous access set to “Entire Web Site”
  • ViewFormPagesLockDown feature is activated

 

You can fix this by deactivating the ViewFormPagesLockDown feature
stsadm -o deactivatefeature -url “<site URL>” -filename ViewFormPagesLockDown\feature.xml

 

Now toggle the anonymous access setting on the site from “Entire Web Site” to “None” and back to “Entire Web Site”.

 

Then activate the ViewFormPagesLockDown feature again

stsadm -o activatefeature -url “<site URL>” -filename ViewFormPagesLockDown\feature.xml