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:
- Create a new Site Collection using the Publishing -> Enterprise Wiki template.
- Edit the Enterprise Wiki Page Layout content type. Set the field Wiki Categories to "Required" instead of "Optional".
- Go to the home page. Click the "Edit Page" link, which opens the page in edit mode.
- Edit the page and add a new wiki link, like this one:
- 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).
- 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...