We had a custom webpart that had an UpdatePanel to asynchronously execute some actions. So far, nothing unusual.
The problem was it worked on a Dev box, but not on the soon to be Live site. Ever heard this one? :)
This webpart had been developed by someone else but, as far as I'm concerned, it is as valid approach as the approach I usually use of leveraging SharePoint's JavaScript Client Side Object Model (CSOM) - or jQuery AJAX functions in a non SharePoint request/scenario.
So I was reluctant to change the webpart, even being quite sure using CSOM would solve it. If it's a valid approach, something else might be wrong. The code behind was actually executed, as SharePoint items were being added to the desired list as it was supposed to. The UpdateProgress panel was also behaving as expected, but the HTML in webpart would not get updated once our code behind was executed. We weren't doing anything complex, just hiding and showing some messages and disabling some controls.
After searching for the issue, I came across this forum thread on MSDN. One of the comments raises the question about whether the SPWebPartManager server tag is in the body or not. So I decided to check our masterpage. We had implemented our masterpages with the help of the Design Manager, so we had an HTML file and auto-generated .master file.
Going through the files, I quickly found that the issue was exactly that. The SPWebPartManager was placed in the <head>, not in the <body>.
All I had to do was changing the HTML file, by moving this part:
from the <head> to the first line in <body>. The HTML file doesn't actually have any SharePoint control for the SharePointForm or the ScriptManager, those are generated automatically when the convertion from HTML to .master happens, but by placing the SPWebPartManager on the first line of the <body>, SharePoint will then convert it appropriately so that in the .master you have:<body onhashchange="if (typeof(_spBodyOnHashChange) != 'undefined') _spBodyOnHashChange();">
[...]
[...]
<body>
The reason it was working on that particular Dev box, was because we didn't have our masterpage deployed there and the default masterpage was being used. Turns out the default masterpages have the SPWebPartManager in the right location.
The HTML masterpages, on the other hand, place the SPWebPartManager incorrectly by default. You can see this in the MSDN article How to: Convert an HTML file into a master page in SharePoint 2013 in the "Reference: Examples of SharePoint markup added to the HTML file > Markup added to the <head> tag" section.
Hope it helps if you are facing the same issue!
No comments:
Post a Comment