CodeProject
Quite recently, we went to a client to implement a set of custom MasterPages along with its own set of the JavaScript framework and styling-sheets.
Everything went pretty smooth for development and UAT environment until the final deployment to the production farm. After firing off the PS script, everything seems pretty dandy and up-running, except the styling and Ajax stopped working for unknown reasons.
Once quickly fire-off my best pal (Firebug and Chrome Development Console), the problem was revealed in a second by the Absolutely Path not working since we altered the site-collection structure in the production environment.
Then the question came to me that how we could come up a better reference URL rather than hard-coded or the absolute one. After quickly looking this up from MSDN, I came up this quick and neat solution below:
JavaScript Files
<asp:ScriptManager id="ScriptManager" runat="server" EnablePageMethods="false"
EnablePartialRendering="true" EnableScriptGlobalization="false"
EnableScriptLocalization="true">
<Scripts>
<asp:ScriptReference
Path="<%$SPUrl:~SiteCollection/Style Library/ProjectPortal/js/jquery-1.5.2.js%>">
</asp:ScriptReference>
<asp:ScriptReference
Path="<%$SPUrl:~SiteCollection/Style
Library/ProjectPortal/js/ProjectPortalLoadAfterJquery.js%>">
</asp:ScriptReference>
</Scripts>
</asp:ScriptManager>
StyleSheet Files
<SharePoint:CssRegistration ID="CssRegistration1"
name="<% $SPUrl:~sitecollection/Style Library/ProjectPortal/ppb-styles.css %>"
After="corev4.css" runat="server"/>
As the codes shown above, the magic trick here is all about leveraging syntax in order to get the proper URL path populated regardless of the change of the URL path since the site collection level structure has been modified.
As for the sake of the best practice, we have determined to use WSP to deploy all custom MasterPages, styling recourse and Ajax script components, thereby this little tip is definitely benefitting us in the long-run.
