For SharePoint, this is the entry you could put into your master page to link to a CSS file.
<SharePoint:CssRegistration
name="<% $SPUrl:~sitecollection/_catalogs/masterpage/dir/file.css %>"
runat="server"
after="SharepointCssFile"/>
Could someone please break down the pieces of this url? I don't understand the following parts of it and how they work together:
<% - I do know this means less than
$SPUrl:~sitecollection/ - Is this some kind of variable? What's ~ for?
%> - I do know this means greater than
CssRegistration is just one of the many ways of referencing CSS files in
SharePoint.
lower than (<) and greater than (>) obvious, and ~ refers to the root of the current web application.
CssRegistration is particularly interesting because you can use After to make sure your CSS is loaded after another CSS such as core.css
The real relevant parameter is name, which in this tag can be used with SPURL, which in turn can be used with sitecollection or site, to refer to the current sitecollection root, or just the current site/web.
Note that SPURL is only available on SharePoint Server, not Foundation.
To support Foundation you can use ProjectProperty, which takes Url or SiteUrl.
So to wrap up, SPUrl is a token available in SharePoint that we can use to specify a resource from a specific location, relative to the current page, web, site and others.
Related
Is there a way in code to determine if a Web control contains server blocks (other than, for example, parsing out the file, grabbing the contents of the tag, and scanning for <% ... %>)?
My reason for wanting this is because I have a lot of old Web forms that were designed without any regard whatsoever to HTML conformance. The header control (which is included on every page but is inside the body tag) contains the link tag referencing the site's main stylesheet. As long as the page's head tag does not contain server blocks, I can programmatically insert the link tag into Page.Controls.OfType(Of HtmlHead).First(), then set the visibility of the "bad" link tag to false.
Again, this is all legacy stuff (it's in 3.5 now, but most was written in the .NET 1.1 days), so changing everything over to use a master page is something for which I simply do not have the time and budget. Regardless, it would be nice to see the pages come up with the stylesheet pre-loaded, rather than having the browser begin rendering with no styling, then applying the stylesheet once it reaches the reference to it in the body.
Seems like a silly work around but could you change the name of your CSS file so that when the legacy code goes to load, it can't find it?
Although Mufasa entered his response as a comment, this question has been sitting unresolved too long. Therefore, I will surmise that the only solution is his -- to wrap it in a try/catch black.
I have installed SharePoint 2010 on a single machine in farm mode pointing to a db on another server. I would like to start dabbling into branding the site by doing something that I initially thought to be trivially straightforward, link to a custom CSS from a SharePoint 2010 master page.
I have uploaded a custom css (Let's call it custom.css) using SharePoint designer in the Site Assets. What syntax do I need to put to link to it? I have tried the following:
<SharePoint:CssRegistration name="custom.css" After="corev4.css" runat="server"/>
But the server cannot find the CSS file. I receive the following error:
Cannot make a cache safe URL for "1033/styles/custom.css", file not found. Please verify that the file exists under the layouts directory.
I've assumed I need to use SharePoint:CssRegistration - Is my assumption correct?
So what is it exactly that I need to put in the name tag to link to a css uploaded via SharePoint designer?
Am I even on the right track or would you suggest an alternative way of putting this together?
I would use Alternate CSS first. But other options are:
If you put the CSS file in Style Library, you can do this:
<SharePoint:CssRegistration name="<% $SPUrl:~SiteCollection/Style Library/custom.css%>" runat="server"/>
Put the CSS on the server as 14\TEMPLATE\LAYOUTS\1033\STYLES\custom\custom.css and then you can do this:
<SharePoint:CssRegistration name="custom/custom.css" runat="server"/>
Putting the file into its own directory is considered best practice so that it does not interfere with updates to out of the box files.
I don't have a real need to omit the default core.css reference from my HTML pages but I would like to know so I can feel comfortable that I have full control. Thanks
There are many ways to achieve this.
The problem is, once you remove the core.css file you are talking about 6 thousand lines of places that will not appear with a presentation anymore. What I do when we are limited to theme-only visual customization I create a theme that will address any new CSS needs and also replace the elements in the core.css file (themes are loaded AFTER this file, so if you have duplicated declarations in both files, the theme's one will prevail, without using the !important mini-hacks).
Keep in mind that SharePoint in editing mode just doesn't work without this file, you have to use different approaches when you are, for example, talking about an internet-facing site with 100% anonymous users vs an intranet-like portal with everyone creating and editing content on the go.
With all the warnings given, you can go to your masterpage and remove the core.css tag making it invisible:
<SharePoint:CssLink runat="server" Visible="false"/>
Depending on your type of sharepoint site (WSS vs MOSS + Publishing Features) the masterpages may work differently based on configuration, by default (WSS or MOSS without Publishing Features or any change on the matter) your masterpage will open on all the link that do not contain /_layouts/ in the url.
Examples:
/Default.aspx => Masterpage
/DocumentLibrary/Forms/Allitems.aspx => MasterPage
/_layouts/viewlsts.aspx (Show all site content) => no custom
masterpage
This is Microsoft's way to stop you from breaking even more (system pages) with the masterpages, but you can be extreme and use HttpModules or editing the 12/Template/Layouts/LCID folder (affecting the entire web front-end)
Usual scenarios:
Anonymous sites with no core.css when the user is anonymous and normal load when credentials are given (loading speed)
Themes used to let users create their mini-sites and use the branded templates or other sharepoint themes
Masterpages to customize what most of the users usually see, forcing your branding throught the child webs (new websites in non-MOSS Publishing wont inherit the masterpage)
Everything-under-the-masterpage with HttpModules or /12/ modifications (very rinky and complicated)
Note: It's not recommended to customize files from the Site Definition when you can avoid doing so.
When using Mickel's advice, make a copy of the Default.master, rename it to something like Custom.master and apply changes to that file. Then right click your custom master page and select "Set as default master page."
This is all done from within SharePoint Designer btw
Simply add your own custom CSS style sheet via Central Admin - this will be applied last, after Core.css so you can override anything you wish. You do not want to remove it! :-)
I am implementing themes to enable an existing website to be rebranded (logos, colors, images etc.) depending on the requesting URL. I understand how to do that and have got the skins working fine except for some exceptions related to the URLs of images.
Specifically I have a control property that it is not feasible to skin. Prior to implementing themes it looked like this:
<DisplayImageChecked Url="~/Images/BobIcon-Green.png" />
Obviously that will not work with themes. So after much trial and error and reading I am trying to implement it like this:
<DisplayImageChecked Url="~/AppThemes/<%= Page.Theme %>/Images/BobIcon-Green.png" />
However that does not work. The generated html looks like:
<img src="AppThemes/%3C%25=%20Page.Theme%20%25%3E/Images/BobIcon-Green.png"/>
Any pointers in the right direction would be appreciated.
David
Use the binding syntax inside a databound control (watch the single vs double quotes):
<DisplayImageChecked Url='<%# "~/AppThemes/" + Page.Theme + "/Images/BobIcon-Green.png" %>' />
Is there a reason that you can't just dump the images in the same folder as the theme? If you put an image say for example: "image.gif" into the theme folder, then you can simply refer to it directly in your skin.
ImageUrl="image.gif"
This will resolve just fine when you apply this skin on a control in your page. Also much easier than trying to do the dynamic URL thing.
You may also use "Images/BobIcon-Green.png" as Url. ASP will take care of resolving the Url to the directory within your theme.
Here's the right way to go about your task:
Adorn your property with the UrlProperty attribute, this will tell ASP.NET to automatically translate your partial URL into the proper url.
Using "~/AppThemes/" + Page.Theme + "/Images/BobIcon-Green.png" will do the trick, but it's NOT the preferred way because you need to do all the work yourself and it's always good practice to leave all the work to ASP
I'm relatively new to ASP.NET and was wondering if anyone could shed some light on when I should use relative references (e.g. ../images/banner_tinga.jpg) versus the tilde (e.g. ~/images/banner_tinga.jpg). Depending on the situation you can accomplish the same goal using either. What are the pros and cons of each mechanism? One argument for the relative reference seems to be Visual Studio's design time dislike for resources referenced by the tilde. Whenever I reference a css file that why it indicates it can not be found.
Regards,
javacavaj
The tilde will work only with controls that have runat="server" attribute, and will not work with standard HTML controls. So there's really no universal choice. If you wish to use use tilde with HTML controls you'll have to mark them runat="server", like this
<img src="~/images/myimage.png" runat="server">
But it doesn't seem like a good practice cause it will be added to the viewstate. But then, you can also do this
<img src="~/images/myimage.png" runat="server" EnableViewState="False">
So then the choice becomes truly universal.
Now answering your original question:
I think it's better to use the '~' tilde, because it gives you a point of reference -- the root of your website. The relative path scheme '../' will fail if you change the folder of the webpage and take it to a different level (higher or lower in the hierarchy)
Hope this helped.
To get to your CSS file, do this
<link href="<%= VirtualPathUtility.ToAbsolute("~/css/style.css/") %>" type="text/css">
Hmmm...I disagree with #StevenMcD completely. The tilde always references the root of the web application that you're developing, whereas the relative path notation is based upon your current location within the web application. I think in the long run, if you reorganize or restructure the file locations of the web pages, the tilde notation will make it much easier for you to refactor since you always know that the base path (~) is referring to the root of the web application. You cannot be assured of that if using "../" notation.
One other note...the tilde (~) notation is very handy when using user controls and masterpages in ASP.NET. When you drop in a user control onto a webform, that webform can be nested in any part of your application's file structure. Relative paths simply aren't guaranteed to work in that scenarion. By using the tilde notation, all paths can be written in code and will work because they're based on the root of the web application. Hope this helps.
By the way, the use of the ~ is not deprecated in any way in ASP.NET.
UPDATE: As Cyril mentioned, the ~ is only available to you when using ASP.NET controls. Pure HTML elements won't work with it.
Personally I only use relative references now and avoid the tilde. It may lead to problems further down the line. Although I can't show any reference material connected to it, I remember hearing/reading somewhere that tilde references have been deprecated