I was recently debugging an issue with a custom application page used to display a user's profile on the mobile version of a client's SharePoint 2010 intranet. The page was based on the out-of-the-box Person.aspx page, customized with additional information and branding, and stored in the _layouts directory. It was later discovered that the standard SharePoint search box delegate control, referenced from the master page, would always direct the user to the OSSearchResults.aspx page when the search was conducted from this mobile profile page. From any other page, the configured search settings were respected. Weird, right?!
After a lot of digging and testing, I discovered that there is evidently something very special about the IPersonalPage interface in SharePoint. This sounds ridiculous, because an interface shouldn't have any code associated with it, but that's the way it is. In this case, all the other custom mobile pages inherited from the WebPartPage class, while the mobile profile page inherited from the PersonalWebPartPage class, which implements the interface.
In my case, the solution was to refactor the custom profile page to inherit from WebPartPage like everything else (of course, this also required additional code to be written in order to replace all the built-in profile access and properties from the original parent).
No comments:
Post a Comment