While creating a site SharePoint reads XML files for configuration.
And saves these configuration in database and does not read those xml
files again. If you have to change configuration for example some link
then you have to change it using front page.
Each team site refer a folder(site definition)containing aspx pages
which works as contianer for data. You can change these pages  for
desired look and feel.
But if you do so then all sites which uses this site definition will
see that effect. If you dont want this to happen then use front page
and modify that page.
This question is very typical all these things depend upon Situations
in which you want to use.

I already know all of this, I am not looking for answers on "how
sharepoint works" but rather peoples opinions. More like a poll.

Example, using front page  is bad  in my opinion or using front page is
good in my opinion (a reason why they think one way or the other
would also be nice).

front page  is bad  in my opinion. almost every "user" that has tried to frontpage a wss site in our org has ended up messing the site up so that it cannot be accessed, and the ones that do successfully edit with front page end up with style anomilies. not to mention that our database is quite large (22gb), taking a performance hit at the database isnt in our company's best interest.

i am most definitely from the school of function over form, means justifying ends etc.

I used FrontPage way back in the beginning before I knew any better and the sites that did with it are now rogue sites that need special care and feeding whenever we have mass changes. Since dumping FrontPage I have been able to do all customization work without it (except DVWP) and don’t miss it at all. I feel that the unghosting is not worth the reduction of time  to get tasks done.

We do use FrontPage to create DVWP in trash sites, then export out those STP files for use in our safe, ghosted sites.

Two things however, one, FrontPage is a perfectly acceptable tool for code editing, FrontPage itself is not the culprit, but how you open sites for editing in FrontPage is what causes the unghosting issues. Anyone can open the files directly from the web  server in FrontPage, make their edits and not unghost their site.

The other being that for small sites and specific needs in an environment where unghosting will not cause a problem, it is perfectly acceptable to do what you need to in order to get the job done. I think education is key, as long as people know what they are doing and the risks they are taking, they should go forth and conquer however they please.

In your post you mentioned that you would customize a site with FP and save it as template (.stp file). We follow the same process to create all our WSS sites as you described.
I have a doubt here. If I create a new WSS site, based on a already customized WSS site template using FrontPage , then, would my new site is unghosted or ghosted?

I also was questioning that recently as I have heard different opinions from various people. I have a page  that I customized with FrontPage that utilizes Tabs and such and alot of custom  work was done to the QuickLaunch area.... i took the page and created an STP file from this and loaded it onto an machine that I have ghosthunter installed to and the page is unghosted. So the upload frontpage customized templates theory is a bust.

I vote for FrontPage being BAD!



There are two reasons that drive my opinion:



1: The normal user , at least in a general sense, is not a programmer or html coder, and most likely has an entirely different focus in their area of expertise. SharePoint is merely a tool for them to use to make their job easier. Allowing them to edit the site in any ‘code changing’ form opens up a huge ‘oops, I messed something up’ can of worms, which potentially means added workload for the programmers and/or sys admins. The fact that someone wants a different color scheme (outside of the themes) or would like to remove something from the page  is not justification for potentially destroying some functionality in the site, or the entire site. This creates an additional management nightmare in a normally already stretched thin IT department.



2: The un-ghosting of a page means that I cannot globally affect these pages  anymore, as well as the ‘I want my site to look like theirs’ that is surely to come up in larger implementations but would not be possible without the addition of dedicated man hours (creating site definitions and templates can overcome this, but that implies the user comes to the IT department first – very rarely happens!).

I did a simple change to ‘all’ the sites on our 9 portals yesterday, and worked with only 3 files on each front-end web. Every page will be affected except any pages that have been edited and/or saved with FrontPage. As we do not recommend using FrontPage to our customers, and explicitly tell them that global changes will not affect their sites if they use FP, my job is done and I go on to the next item. If everyone used FP, I would be here until sometime next month working on changing the un-ghosted pages.

Now, I am not a developer, I am an user interface designer. That being said...

You don't actually "need" FrontPage to do anything in SharePoint other than use their data view webpart functionality, which I have found some people write their own tools for this just to avoid unghosting their pages. If you have a need for a WYSIWYG html editor you need something and it might as well be FP, but for SharePoint functionality development, FP gets in the way and slows things down. I would much rather develop web  parts when ever we can and avoid using anything that unghosts a page... maintenance of unghosted pages  is cumbersome and lengthy. Also when you upgrade or patch, there is a possibility that these files can corrupt and not work properly.

