Different My Site Themes on different SSP's - sharepoint

We are running MOSS 2007, with 4 different SSPs.
I want to change the theme that is applied to the mysites created on one of the SSPs. I plan to do this using feature stapling but how can I deploy this feature to just this specific mysite url as it only differs by port number.
Cheers

Isn't the feature Site / WebApplication scoped? That way you target only the web application / site-collection the feature is activated in...

Check out this link:
SharePoint+Features+-+Scope+of+Deployment
The web application deployment target is used as the destination for the following application scope resources which may appear in your solution manifest. These are physical changes to files within your web application (IIS web site).
ApplicationResourceFiles - Ex: MyFiles\My.resx. See the comment at the bottom of the solution manifest schema for some more detail.
Assemblies (if the DeploymentTarget is set to WebApplication) -> Ex: [web]\80\bin\MyAssembly.dll
CodeAccessSecurity - Changes to section in [web]\web.config to point to a new custom policy file in [12]\config
DWPFiles - .webpart and .dwp files for custom web parts
SafeControls - Additional entries in section in [web]\web.config.

Related

umbraco deployed as azure web app - content not showing on site

I've got an umbraco site which I deploy to an azure web app service. The data is on an azure sql database. I have been able to deploy this successfully, and can verify that all the data I expect to be there is present in the content view.
However I have added content on various pages, in rich text editors, and on my local site I can see this content on the site. But on my deployed site the content in rich text editors is only visible on the content view, not on the site. I've tried publishing each item but nothing will appear.
What else can I try?
Umbraco needs some additional configuration to be treated properly on Azure. It especially affects indexes and XML caching file.
Please check the following blog post made by one of the Umbraco HQ Core developers - Sebastiaan Janssen: https://cultiv.nl/blog/making-sure-your-umbraco-site-performs-on-azure/. Go step by step to ensure if your app is properly configured.
Going further you may be in need to also ensure proper configuration for load balancing, which you can find here: https://our.umbraco.org/documentation/getting-started/setup/server-setup/load-balancing/flexible
I found the answer after a much experimenting.
I had not manually included in my project (and thus not deploying) Views/Partials/Grid/fanoe.cshtml. This file includes the and I guess I was using some default template which is using this file, rather than the other grid templates in the same folder.

Create .master file without creating .html file in Teamsite in Sharepoint 2013

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.

Using deployed wsp solution in MOSS 2007

i have a bit of stupid question, but i'm really having trouble with it.
I have a wsp project which i have successfully added to MOSS 2007 using stsadm.exe and deployed it via sharepoint central administration. This has created a new folder in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\ with solution files, so my issue is how to use/create workspace using this solution. I have no new feature, site type etc. in my sharepoint. The solution had been created by another developer whom i cannot contact.
Deploying it through Central Admin isn't the same as activating the feature.
There are several scopes in which a feature could belong:
Web
Site
Web Application
Farm
Only solutions targeted to Web or Site can be activated within SharePoint UI. The others are done through Central Administration. On activation of the feature is when work is performed.
Site: Site Collection Features
Web: Site Features
If you want to see what's in the WSP, you can make a copy and change the extension to .CAB and browse the files. Any DLLs will be likely deployed to the GAC.* If you look at the other XML files you can see what's in them and guess where they are going. Chances are pretty big the feature is Site or Web scoped. If it contains a SharePoint Timer Job, it'll be either Web or Farm scoped but could be Site scoped as well.
The only thing that could be complicated is features can be marked as hidden. If this is the case, the feature won't show in the Site- or Site Collection Features area. Instead you'll have to activate using an STSADM command (activatefeature) passing the name or GUID along with the URL where you'd like the feature activated. You can find this info by opening the WSP and looking at the XML files within.
*Some DLLs might just be feature receivers - code that will run on Feature Activation or Deactivation to do some additional things through the OM.

Setting up default web parts on a Wiki Page from a Web Template in SharePoint 2010?

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

Building sites besides sharepoint site template

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.

Resources