In Publishing sites, it’s possible to lock down a Rich HTML placeholder so that users can do certain things, but not other things, such as typing in text but not modifying fonts. Someone recently posed the question, is it possible to modify the Wiki homepage in a similar way? That question prompted me to track down just how this Wiki Homepage came to be, in order to find out if it would be possible to lock down the Wiki field on the page.

It turns out, this is the sequence of events (more or less):

  1. You activate the “Wiki Page Home Page” Feature in your site. (This Feature is stored in the WikiPageHomePage directory in the FEATURES folder in your 14 hive.)
  2. This Feature has an activation dependency on the WebPageLibrary Feature, which is a feature that provisions the Wiki Pages library.
  3. The WikiPageHomePage Feature has a Feature Receiver. I haven’t decompiled the code to see what it does, but I can guess: it provisions a new homepage for the site, using a file called wkpstd.aspx found in the /14/TEMPLATE/DocumentTemplates folder as a page template.

    4. It turns out that the WebPageLibrary list schema provisions a new field of type Note, called WikiField. The wkpstd.aspx page simply references this field using a new type of field control called an EmbeddedFormField.

    There’s no magic in how that field renders the Note field, as far as I can see. I went ahead and manually modified the wkpstd.aspx page (I know, I know, this is not best practices, but I was experimenting) to use a regular Note field that I had created in the browser and added to the Wiki Pages Library. Unlike the field that’s created with the list natively, this one I created in the browser didn’t have Rich capabilities. As you can see, pretty much all of the styling options were removed from the ribbon.

    This leads me to believe that you could probably provision your own Note field, setting the RichTextMode property to Compatible, to allow Bold, Underline, Italics, etc., but no HTML.

    The tricky about this whole thing is that the WikiField provisioned with the list is Sealed, which means you can’t override it or make changes. In addition, because inititally applying that Wiki Page Home Page feature triggers all these other features (including executing code in compiled code in a Feature Receiver), it’s hard to swap out any of the features in the process. To me, this seems to make the most sense:

    • Provision your own custom page to the /14/TEMPLATE/DocumentTemplates directory, and change the field reference to a field you want to use.
    • Create your own custom Wiki Pages Library list template, copying and pasting the old one and modifying the values of the WikiField to suit your own needs.
    • Unfortunately, you’ll need to recreate the Microsoft.SharePoint.SPWikiPageHomePageFeatureReceiver class as well, which essentially provisions a new SPFile object at the root of the site, using the new template you created.

    This all seems like an awful lot of work to me. If someone really wants to avoid buying the Server product and wants to hack this template to bits in order to lock down the field, more power to them. To me, I’d rather just train my people to not use pink Comic Sans in their pages.

    As an alternative, I want to point out that the Wiki Site Template ONET.xml file uses the wkpstd.aspx page as well. Instead of retroactively making your site, essentially, a wiki site, you could instead try to copy and paste the Wiki Site Definition and modify it to use your custom list, homepage file, etc. This would seem to me to be an easier approach.