The default.aspx page  for your portal  has been unghosted. Use the
GhostHunter Web Part in the Web Part Tool Kit on BlueDogLimited.com to
reghost it.

So, in order to avoid unghosting in SPS, is there a way to manipulate the default.aspx file  using frontpage (for us non-developers and those that do not have access to .net programmers) without unghosting the page?

To manipulate an instance of any Web Part Page, you can typically use
the Content Editor Web Part containing <style> and <script> tags to
influence the presentation of the page, often in profound ways. Give me
an example of what you are trying to do.

To manipulate the template that will effect all Web Part Pages based
upon it, you can edit the ASPX page  directly from the 60 hive. Use
whatever tool you want, including FrontPage. Just make sure to open the
page from the file  system rather than from the context of a specific
SharePoint site.

No really though, I have seen some issues with this and some advice would help:

1) When I edit in frontpage for an aspx  file in the 60 hive, it doesnt resovle many of the objects, so I end up coding directly in html, vbscript or CAML. This kind of defeats the WYSIWYG of frontpage as a development environment. Is there some set up I am missing?

2) I iisreset after changing the file. Most changes are reflected in the 'new' page  afterwards, oddly, some are not. What's with that so ya think?

use vs.net and reference the magical dlls :)

The quickest way to work around unghosting is …

Open the file  in FrontPage from the SharePoint site, make your modifications, do a Save As. Save it to your file system. Copy it into the appropriate template directory.

this makes some sense to me now. An example of what I am trying to do is hide items on the quick launch bar and top menu bar for those items that the user does not have permissions to. I don't necessarily want to delete the items, just maybe comment them out until we are ready to distribute these items to the public.

I know I can make them unavailable by changing permissions, but the CIO doesn't want them visible to the users yet.

I would say it this way...

The quickest way to work around unghosting is never open a production
page in FrontPage from the SharePoint site. Only manipulate the
direct-mode page  in the 60-hive on the Web server  or add a Content
Editor Web Part.

As far as I know, MS recommends Don't Change/ Modify the files  under \60 folder directly Or even Don't touch the file  system files. If You do so, The changes that you made  will be reflected in all the SPS Site which you will be creating. Also Backup and Restore Option will not work properly for all the sites.

1) You can still use the FrontPage WYSIWYG environment to edit the
direct-mode page. Just open it from the file  system on the Web server
rather then from the HTTP reference.

2) You shouldn't need an iisreset to see changes to the direct-mode
page. The pages  that do not reflect  your changes must be unghosted.

The problem with doing this is that it doesn’t actually run the web parts, etc. so you can’t get a complete view of what the page/template will look like. Obviously, there’s no chance of un-ghosting the page, however, many clients want to see what the final page  will look like.

Like so many Web-based solutions  that we've used for years, you can
simply:
1. Make a change
2. Save the page
3. View the page
4. Go to step #1

You can do anything you want with the 60 hive as long as it’s in a new definition – and that no sites have been created from it. (You can always delete the site you’ve already created.)

I use this alternative to unghosting:

Create a web part page  with just a single zone and put it into a scrap document library
Place any web parts on that page and crack that page open in FP to do whatever you want with it (say convert it into a DVWP)
Export the page from the browser when you’re done all your modifications
Import the DWP file  onto a normal site

Optionally you can delete the web part page you unghosted or the entire document library. I use it as a sandbox so I’m not munging with my production sites in real-time with anything that end users would see.

I too use this approach...................

I'm all for supporting Unghosting and Never touching the 60 hive pages  directly, but don't understand how you can do this for a Portal.

How would you go about changing the layout of a SharePoint Portal page  definition without editing the Microsoft direct-mode page itself? I'd love to add a custom folder with just my changes, but how would you get the Portal to use your custom pages as the default?

The main concern I can see with editing the direct-mode page itself is that your changes maybe broken with a future hotfix or service pack. If I am able to create my own custom page layouts, how will the SP/hotfix apply to my pages?

The direct-mode page  is a standard ASPX page that will easily convert
into a master page of the future. There may be some hand coding required
but only to a relatively few direct-mode pages  rather than every
instance of that page were it unghosted.

Start here … http://www.devx.com/dotnet/Article/27673/0 (Site Definitions: How to use them and why you need them.)

It’s written from the perspective of WSS but the same concepts apply to portal. (Look for WEBTEMPSPS.XML in the 60\TEMPLATE\1033\XML directory  to see…)