MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Arguments against using SPD 2007 to modify master pages

  Asked By: Lacy    Date: Jan 26    Category: MOSS    Views: 1862

We have a consultant working on doing light customization of our MOSS
environment (adding logo, changing colors, etc.). The consultant is
planning to use SharePoint Designer to modify default.master and point
to a new CSS file he is creating.

I have heard arguments against using SPD to modify master pages, but I
can't recall the specifics. I am remembering possible performance
problems and potential problems in the future when looking to upgrade.
I know "unghosting" is now referred to as "customizing", but is this a
potential problem?

Can anyone help me speak intelligently (tall order!) to our
consultant? I want to make sure we know all of the potential issues of
using SPD instead of visual studio to customize the design. The
consultant is following Microsoft recommendations, which I understand,
but I am concerned because of the problems I *think* I recall



24 Answers Found

Answer #1    Answered By: Kristie Hardy     Answered On: Jan 26

I would make sure that your consultant is creating a
new master  page and not customizing default.master or
any other built-in masterpage. If it's a "light
customization" then I'd copy default.master, rename
it, and modify  the newly created file.

Only SharePoint Designer will render a preview of your
masterpage as you modify it. For this reason, I
consider SPD an indisposable tool for this task and
would not discourage the consultant from using it
(unless his time is free). It can be used in
conjunction with any text editor such as Visual Studio
if he desires.

Answer #2    Answered By: Shayla Mcbride     Answered On: Jan 26

> Only SharePoint Designer will render a preview of your
> masterpage as you modify  it.

Provided you're not using 'new fangled' technology like CSS-P. In
which case, SPD is useless in that regard.

To answer the OP, my understanding is that the ghosting/unghosting
thing isn't really a concern in WSS3, though it was in WSS2 and
anything previously, as it DID create a performance issue.

In addition, if you truly need the masterpage modfied (short of adding
new colors, you probably do) Then SPD is really the way to go.

I imagine the other fear of SPD is the fact that given to internal
folks, they CAN really screw up a site, so in terms of granting access
to internal users, you'll want to make sure there are
training/knowledge aspects addressed first.

Answer #3    Answered By: Jarvis Rowe     Answered On: Jan 26

The rule of thumb I go by with SharePoint Designer is that you use it
for "one-off" scenarios. This holds true for design customizations as

If you have one site collection where you want to customize the look,
then I see nothing wrong with SharePoint Designer. If, on the other
hand, you want to incorporate standardized branding across many site
collections within a farm, then you are going to want to deploy a master
page using a feature.

I see un-ghosting as less of a problem with V3 and the advent of master
pages, because you don't really lock yourself in with future upgrades
like you did with V2.

Answer #4    Answered By: Christian Waters     Answered On: Jan 26

For this particular site, we are planning to have it be a single
site collection. However, if we see a future need, we may eventually
split out into multiple collections. The branding would be minor.

