I've asked a similar sort of question here but what to be more specific.
I want to be able to deploy a solution and activate a feature that provisions various custom aspx pages to different site levels within my web site.
So my first custom aspx page would be at the root: http://example.org/custompage1.aspx
And then another custom aspx page would appear at a deeper level: http://example.org/subsite1/custompage2.aspx
I've got my solution scoped to the "web" level. If I activate the feature at the sub site level I can access the custom aspx page that should appear at this deeper level, but, I can also access the other page that should only appear at the root of the web site e.g. http://example.org/subsite1/custompage1.aspx
Which is wrong, wrong, wrong!
I tried to scope the feature to “site” but this only seemed to provision the root custom aspx page, not the page that should appear at the deeper level of the web site.
"Custom aspx" pages are known in SharePoint as "Application" pages, and they are deployed in the _layouts directory (usually C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS). All pages inside the Layouts directory are available from every site in the web application.
If you know in advance which page goes with which site then you could put code in each custom page that checks to see if it's being accessed from an "invalid" site, and if so, throw a custom 404 error (see here: Hidden Features of ASP.NET) or something similar.
Anything you do in the feature xml will only apply to the site on which the feature is activated. If you want to do something across multiple sites based on relative urls, you will need to set up a feature receiver and use custom code to deploy files/features to the other sites.
The easiest approach is probably to create a seperate web scoped feature within your solution and have the site scoped feature receiver activate it on subsites.
Clorphil nailed the answer. I would only add that you can use SPContext.Current.Web within your page to determine which web site you are in when called.
Related
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.
I have two features that add CustomAction to the SiteSettings page. One feature is at the Site level and the other is at Web level.
The CustomAction that is being added at the Site level is a link to the custom configuration page that manipulates Site level settings for my application. Therefore, I don't want the link displayed for the SiteSettings page of a subsite. I know there is a setting (RequireSiteAdministrator) that hides the page according to access level, but I would still like to have this page show up for Site owners at the top/root level site settings page and not in the sub site level setting page.
There is a RootWebOnly attribute for the CustomAction xml node which would solve my problem. The problem with this attribute is that it only available for SandBoxed solutions.
I know that this is possible, since I see the behavior for the Site collection administrators link in the Users and Permissions section of the Site Settings page. Please notice that if you go to the top/root level settings page, you will see this link. On the other hand, if you navigate to the Site Settings page of a subsite, the link is no longer there.
I have tried using HideCustomAction, but this hides the link on both pages.
After battling with this for two day, I had an ah moment that I thought I would share. This will allow you to place a custom action that will show only at the root web level.
Create 2 features. One at the site level (siteFeature) and one at the web level (webFeature).
Make the web feature hidden so that it can't be accessed (activate/deactivate) though manage features page.
Put the custom actions element xml in the web feature.
In the activation event receiver of the site feature, activate the web feature.
UnfortunlyUnfortunately this is not possible with custom actions and custom group.
All you can do is just to set up permissions on the link that will be shown only to SiteCollection Administrator
Example how it will be is "Site Collection Administation" group where links are hidden when you are not on the top site level and shown when you are.
Hope it helps,
Andrew
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.
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
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).