Right. So if I was deploying multiple default and system masters I could define the top level site (plus inherited sites) to use one, and set the other to specific site instances?
Sweet. I imagine the order would be important, too, but I'll cross that flaming, rickety bridge when I get to it. From: [email protected] [mailto:[email protected]] On Behalf Of Jeremy Thake Sent: Wednesday, 25 February 2009 1:05 PM To: [email protected] Subject: RE: Overwrite existing elements with features Yes, if they are ghosted, they won't pick up the standard defined one. Changing the master page can be done via code. Plenty of examples of that on the web, something like below would do it: site.MasterUrl = MasterUrlPath; site.AlternateCssUrl = "/_layouts/1033/STYLES/Litware/LitwareBrand.css"; site.SiteLogoUrl = "/_layouts/images/Litware/LitwareFullLogo.png"; site.Update(); From: [email protected] [mailto:[email protected]] On Behalf Of Paul Noone Sent: Wednesday, February 25, 2009 10:56 AM To: [email protected] Subject: RE: Overwrite existing elements with features Thanks for the advice. Definitely sounds like the way to go. So if the pages have been ghosted then the production site collection would continue to use the master/layout pages stored in the DB even though identically named pages were deployed to the file structure via a feature? Is there a simple way to change this setting via code and add it to the solution file(s)? And how would this work for subsites that use their own custom masters?? From: [email protected] [mailto:[email protected]] On Behalf Of Jeremy Thake Sent: Wednesday, 25 February 2009 12:41 PM To: [email protected] Subject: RE: Overwrite existing elements with features I have done this approach at a customer in exactly the same scenario. There were no issues that I came across with deploying a Solution Package with Features which included Master Pages, Page Layouts, Content Types, Site Templates etc. that had the same GUIDs as already exist in the SharePoint Farm. I did use SPSource to reverse engineer what we were able to. The only hitch I can think of is if you have customized the master pages so they are stored in the content databases within the site collection. You'd would need to roll out the customizations to go back to the original master (that you are deploying) or write some code to switch the pages over to the newly deployed Master Page. Didn't have any issues with Content Types being redeployed using same IDs...be interested to hear others experiences with this? The benefits of moving to Development approach are enormous once all the plumbing is in place. From: [email protected] [mailto:[email protected]] On Behalf Of Paul Noone Sent: Wednesday, February 25, 2009 10:29 AM To: [email protected] Subject: Overwrite existing elements with features Hi all, Could I please ask what may be considered some exceedingly stupid questions? Scenario: Let's say that over time you made numerous customisations to a fairly mature and sizeable portal - from branding to content types, site templates to features - none of which were deployed as solutions. Let's ignore the reasons why. Realising the enormity of this error you would now like to turn all those customisations into sensibly grouped features (deployed as a single solution?) to the production farm. Questions: What are the implications of overwriting existing content in this way? Provided the same GUIDs are used is this a safe, sane, sensible thing to attempt? Would using SPSource to develop the solution files on the dev farm be the best way to start? Kind regards, Paul ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists -------------------------------------------------------------------------------- Support procedure: http://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists
