As the title says,
When I try to modify and APP on a site with a custom CSS registered with CSSRegistration:
<SharePoint:CssRegistration name=”<%$SPUrl:~SiteCollection/Style Library/~language/Themable/icapapp.css%>” runat=”server” EnableCssTheming=”true” />
I get the error shown in the title (Exact error as an attachement)
So.. you can get around this on premises by utilising _layouts for me which is bad practice as you never know what an update will include and besides this on 365 so is a no go area. Or of course you don’t use custom themeable css… Which totally lets down the whole themeing concept.
Recap:
- Masterpage on main site has custom themeable css registered WORKS
- Add an App and configure
- App Properties page doesn’t load CSS due to cannot make cache safe URL error
- It is automatically trying to append the hive/~language url to the front
- Could this be a publishing error? SPUrl insufficient in this case?
- Due to site-appid.sharepoint.com address it is attempting to resolve using relative url?
?id=6614983%3AUploadedFile%3A63812
With all of the above I have decided to fix this with JavaScript.
Instead of adding CSS I add JS instructions to load custom CSS.
Something like this:
/*
Dynamic CSS loading – either on page load or dynamic change of css
filename: no extension
key: unique ID for the tag
*/
UniTech.IntranetFramework.UpdateStyleSheet = function (filename, key) {
var stylesheet = UniTech.IntranetFramework.Constants.cssLocation + “/” + filename + “.css”;
if ($(“#” + key +”css”).length == 0) {
$(“head”).append(“<link>”);
css = $(“head”).children(“:last”);
css.prop({
id: “dynamic_css”,
rel: “stylesheet”,
type: “text/css”,
href: stylesheet
});
} else {
$(“#” + key +”css”).attr(“href”, stylesheet);
}
}
Based on the code from here: http://www.webgeekly.com/tutorials/jquery/how-to-switch-css-files-on-the-fly-using-jquery/
Still makes me think is this a unintended side effect because of the App model or is it intended.
I am sending it in as an issue and I will await a response.
In the mean time I will investigate on other ways to achieve this, perhaps maybe a way to block APPs from attempting to load custom CSS for their configuration pages.
Thank you very much for the reply!
Hi Hugh,
Good question, I remember hitting something similar myself.
What I found is that, in a nutshell, Microsoft did not intend CssRegistration/CssLink to be used for anything other than files in the _Layouts folder. You can see this if you crack open this stuff in Reflector or similar – hopefully the image below will come through:
Chris.
?width=721