The consultant sounds like he plans to actually change
default.master (says he will customize the file and we could reset
to the default at any time- "no new master  page files will be

He says the OOTB master page (default.master) is in the master page
gallery which is already in the database, not the 12 hive. He said
he will not modify  any files in the 12 hive (against Microsoft
recommendations/unsupported). This doesn't seem to be what you guys
are saying.

This didn't sound right to me, but I'm not too familiar with
anything on the server/database side. Any additional clarification
would be appreciated (I need to know how to relate this info back to
the consultant).

Answer #5    Answered By: Virendar Bahudur     Answered On: Jan 26

Some of us (including myself) are saying that you
don't need to modify  the files in the 12 hive for this
project. Making your changes in the master  pages
gallery is sufficient, in my opinion. FYI, the master
page gallery contents are stored in the database.

I must still stress that your consultant make a copy
of default.master, rename it, and modify that copy.
It allows you to easily fall back default.master
should a problem arise with the customization.

Answer #6    Answered By: Sierra Beck     Answered On: Jan 26

So using SharePoint Designer to customize a *copy* of default.master
should be fine for what we are doing. And there are no (major)
concerns about future updates or upgrades. Is that essentially what
you are saying?

Sorry to be so ignorant here- this is far from my area of expertise,
if you hadn't noticed.

Answer #7    Answered By: Elisabeth Walsh     Answered On: Jan 26

Yes, that should be fine for your project. In
general, by copying an existing item and modifying the
copy, your customization will not be lost when service
packs are installed. This was a major issue in SPS

Answer #8    Answered By: Bhavesh Doshi     Answered On: Jan 26

While I agree that v3 service packs shouldn't be an issue, be aware that
you are creating a new master  Page. That, by definition, means that when
you upgrade to vNext that you will be responsible for alterations to
that master page. Not only alterations in the form of look and feel but
navigation as well. It is one thing to update that file if you have one
copy in the 12 Hive of each web front end (WFE) but it is a potentially
larger project if you must get the altered Master Page into the Master
Page Gallery in the database for every Site Collection it is used in.
That's why the questions about the scope of the solution. If contained
within a single Site Collection without the likelihood for growing into
many Site Collections and if you have publishing turned on or a custom
Site Definition you should be fine treating the custom Master Page as
content using SPD. Otherwise, it is better to treat the custom Master
Page as infrastructure and deploy it to the 12 Hive using a Feature.

Answer #9    Answered By: Elisa Santos     Answered On: Jan 26

I also just flipped through your
developer's guide and found the "caution" you wrote at the top of
page 128. That sounds like what I was originally concerned with. I
just couldn't quite articulate what I had remembered

I will provide this info to the consultant and see what they say.
Their recommendation may work for our environment, but I think they
need to be aware of these issues for any larger installs (like our
future intranet upgrade- this will certainly be an issue there)!

Answer #10    Answered By: Tatiana Houston     Answered On: Jan 26

If he is only working on the copy of default.master in the master  pages
gallery then he can always revert to the original with one click on the
context menu of the file. There is no need to make a copy and rename

Answer #11    Answered By: Arlene Hodge     Answered On: Jan 26

The builtin default.master is originally stored in the
global directory of the 12 hive. When you provision a site it is copied
(ghosted) to the master  pages gallery of the site. (ghosted means it
isn't physically copied, but a pointer is created in the content
database that points at the one in the 12 hive.) when he edits the
default.master in the master page gallery using SPD he severs the
connection with the copy in the 12 hive and stores a full copy in the
master page gallery. Changes made to the original in the 12 hive will
no longer have an effect. The customized one in the 12 hive can be used
for the entire site collection IF Publishing Infrastructure Feature is
turned on for the Site Collection and the edited copy is in the top
level site site collection.

The issue is scope. This master page will only be used for a single
site or site collection. Since you say this is a unique site collection
then it makes sense to directly edit this master page. That's what
others meant by "One Off'.

Hope that explains it.

Answer #12    Answered By: Jolene Sandoval     Answered On: Jan 26

I understand, but anytime you open and save a master  page using SPD,
it then takes it and saves it to the DB, No? If this is the case
does that have a cause for concern for future upgrades (possiblity
of overwriting master pages  back to the 12-hive and there being a
disconnect) in addition to a performance hit? Even for one-offs

Answer #13    Answered By: Brandan Roach     Answered On: Jan 26

I understand this to be Microsoft's recommendation (and a really good idea),
so that updates to built-in masterpages don't undo your customizations.

Do I understand that a "new master  page" will be in the file system, and not
in the database? In that case, there's no unghosting.

Answer #14    Answered By: Kai Carney     Answered On: Jan 26

I would place the new master  page into the database
(master pages  gallery). You can upload it manually or
deploy with a feature.

Answer #15    Answered By: Gaurav Nemane     Answered On: Jan 26

it does not take long to create a feature to deploy the new
master page. If you have a farm env., a feature is very convenient to
deploy files to the 12 hive of each WFE.

Answer #16    Answered By: Marjorie Humphrey     Answered On: Jan 26

Master pages  in the file system should NEVER be edited in SharePoint
Designer. You will break them. Customizing ghosted copies of built-in
files isn't a problem because you can always revert them to the

Answer #17    Answered By: Chelsey Watts     Answered On: Jan 26

Since SPD is working on an unghosted copy that you can revert to the
original there really is no danger with modifying default.master. Nor
is there any reason to copy it. The only reason to do that were if you
were working directly on the one in the 12 hive global directory and you
should never open a file directly from the 12 hive with SPD. You will
break the file if you do. Working on a "ghosted" copy is fine because
you can always revert to the original in the 12 hive.

Answer #18    Answered By: Nagesh Maulik     Answered On: Jan 26

It depends on how broadly you want the changes to take effect and
whether you have publishing enabled.

If publishing is not enabled then modifying the default.master using
SharePoint Designer will only affect one site, the site being edited.
If you are in the top level site and publishing Infrastructure Feature
is active then it can affect the whole site collection. It can't affect
more than that. This is because of "unghosting" the file to the
database. It's not the performace issue it was in 2003, but continues
to cause issues with maintainability in large environments.

However, you can use SharePoint Designer to edit the default.master,
then export it from the gallery to the file system, and use Features and
solutions to use it on the rest of the Farm. I normally use SharePoint
Designer to do the editing of master  pages and CSS files in a
development environment, but deploy them to the filing system (12 hive)
using Features and Solutions.

Answer #19    Answered By: Jonathan Scott     Answered On: Jan 26

So, is there any reason not to enable the publishing
feature? I don't think we were planning on it (it's just a site for
different groups to use for collaboration), but if it doesn't hurt
anything, I suppose we could.