Will the next version of SharePoint have ghosting, un-ghosting issues when modifying sites using FrontPage?

My vote is that Unghosting is BADDD.

Again drawing from very limited experience, we set up a WSS site and let them use FrontPage to customize it. It ended up having to be scrapped because of all the 'anomolies' that occurred, and the difficulty in updating it.

Looks like Front page  and un-ghosting are pretty much un-popular with
everyone (except for a page here and there). Anyone think Front Page
is the bomb.......and un-ghosting is not a bad  thing?
To answer your question, Microsoft says the next version of
SharePoint (Office 12) will use a different editor and there won't be
a ghosting/un-ghosting problem. I will believe it when I see it.

Anyone who has put in serious time  on Sharepoint will tell FrontPage and un-ghosting are bad  ideas. All the more so if they are currently stuck with maintaining those sites.

Only place I would use FrontPage is for prototyping.

I found a nice posting about sharepoint  V3. Posted on : 9/18/05.
www.sharepointblogs.com/.../3503.aspx and I can't wait to see new SharePoint designer tool. I guess FrontPage is a bomb for data view web  parts only if you export the list as a template and later create a new list with the new list template.

From what I've heard and seen, it seems that FrontPage is going to become a dedicated SharePoint editing tool, and web  designers are going to be steered toward the new Express series of tools. FrontPage is supposed to be renamed and changed to be designed to work with and be aware of WSS/SPS.

That would make me "lol" in real life, because FP is HORRIBLE, to
take it rename it and say this is the new "tool" for designing SP
pages would be even more HORRIBLE.

Someone should develop something to create dataview webparts without
the need of FP, they'd really bank in the $$$.

Unghosted; even reghosted pages  bleed thru as unghosted in a custom  Web
Template. But this is not a FrontPage thing, it is a SharePoint thing.

For the last two years I've consistently said, g-g-g-ghosted is
g-g-g-good, unghosted is bad. Here's my rationale:
mindsharpblogs.com/.../626.aspx

I have just started at a company and their SharePoint guy uses Front
Page for everything. He creates a template via Front Page and then
applies it to every single WSS site (I almost passed out when I heard
this). I wanted some hard proof that this was a bad  thing to do, so it
wouldn't look like it was just the new guys opinion. With your blog I
now have that "proof" and I can just forward the link for everyone to
read.

Do you have anything or know anywhere I could get the "proof" that a
WSS site created with a Custom FP template is "unghosted" or will "bleed
through", as you say? I think this guy might try to argue the point,
that, WSS sites created with a Custom FP template are not "unghosted"
and won't "bleed though". I would love to have another blog or article
that proves that to be false.

I am currently putting together a document demonstrating two sites that I have put together.... one following the Frontpage path which is heavily unghosted ( company at first wanted the Frontpage look even after my objections) The second site is completely Ghosted following this mantra " As for me and my house, we will not unghost ".

I did borrow a few webparts that are floating around such as Bob Mixons Quicklaunch webpart (excellent i might add).

If anyone is interested in a copy of this please send me an email and I will forward it along with the screenshots after I have completed this.

I would be interested in learning more about this 'ghosting' business.

I am trying to catch up on how this affects the performance...

I would also be interested in a copy........

I have posted this document to my web  site. Because the doucment is large ( lots of screenshots) Email is probably not the best way.... you can find the doc at http://bobfox.net/spnj Enjoy.

Document even..... spellcheck rules!!

No, I said we do DVWP (Data view web  part) development in FrontPage, save it out then deploy on ghosted sites. I was not referring to the entire site as a whole. If you do that, those sites based off the template will be unghosted as well.

Proof is in the pudding... just unghost a site, save it out, redeploy
for a new site then make a change to the site definitions or something
and test for which sites listen to the changes (using a control ghosted
site as well).

Showing it is probably better than any article saying it.

Don't know why I'm entering this fray, but from an *Administrator's*
perspective, unghosting is something to be avoided in most cases.
However, unless you have a highly talented developer who can write code
that doesn't unghost the page, then unghost it IF you have a good
business reason for doing so. And FP03 is the tool of choice for
non-dev, non-IT people.

I'm not in the *never* unghost a page  camp, but I'm certainly not in the
*let's unghost all the time* camp either.