I'm having a weird problem on one of my client's systems. The have a SharePoint 2010 Enterprise Wiki. I extended the wiki content type and included some extra fields (site columns). I also created a custom Page Layout that includes page controls to edit the values of these new fields. Some of these fields are set to be required.

When a user edits a wiki article and saves it without providing a value for the required fields, SharePoint prevents the save and displays errors next to the field content controls that require a value. However, the main content (text) of the wiki article also gets altered by SharePoint. Every bracket gets escaped, which effectively renders all wiki page links useless. I.e. when an article has the following wiki page link:

[[link to other article]]

SharePoint changes it to:

\[[link to other article\]]

Steps to reproduce:

  1. Create a new Site Collection using the Publishing -> Enterprise Wiki template.
  2. Edit the Enterprise Wiki Page Layout content type. Set the field Wiki Categories to "Required" instead of "Optional".
  3. Go to the home page. Click the "Edit Page" link, which opens the page in edit mode.
  4. Edit the page and add a new wiki link, like this one: [[Test Page]]
  5. Save the page. SharePoint won't save it, but instead show an error that the Categories need to be filled in (remember, we set it to Required).
  6. Look at the wiki's content. The wiki link added at step 4 should now look like: \[[Test Page\]], which causes the link to be no longer regarded as a link.

Does anybody know why? An out of the box install doesn't exhibit this behaviour. Can it be a Cumulative Update bug causing this? (see update below). They have the December 2011 CU installed.

Cross posted this on MSDN forums: http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/d3ae0b2b-137c-45b1-b2d8-559b74192cae

Update 1: It looks like the December 2011 Cumulative Update introduced this bug. Investigating further...

Update 2: Forget about the Cumulative Updates. Same behaviour in the current Information Worker Demo VM, which is currently at SP1 level. I'm pretty sure pre-SP1 didn't have it though. Gotta test this some more...

Update 3: Today I confirmed SharePoint 2010 RTM doesn't have this bug. So it must have been introduced somewhere between RTM and SP1.

Update 4: On the MSDN Forums a Microsoft employee said the following:

"After research, it has been discovered that this is a known reproducible issue with the SharePoint 2010 wiki feature. We are currently working on a solution for this issue, please continue to monitor Cumulative Update schedules for a resolution."

So it looks like Microsoft confirmed this bug and a fix is on the way...

  • This was well over a year ago, and I am now having this same issue... I dont know if there is any hope of me getting a speedy resolution. If anyone can assist, it would be greatly appreciated.
    – user25560
    May 2 '14 at 18:23
  • Thanks for posting! I was looking for a way to escape the double brackets to print them as literal and this did the trick.
    – k1DBLITZ
    Jun 5 '15 at 14:56
  • I've got this bug on our Sharepoint Online site May 16 '16 at 13:54

So Microsoft confirmed this bug in the thread on the MSDN forums:

This is an official confirmation that it is a known reproducible issue that is actively being worked on. At this point I cannot state when or if a fix for the issue will be released.

... you might want to hold off using a support ticket until the next CU is released since it is so close to release time.

So now we wait...

I did create a quick fix for this problem, by adding a piece of Javascript to the custom wiki page layout. It searches the wiki content editor control for the escaped brackets and removes the backslashes. Use it at your own risk :-)

<script type="text/javascript">

    jQuery(document).ready(function() {
        setTimeout('FixEscapedWikiLinks()', 1500);

    function FixEscapedWikiLinks()
        var region = RTE.Canvas.currentEditableRegion();
        if (region != null) {
            var html = region.innerHTML;
            var pattern = /\\+((\[|\]))/gm;
            html = html.replace(pattern, '$1');
            region.innerHTML = html;


I encountered this problem and found it was being caused by a different reason.

When viewing the raw html for the page, a span element was inserted in the middle of my tag which was causing the Sharepoint Page to understand it as text. After removing the hidden span element, the tag properly generated on save.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.