Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Default.aspx in SPS home directory doesn't reflect changes

  Asked By: Marlin    Date: Sep 21    Category: Sharepoint    Views: 4997

I am in the process of branding an sps portal using some of the techniques described here: msdn.microsoft.com/.../...PointHowToApplyBrand.asp, but any changes I make to default.aspx in <%SystemDrive%>\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\SPS\ are not reflected at all when I browse to the portal home page.

Here are all of my failed solutions:

1. Deleted all cookies, temp files, history from IE.

2. Recycled the app pool for the SPS portal in question.

3. Stopped/Started the SPS portal in question.

4. Rebooted the server that hosted the SPS portal I question.

In my consternation, I even renamed the actual default.aspx file in an attempt to cause the homepage to fail so I would get some indication that SPS looked for the file at all, but the homepage STILL displayed normally. WITHOUT default.aspx in the home directory.

Changes I’ve made to other default.aspx pages throughout the SPS directory structure actually do make a difference in the displayed page.

How can I change default.aspx in the home directory? Is it being saved on the database?

Share: 

 

18 Answers Found

 
Answer #1    Answered By: Gregg Wilkinson     Answered On: Sep 21

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.

 
Answer #2    Answered By: Darrel Sexton     Answered On: Sep 21

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?

 
Answer #3    Answered By: Tory Sellers     Answered On: Sep 21

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.

 
Answer #4    Answered By: Agustin Miranda     Answered On: Sep 21

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?

 
Answer #5    Answered By: Arron Middleton     Answered On: Sep 21

use vs.net and reference the magical dlls :)

 
Answer #6    Answered By: Tyron Calderon     Answered On: Sep 21

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.

 
Answer #7    Answered By: Stephon Valentine     Answered On: Sep 21

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.

 
Answer #8    Answered By: Leif Cardenas     Answered On: Sep 21

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.

 
Answer #9    Answered By: Jasper Hatfield     Answered On: Sep 21

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.

 
Answer #10    Answered By: Rashawn Hopper     Answered On: Sep 21

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.

 
Answer #11    Answered By: Horace Coffey     Answered On: Sep 21

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.

 
Answer #12    Answered By: Rigoberto Beard     Answered On: Sep 21

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

 
Answer #13    Answered By: Alphonso Mckay     Answered On: Sep 21

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.)

 
Answer #14    Answered By: Daron Oneill     Answered On: Sep 21

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.

 
Answer #15    Answered By: M Juarez     Answered On: Sep 21

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

 
Answer #16    Answered By: Marty Mcdowell     Answered On: Sep 21

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?

 
Answer #17    Answered By: Dakota Shaffer     Answered On: Sep 21

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.

 
Answer #18    Answered By: Ted Gilmore     Answered On: Sep 21

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…)

 
Didn't find what you were looking for? Find more on Default.aspx in SPS home directory doesn't reflect changes Or get search suggestion and latest updates.




Tagged: