My team is trying to build out a Web Template which includes an instantiated Wiki Page with some default Web Parts added to it; but we're unable to get this behavior to happen.
In brief, we're looking to add some default.aspx (or Home.aspx, the name is unimportant, just the functionality) to the SitePages directory, GhostableInLibrary; so it's visible to all SiteCollections made from this Web Template.
It is of note that we're basing our Web Collection off the Team Site, and that the Wiki will be the default Home Page for the new site.
Site templates can be used to customize newly created sites except for the top site of a site collection. Since site templates are all managed in site collection's Solution gallary, so a site template CAN'T be used to define its own container.
You need a Site Definition to customize the first site of your site collection.
For how to use site template, you can goto, http://weblogs.asp.net/soever/archive/2009/10/19/sharepoint-2010-site-exporting-as-wsp-solution-part-1.aspx
For how to create a site definition, you can goto, http://msdn.microsoft.com/en-us/library/gg276356.aspx
If you want to strap onto an existing template without creating a new copy, or you don't have the original site template to access. You use a process called feature stapling.
When you create a sharepoint solution it would contain two features, one for your actual functionality and one that simple staples it to an existing template.
Here is an article discussing it some more. http://mssharepointtips.com/tip.asp?id=1065
Related
I am an experienced .NET Developer acting as interim SharePoint Developer, and am new to SharePoint. After determining that I need to go with an application page instead of a site page for a new project due to it's complexity and need of custom code behind. Before developing the entire solution, I wanted to tie up the loose ends of my understanding of application page deployments. I need to add this page as a URL on the left side of a Site Collection page (kind of like what happens when adding a subsite to a site page.) I have read about the modules, which seems extremely hacky to me. There must be a better way to develkop a custom page on top of SharePoint without the page being accessible to anyone on the entire site.
EDIT
The application I am wanting to develop on top of SharePoint exists purely for data entry and reporting purposes.
Have you considered using a Webpart?
With a visual webpart which is essencially a usercontrol wrapped in a webpart you can add as much complexity as you want and you also have code behind to hook to events etc.
The benefit of using a webpart is that you can then drop it on a page, and use all OOB sharepoint access controls.
You mention that you want to develop a data entry reporting app. So something you can do is to create a subsite. Look all access to modify pages except to owners. Create all your screens by adding pages to the subsite and dropping webparts on it with the logic you require for each screen.
Also make sure you deploy the werbparts via a web feature that only is activated in your subsite, this way the webparts are only available in that particular subsite.
I recently created a site in Sharepoint 2010, and I have saved it as a template. I'm able to apply this template to new sites, which is great. I can then add new data to each site individually. However, my problem is that if I want to change something on every child site, I would have to go through manually and do so. Is there any way that I can create a template that will work dynamically so that I can make changes to the original and all the child sites will inherit these changes?
Unfortunately not how you are requesting. When a site is created it uses a site template, including your own custom site template. Once a site has been created there is no way to reapply a site template to that existing site. You could use PowerShell to update a series of existing sites but the commands would get quite complex.
If you have deployed new site collections using a globally deployed template and you change that template using SharePoint designer, you should not have any issues and changes will be automatically applied to child sites unless you change master page.
I have around 9 web parts and 3 pages to be deployed. Each page will be having 3 webparts.
From a deploymnet perspective, i think i have the following two options:
Deploy the pages using a feature. The pages will have webparts present.
Create a custom site definition with a document library and have the three pages as part of the document library.
Can you please let me know which one of the options is better or is there any better solution?.
Please note that the solution needs to work on WSS 3.0 as well.
I would code the whole thing as a feature. You can staple it to the site definition for the site type you want it activated on.
If ever you need to migrate to the next version of SharePoint or another server it is easier to not have any custom site definitions. Also, the features leaves the site in a normal out-of-the box state; if you ever remove the feature nothing breaks.
Also, unlike the site definition it will also allow you to run it on sites that where created in the past.
First you need to deploy the webparts using WSP. Once it populated in webpart gallery you can copy the pages from page library and can paste in production.
During site creation using SharePoint, SharePoint offers some templates. If we need to create a site other than a template offered, how should we proceed?
You have 2 options:
Site Templates
Site Definitions
Many people use those terms interchangeably, but there are big differences between the two.
Site Templates
Site templates are easy to create. Basically, you create a site using a ite definition (e.g. the blank site) and start customizing it. You can add lists and libraries and setup the site however you want it. Then, go to Site Actions > Site Settings > Save site as template. You can save your site as a .STP file. The .STP file basically records everything that you added or changed on your site after site creation.
Once saved, your site template will show up in your site template gallery. You can go to the site template gallery and save the .STP file offline. Your new site template will be available in the subsite creation page in the "custom" tab. The template will only be availalbe in this site collection, unless you add the .STP file to the site template gallery of another site.
You can deploy site templates globally. So, if you want everyone to see a STP in their subsite creation page, you can run the following stsadm command:
stsadm -o addtemplate -filename BoardDirectors.stp -title "Board of Directors"
You can retract site templates whenever you want without affecting the sites that used them for creation. This makes them easy to version, as long as you don't want to push updates to existing sites.
One big problem with site templates is that you cannot staple features to them.
Site Definitions
Site definitions are collections of XML files deployed to the 12 hive. They are harder to develop; you basically have to use Visual Studio. The XML files have to be packaged into a SharePoint WSP and deployed using STSADM.
Creating a site definition gives you the most control over your site. Another benefit is that sites using the site definition will always reference the site definition's files, so updates will be recognized by sites using that site definition. For example, if you find a bug, you can fix it in one spot and all sites using that site definition will be fixed.
Note that withdrawing a site definition will break sites that use it.
Recently, many SharePoint experts have recommended staying away from creation new site definitions because of the overhead. Instead, if custom functionality is needed, they recommend coding custom features and just activating those features on sites.
Think about which option you need. In our organization, we chose not to create any new site definitions, and use site templates sparingly. Custom functionality is driven primarily by the use of features.
You are talking about custom "site definitions" and custom "site templates". Google those terms and you'll find tons of information.
You can design your own custom templates. Install VSeWSS extension for Visual Studio and it has a project type called "Blank Site" template. You can use it as a base starting point and customize the solution generated to your needs. All the information required to do so is available in the help document that comes with VSeWSS.
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