none
Bug: Wiki article links get escaped on save when required field wasn't filled in

    Question

  • 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.

    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: [[Test Page]]
      • 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.

    It looks like this is a bug in SharePoint 2010. My client is running the December 2011 Cumulative Update. But it looks this bug was already present in SP1. And it hasn't been fixed with the August 2012 Cumulative Update.

    By the way: here's the StackExchange question I posted:

    http://sharepoint.stackexchange.com/questions/46799/wiki-article-links-get-escaped-on-save-when-required-field-wasnt-filled-in

    Update: I've confirmed that SharePoint 2010 RTM doesn't have this bug. So it must be introduced somewhere between RTM and SP1.

    • Edited by LZandman Thursday, October 04, 2012 11:07 AM Update
    Wednesday, October 03, 2012 10:26 PM

Answers

  • Hi there,

    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.

    Gregg


    MSFT

    • Marked as answer by LZandman Tuesday, October 09, 2012 9:06 AM
    Monday, October 08, 2012 7:50 PM
  • So, I guess we wait for the offical fix.

    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;
            }
        }
    
    </script>



    • Marked as answer by LZandman Thursday, October 11, 2012 8:22 AM
    • Edited by LZandman Wednesday, October 17, 2012 11:30 AM code fix
    Thursday, October 11, 2012 8:22 AM

All replies

  • Hello,

    Thank you for your question.

    We are trying to involve someone familiar with this topic to further look at this issue.

    This may take some time. Thanks for your patience.

    Thanks,

    Friday, October 05, 2012 10:23 AM
  • I'll also try to submit this issue through regular support channels. I'll see if my client has a support contract.
    Monday, October 08, 2012 8:17 AM
  • Hi there,

    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.

    Gregg


    MSFT

    • Marked as answer by LZandman Tuesday, October 09, 2012 9:06 AM
    Monday, October 08, 2012 7:50 PM
  • Gregg,

    Is this an official confirmation that you are planning to release a fix for this in the near future?

    The reason I ask is that I'm also considering using the official Microsoft support channels. But if the end result of that will be exactly the same as what this thread achieved then I don't want to waste the support ticket (I understand my client has limited support tickets available).

    Tuesday, October 09, 2012 9:05 AM
  • Hi there,

    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.

    Although how your client spends their tickets is their business decision, you might want to hold off using a support ticket until the next CU is released since it is so close to release time.  If the issue persists after that then opening a ticket might be prudent.

    Gregg


    MSFT

    Tuesday, October 09, 2012 7:02 PM
  • OK, thanks!

    Leon

    Tuesday, October 09, 2012 7:05 PM
  • So, I guess we wait for the offical fix.

    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;
            }
        }
    
    </script>



    • Marked as answer by LZandman Thursday, October 11, 2012 8:22 AM
    • Edited by LZandman Wednesday, October 17, 2012 11:30 AM code fix
    Thursday, October 11, 2012 8:22 AM
  • Hey Gregg,

    Was this ever corrected in one of the CU's I've checked the release notes but cannot find anything relating to this as a fix in one of the latest Nov, Dec, Feb CU's...

    Thanks!

    Christian

    Thursday, February 28, 2013 6:35 PM