So this was an issue that we were facing a couple of days back and really had a tough time solving it, thanks to the wierd behaviour of SharePoint.
The Issue:
Ok, as any other project in SharePoint would do we were using custom pagelayouts for our content pages. However, one of the layouts has a user control which would push a couple of webparts into the different webpart zones of layout. This page layout would crash when it gets applied to any page in the site.
Investigations:
As is common in most of the issues in SharePoint, the ULS wouldnt give a clue. We used to get wierd error messages viz. Unknown class for webpartzone 'xyz', div tag is not a valid tag etc.
The interesting part was that trying to debug wouldnt even hit the breakpoint in any of the pages.
Thus, we turned to the only resort for any developer, Google :)
Cause:
We found that SharePoint would introduce two error webparts into the pagelayout while deploying the solution. This could be checked by going to the edit properties of the pagelayout in the master pages and pagelayouts gallery of the site collection. Scrolling down to the end of the page and selecting the option to 'Open the page in Webpart maintenance mode'.
Now the question is from where have these errorwebparts come from? Obviously, no sane developer would do that.
Root Cause:
It was obvious that SharePoint was pushing these, but why? A lot of googling ultimately pointed the issue. As I understand SharePoint expects the '<ZoneTemplate></ZoneTemplate>' tags to be defined within the Webpartzone tags, failing to which it injects these webparts when your custom code tried to insert webparts into the webpartzone.
Resolution:
Well the first step in trying to resolve this was to remove the error webparts from the custom pagelayout, and checking if the issue is gone. Having confirmed that, we added the '<ZoneTemplate></ZoneTemplate>' tags at all places in the page before the closing tage of the webpartzone.
Well abracadabra............. the problem is gone :)
Hope this helps you in solving your problem too.
The Issue:
Ok, as any other project in SharePoint would do we were using custom pagelayouts for our content pages. However, one of the layouts has a user control which would push a couple of webparts into the different webpart zones of layout. This page layout would crash when it gets applied to any page in the site.
![]() |
| Applying Custom Page layout |
Investigations:
As is common in most of the issues in SharePoint, the ULS wouldnt give a clue. We used to get wierd error messages viz. Unknown class for webpartzone 'xyz', div tag is not a valid tag etc.
The interesting part was that trying to debug wouldnt even hit the breakpoint in any of the pages.
Thus, we turned to the only resort for any developer, Google :)
Cause:
We found that SharePoint would introduce two error webparts into the pagelayout while deploying the solution. This could be checked by going to the edit properties of the pagelayout in the master pages and pagelayouts gallery of the site collection. Scrolling down to the end of the page and selecting the option to 'Open the page in Webpart maintenance mode'.
![]() |
| Link to Webpart Page Maintenance Link at the bottom |
Now the question is from where have these errorwebparts come from? Obviously, no sane developer would do that.
Root Cause:
It was obvious that SharePoint was pushing these, but why? A lot of googling ultimately pointed the issue. As I understand SharePoint expects the '<ZoneTemplate></ZoneTemplate>' tags to be defined within the Webpartzone tags, failing to which it injects these webparts when your custom code tried to insert webparts into the webpartzone.
Resolution:
Well the first step in trying to resolve this was to remove the error webparts from the custom pagelayout, and checking if the issue is gone. Having confirmed that, we added the '<ZoneTemplate></ZoneTemplate>' tags at all places in the page before the closing tage of the webpartzone.
Well abracadabra............. the problem is gone :)
Hope this helps you in solving your problem too.


No comments:
Post a Comment