To simplify our SharePoint environment I am wanting to have a central and single location where all of the master pages are stored so I was hoping to reference the masterpage files directly from the _layouts directory.
I add the files to the "\LAYOUTS\MyMasterPages" directory and then update the SPWeb object to use that path:
web.MasterUrl = "/_layouts/MyMasterPages/newdefault.master"
But when I go to the site I get:
The referenced file
'/_layouts/MyMasterPages/newdefault.master'
is not allowed on this page. at
System.Web.UI.TemplateParser.ProcessError(String
message) at
System.Web.UI.BaseTemplateParser.GetReferencedType(VirtualPath
virtualPath, Boolean allowNoCompile)
at
System.Web.UI.PageParser.ProcessMainDirectiveAttribute(String
deviceName, String name, String value,
IDictionary parseData) at
System.Web.UI.TemplateParser.ProcessMainDirective(IDictionary
mainDirective)
I am assuming that this may be due to trust level security policies and a CAS configuration but I am not entirely sure. Is there a way to allow this central way of using master pages across the enterprise or am I stuck using the /_catalog/ virtual path?
This worked for me:
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
this.MasterPageFile = "path to masterpage";
}
as proposed on:
How to use the site's masterpage from a _layout SharePoint page?
My understanding (but I don't know why) is that Master Pages need to be in the MasterPage gallery of each site collection.
Since you would need to deploy those packages to each SharePoint server (frontend, application, database, etc) in the farm, I think the requirement is either related to clustering, or perhaps to the database and ghosting.
In either case, be sure to use custom features as the way you deploy your master pages regardless of your farm size.
I understand the want to do things your own way with SharePoint, and while I am normally on board with that kind of thinking, the past year of pain has taught me that living inside of the recommended SharePoint boundaries is the best way to go.
The master page used by a SharePoint site must be located in the master page gallery. This is a hard requirement by SharePoint as far as I know.
This gives you more benefit than you might think. This allows you to change the master page in realtime using SharePoint designer with the changes only visible to you. Once the master page is check-in and published as a major version, the change becomes visible to the public. You also have version history on the master page.
I understand you pain, I have been in the same situation as you are. What I learned is: don't fight the platform, just work within it.
Related
I am aware of a program called "SharePoint Designer 20xx), and I would like to know if any of you have modified the default master page to make it.. less confusing and more simplistic. Can this be however I want it or is there limitations?
I also found this:
http://www.expertsharepointconsulting.com/images/Blue%20Large.PNG
I would like to implement a design similar to this! If I were to download a "Free sharepoint master page", would this design only work for the main page of SharePoint? as in if I were to go from the newly added masterpage, to a page called "reports", would it be completely different? If so how can I get around this?
You can create customized masterpages whichever way you want. Usually you don't touch the default ones, specially because you can break some system pages with that. Just create new ones from them or from the minimum.master one.
As an example of a Sharepoint Website using a very customized master page I can point you to a publishing website project I was involved for a Portuguese company: http://www.ana.pt/en-US/Pages/Homepage.aspx
It's all Sharepoint 2010...and it is fully customized
You can of course use the same template for all pages, just have to set it on the root site and say that all sub sites inherit from it.
To achieve the level of design changes you see on that web site you have to build new master pages, page layouts, use JS, CSS and user controls (the website uses little to no web parts).
we don't use Sharepoint designer because that would mean the files becoming unghosted, which can be pain sometimes, and sharepoint designer is not a very good tool.
The way we do it is by implementing everything on visual studio and deploying it via WSP packages. This way everything stays ghosted on the file system. You can check an example here:
http://mihirsharepoint.wordpress.com/2012/11/23/creating-custom-master-page-in-visual-studio-and-deploy-it-to-the-sharepoint-site/
I am making a Sharepoint 2010 WebPart with functionality from another Main Web Application.
To develop the Webpart quickly I have imported the business logic assemblies used in the Main Web Application. The Webpart works and pulls application specific configuration information from the Sharepoint web.config file.
Is this the best place to store this information?
If not..
Where/How should the application specific configuration data be stored in Sharepoint?
The config data contains items like locations of web services etc. The data will only need to be edited by system administrators.
Thanks
Web.Config is, IMHO, a terrible place to store this sort of config information - its hard to deploy and hard to change, especially if you're using multiple web front ends.
The recommended way to do this is to use PropertyBag (key/value pairs) through the .Properties of SPFarm, SPWeb.RootWeb (for site collections), SPWeb, SPList etc (depending upon the scope that you need).
MSDN - Managing Custom Configuration Options for a SharePoint Application
There is a production ready code available as part of the
MSDN - The SharePoint Guidance Library
See Hierarchical configuration manager
This gives you programmatic access to read/write these values. If you want to do this without using the guidance library then you would use something like the following code.
SPWeb web = SPContext.Current.Web;
if (web.Properties.ContainsKey("MyProperty"))
string myProperty = web.Properties["MyProperty"];
If you want a UI to allow admins to easily set the values then use something like SharePoint Property Bag Settings
The easiest way to do it is to create sharepoint list visible only to administrator. It can have 3 columns description, title, value. It will store all config values. Also you can add a link to this list to site settings page.
The web config is always a good place. However if you want to change that data you will have to enforce some sort of site recompile which is a pain for end users.
Theres a nice little app/solution on codeplex to do with the property bag value
http://pbs.codeplex.com/
This is a brilliant little app/solution that ties in with your central administration.
It should be inbuilt i think.
Hope this helps.
We use SharePoint 2007 and have set up a web application with several site collections. One for each of our clients. We'd like to synchronize content in all of the site collections. Maybe having a central repository, then all other site collections get content from here.
I was looking at Lightning Tools Conductor web part and seems a pretty good solution. However, I'm wondering if this can also be possible using the Content Deployment feature to copy a site from the central repository to all other site collections.
I do not advice you to copy and thus duplicate the information from your central repository to the other site collections. You'll lose precious disk space, performance and scalability.
If you have content that is created in a common site collection, you should either use the built-in web services or create dedicated ones to retrieve the content within the targeted site collections.
I usually create cross site collection look-up fields that allows a contributor to pick an entity from my central repository in a visual way and apply the rendering of the content once the page is in view mode.
That might not suit every need but I don't think content duplication is a wiser choice.
Edit : re-reading your question, is there a specific reason why you want to copy a complete site (spweb I guess) rather than specific content inside ?
I'm creating a custom master page for my SharePoint 2010 publishing site. There are images, css files and js files associated with this custom master page. Where should they be stored?
I'm using the SiteAssets library for now - is this a good choice?
Thanks.
Yeah that is a good choice, also make sure you Provision all these files using Feature, this way upate of Files becomes easier.
In my opinion, you should store everything under the site collection libraries, this way you get:
Easy recovery in the cases you need to re-install the server[s]
Versioning and permissions on resources
Separation of resources between site collection
Simple deployment between environments, as you do not need to copy the files manually or design and deploy a feature to do it for you
The preferred place is of course Style Library, this is what it is intended for.
If you are creating and deploying your files through code, you can also use the _layouts directory to store your files. This makes it simpler to share files between site collections. Visual Studio 2010 makes it really simple to add a reference to the Images folder and any files will then be deployed to the _layouts/Images URL.
The only advantage of this is that a site collection administrator cannot make changes to these files, only someone with access to the physical server. (Although this can also be a disadvantage if your logos or images are changing regularly).
I usually store them in _catalogs/masterpage/ORGNAME/...
You can refer this blog for actual implementation
http://markviky.blogspot.com/2010/11/sharepoint-2010-web-content-management.html
-Vighnesh Bendre
I am new to SharePoint development. We have created a base site template and have used that template to start new sites in other locations on the same server. This works fine but the newly created site seems to "flatten" the custom content types created in the original site. I would think there would be a way to keep the original content type inheritance intact to help support any necessary modifications on the new site. They can still make the modifications but they take longer because you have to visit each list individually. Does anyone know how to fix this or know a better way to approach this?
The problem you are having is the move from your original site collection to another. The site template does not store the complete definition of a site - only the differences from the underlying site definition. Move from one site collection to another and you lose the underlying site definition and run into problems such as the loss of your content types.
Site templates and site definitions are two separate customizations you can undertake. You need to make a decision based on your requirements as to which is best.
Site templates
Pro's:
Easy to create and reuse through the SharePoint interface
Ideal for end users
A site template is a customization of the underlying default site definition
Con's:
Dependency on underlying site definition means SharePoint updates could break your site templates
Poor performance since the modifications are held in the database and are read from the DB and compiled on each request
Limited customization options
Site definitions
Pro's:
Harder to create: involves coding XML
Made by developers and site administrators
Independent of SharePoint default site definitions so not affected by SharePoint updates
Limitless customization options
Con's:
Difficult to modify when deployed
Can be cached on the file system so is fast to load
Check out Google for info on creating custom site definitions.
Hope this helps!
Jonny
The best way to do this is to create a site definition where the content types are within features whose scope is to the farm.
Tim