By: Knox Cameron | Updated: 2011-01-06 | Comments (3) | Related: > Sharepoint
Wiki libraries are a great way for people to share "free form" information with their team and wider audiences. They includes features such as letting you easily create new pages simply by creating a "forward" link to a page name that doesn't exist yet, as well as letting you review changes made over a page's history, and checking for "incoming links" to a page.
SharePoint's wikis are basic but functional. Some of the features SharePoint leaves out, such as text formatting markup, is not required because SharePoint's native functionality is better. Plus you have other SharePoint functionality not typically found in wikis such as web parts, lists and libraries, metadata and so on.
The problem is that they can be a bit too "free form": if you create a new page, it's always blank. Often, it would be nice to create pages with a standard layout to show the user what information to include. For example, you might create a wiki library to hold pages for team members to share status information about each active project. It would be good to have a standard layout with the project name and manager at the top of each page. However, users have to know to add that information each time they create a new page.
Unfortunately, there is no system of templates for wiki pages in SharePoint. Not even in SharePoint 2010, where wiki pages have become the default page type for non-publishing sites. There are some add-ons available to provide that kind of functionality, such as the community kit in CodePlex, but they require installation of components on the server.
Both of these solutions can be implemented as-is by an administrator without programming knowledge. However, programming knowledge would let you adapt and enhance the solutions, and would be useful if you need to troubleshoot issues.
Either solution could be used to support multiple templates - just follow the steps again in the same or a different library.
SharePoint 2007 - copy content
For this solution, you will need to find some internal information about the page that comes up when you create a new wiki page. To get this, you will need a tool like the Internet Explorer Developer's Toolbar, available as a free add-on for Internet Explorer up to version 7 (Download details: Internet Explorer Developer Toolbar), but available as a standard component in Internet Explorer 8 (press F12 to activate it). For FireFox, an equivalent tool is Firebug.
The steps are:
Get˙a copy of˙the URL of the page that comes up if you select the option to create a new page in the wiki library. Copy it from the address bar of the browser into a NotePad file. It looks something like:
Use the Internet Explorer Developer's Toolbar (or equivalent) to get a copy of the IDs of the page name field (an html INPUT control)˙and page body field˙(an html IFRAME)˙on the CreateWebPage.aspx page.
- Open the toolbar then select the toolbar option to Select Element by Click
- In the page, click on the Name field. It will be highlighted with a blue border.
- In the developer toolbar, find the id property, select it and copy it to NotePad
- Repeat the same process to select the page body field. In the toolbar, you will see that the iFrame that contains it is above it in the hierarchy. Select the iFrame, then copy the id into NotePad as before.
Create the page with "template" content.
In the source (HTML) view of the page body content, put the tag <div id=TemplateText> at the start of the template content, and </div> at the end, to mark the content to be copied to the new page, for example:
Select Edit Page from the Site Actions menu (not the wiki "edit" link) and add a content editor web part to the web part zone at the bottom of the˙template page.
Open the properties of the content editor web part, and select the button to edit the source.
Copy and paste the below script.
Replace the page creation URL, page name field ID and page body field ID in the script with the values for your environment, which are saved in your NotePad file.
Save the changes, and save the page. Then test!
Unfortunately, the solution above won't work for SharePoint 2010.
For a start, it does not have a page for creating new wiki pages like the one in 2007. Even if it did, the above solution would not bring over all the content.
The reason is that SharePoint 2010 now allows you to embed web parts in the rich text content of wiki pages. Although these appear as part of the rich content to a user, on the page they are actually stored in a hidden web part zone. The rich content just contains a marker where they are placed when the page is displayed. So the above approach would copy the markers but miss the actual web parts.
So what we need is a solution that will actually copy the template page as a complete object. The best way I could find to do this was to use the FrontPage RPC protocol, the same protocol used by SharePoint Designer when editing a site.
This protocol is documented and supported, and has a move document Method that does what we need (when you give it the option to copy rather than actually move the file).˙However, it is also very old, and pre-dates all our modern standards for web services. I found it temperamental about getting data in exactly the right format, and the results of operations are returned as fairly unstructured html. The key to getting the protocol right in the end was to use Fiddler to capture the commands used by SharePoint Designer to copy a file, and emulate those commands.
The steps are:
- Download the jQuery library file, and save it into a SharePoint library on your site. Make sure it is published and available to all users.
- Create the template page in your wiki site/library. For demonstration, I made one that looks like this:
- Create a page to be used to create new pages. I called mine "NewProject". Add some explanatory text, then insert a Content Editor web part in the rich content field.
- Click inside the content area of the web part and select HTML > Edit HTML Source from the ribbon. Make sure you are not seeing the HTML source of the rich text field containing the web part (I find this sometimes happens). Copy and paste the following code.
- Edit the three variables with names in BLOCK CAPITALS near the top to match your site URL, the name of the library containing the wiki pages and the file name of the template page. Also edit the path to the jQuery library file near the top, or remove that block if you already load the jQuery library in your master page.
- Save the changes to the Content Editor Web Part then save the page. Now you can test!
In this screenshot, I entered a name for a new page of "Test" and clicked the button. This was successfully created by copying the template (although SharePoint reports it as a "rename" operation), and the link can be used to go to the new page. To demonstrate the error handling, I clicked the button again without changing the name, which generated the error that the file already exists.˙
Comments and caveats
This solution requires the FrontPage RPC functionality to work. This is enabled by default, but may be disabled in your environment if (for example) use of SharePoint Designer is blocked.
I have not tested it, but this solution should also work for SharePoint 2007. The version number on the "move document" method may need to be adjusted.
The solution could easily be adapted to other requirements involving copying files in SharePoint.
Some notes on the code for programmers who are interested:
- I had problems with the id selector '#' in jQuery not working reliably, similar to what was described in jQuery in SharePoint for Hackers, hence the use of getElementById.
- I ended up manually encoding some of the characters when I was having issues getting the RPC calls to work. Some of that is probably unnecessary, but hey, it works.
- I wasted a lot of time trying to use the object/value pairs format for the data parameter on the ajax call, but gave up as it never seemed to encode them the way the FrontPage RPC requires. In particular, RPC required the underscore character in parameter names to be encoded. Manually encoding my own string was inelegant, but again, it works.
- The results from the RPC call are returned as an HTML page with paragraphs and list items. Hence the string matching to find the useful bits of information to return to the user.
- Set up a wiki library and try out the solution for creating pages from a template that is suitable for the version of SharePoint you are using.
- Learn more about understanding and creating libraries in SharePoint 2010
- Explore the other possibilities for using jQuery in SharePoint, for example Hiding the SharePoint Search Scope Dropdown List.
Last Updated: 2011-01-06