I am working on teamsite that has Publish features enabled.
Is it necessary to have a .html file and then generate .master file out of it to be used for both publishing pages and site pages.
How to upload Starter PubCollab master file in the referenced link below. Does it need to be uploaded as HTML master page or ASP.NET master page.
https://startermasterpages.codeplex.com/releases/view/97062
Does ASP.NET master page is only for publishing pages but not for site pages?
I would like to have only .master file that can be applied to both publishing and site pages. Is it possible?
Master Pages should be stored in _catalogs/masterpage/Forms/AllItems.aspx It doesn't matter what content type you pick really, SharePoint does not enforce these content types when you are assigning the masterpage to a site, but using the correct one for the type of masterpage you are using is clearly the best choice.
As far as HTML vs ASP.NET, I have always done masterpages in ASP based on the default masterpages provided by Microsoft (v4.master, v5.master) since you know they best support all OOTB functionality and won't have any issues. ASP.NET works fine on all types of SharePoint pages and should look the same for Publishing, Team and System pages including settings pages. This has been true since 2010. I have always deployed my branding solutions via Solution WSP files, but that's not necessary either.
So to answer your last question, yes, yes you can. It's how I have always setup my site collections.
Related
by Default there are Themes, I don't Like those. How can I modify It completely and make a professional website. I have found same Questions on this blog but all for MOSS2007. I am working on Sharepoint 2010
The way I modify sharepoint, is as I do with almost every other CMS out there combined with the power of asp .Net (Remember that as CMS' go sharepoint is a poor solution if the only thing you want is a portal. Sharepoint is first and foremost a BI Solution).
When you edit your site in sharepoint designer (Site Action -> Edit in sharepoint designer) you can see a whole lot of options.
Here you can change the default masterpage to accomodate the look and feel of your site. You will do most of the hiding stuff here (those you don't want to be seen giving them the visibility=false attribute). Here you can also include a new CSS (place it in site assets) where you can override already existing css files.
From this point on, you will be able to add web pages to the site, that will conform to the masterpage, and thus you can use all the sharepoint power (web parts and even embedded html code) keeping the look and feel you have implemented on your master page.
So what you need to do is:
Modify master page in sharepoint designer
Add css files in site assets and include them in your masterpage
Add any other aspx pages or custom web parts that you will refer to in the sharepoint site
Create web pages with sharepoint assets, web parts or custom code
Enable anonymous access for the people you want to view your portal without authenticating (Bear in mind that there are some sharepoint controls that can only be viewed by logged in users)
There are multiple ways of customizing it.
My perfered way is CSS.
Add reference to a custom css in master page using feature
Modify the look and feel by modifying sharepoint out-of-box CSS
Following resources gives all the details of SharePoint 2010 css classes.
http://sp2010notes.wordpress.com/sharepoint-2010-css-chart/
http://sharepointexperience.com/csschart/csschart.html
I hope it helps.
Cheers.
Rajendra Shekhawat
There are two types of pages in sharepoint. Application and site pages. In site pages if we want to customize them, are we not able to use the server side code? If so why? I saw an article related to this in MSDN.
Generally what is meant by customized here. Adding a webpart through the code is customization? Please explain me any one.
Without a web.config modification (not recommended), Site Pages do not support server side code (either inline or in a code behind file). This is primarily for security and performance reasons. Unlike Application Pages, Site Pages can be added or modified in SharePoint Designer and, in a limited fashion, through the browser.
Normally, there are many more users with these privileges than those users that have access to the web server. I'll leave it to your imagination to consider some of the insecure or inefficient server side code some of these users could create.
In addition to custom web parts, see Where's the code-behind for sharepoint aspx pages? for server side code options within Site Pages.
When you're doing application page, you're storing the aspx with the 12 / 14 hive (SharePoint installation directory) and you're free to use any code behind class / component that you want to use. The original aspx file will stay in the physical folder of the Web Frond End
On the other side, when you're creating site pages, you're adding a new entry within the content database and not on the file system. Even if you have a site page template, you need to add safe entries to your web.config to trust the assemblies.
For the site pages, it is suggested to work with WebParts. They will allow you do do any business / core logic with the actual page, list, web, site.
When they talk about customization, they talk about modification done to the site pages that will alter the original definition. A site page provisioned through a web definition will stay "uncustomized" (ghosted) in the file system until it is being edited.
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 need to provision a custom aspx page which does some work and then redirects to another page. Using a _layouts page, AKA an application page won't work since I only want this page accessible to one site collection.
I looked at using pattern #4 from blog post Application Development on MOSS 2007 and WSS V3. It feels pretty hacky, and it asks you to drop the DLL. Drop it into the bin of the site collection, and upload the file through SP Designer.
I'd rather have this page be a feature that gets included in my site definition or stapled to an existing site definition. I imagine I could use a feature receiver to deploy the files to the pages SP list. One of the comments on the blog post says as much:
Pardon my ignorance on this maybe I am
missing the point completely but
wouldnt it be easier to deploy your
custom pages by programmatically
adding them to the pages splist?
I basically, had a simple .aspx page
with a user control. I deployed it via
this method.
How can a custom page be provisioned without using a _layouts page?
I guess another option is to keep using a _layouts page, but make sure the referrer is correct.
Besides application pages, you also have the possibility to create site pages.
Site pages are in nature related to application pages, but they reside in a site not in _LAYOUTS.
The welcome page (default.aspx) is an example of such a page.
In the same way as with application pages, it is possible to do codebehind in these pages (check out AC's article on this subject, Using ASP.NET 2.0 Code Behind Files in SharePoint v3 Sites)
You can read this article regarding the subtle differences between application pages and site pages: SharePoint Application and Site Pages - Part 1 of 2
You deploy this custom page using a feature, where you specify the file as ghostable (look at the example in ACs article).