I wasn't aware that work you do using SPD can eventually be deployed
across the farm. So you don't have to do the work in Visual Studio?
It can be done in SPD and exported to be used in Features and
Solutions? That is helpful!

So essentially I could edit a copy of the master  page (or even
create a new one based off of Heather Solomon's "clean" one) using
SPD, and give it to my IT Dept. to globally deploy it via
features/solutions? That would result in a completely ghosted,
updateable/upgradeable environment?

Whenever I hear that there's no harm because you can always roll
back (reset to site definition), I think, "Why even bother making
the changes in the first place, then? If I would eventually plan to
roll it back and lose my changes anyway." But if I can keep my SPD
work and use it globally, that changes everything.

So I guess SPD isn't so bad after all! ;) Am I understanding that

Answer #20    Answered By: Asia Meyers     Answered On: Jan 26

There are actually two publishing features, one at the site
collection level and one at the site level. Publishing Infrastructure,
the one at the site collection level is what adds the ability to inherit
master pages  from the top level master  page gallery of the site
collection. Publishing at the site level then adds a requirement to use
layout pages, approval, scheduling, etc. for publishing. Some people
turn on Publishing Infrastructure to gain the master page feature
without using Publishing on any site in the site collection. It doesn't
hurt anything, but the added infrastructure does add some additional
complexity that requires more training to use properly. For example,
once its turned on sites in the site collection can only see master
pages in the top level master page gallery, not in their own master page
gallery. As long as you understand that its not a problem. If you
don't it can make you crazy.

Answer #21    Answered By: Shelley Reese     Answered On: Jan 26

You didn't say anything inaccurate Kat. SPD _can_ be used as a powerful
tool when you understand how to use it properly. Unfortunately, most
people don't understand and use SPD to alter things directly in
production without regard to how it will affect their future. That's how
SPD has gotten such a bad reputation among developers.

Answer #22    Answered By: Omar Arnold     Answered On: Jan 26

Have I mentioned how much this discussion group

I promise to cautiously accept SPD and use it wisely (and NOT give
it to my users)!

Answer #23    Answered By: Christen Roberson     Answered On: Jan 26

I typically say that a WSS only developer should use SPD for four

1. Data Form Web Part
2. Workflow prototypes
3. Contributor Settings
4. Things you can't do in the browser

I still prefer to do my Master Pages in Visual Studio, but I can see
value in doing them in SPD and exporting the results.

Didn't find what you were looking for? Find more on Arguments against using SPD 2007 to modify master pages Or get search suggestion and latest updates.