Todd
Fri Jun 16 16:20:30 CDT 2006
There is one thing to look forward to, v3 removes a lot of the problems
associated with unghosted (or now 'customized') pages. For instance, you
can restore a site to the site definition from the site itself. I'm not
sure what level of permissions you need though. So feel good that MS is
listening and it will get better.
That being said, we allow FrontPage edits and see some problems with
unghosted pages (only pages can become unghosted, not sites). Performance
hasn't been one of them. We have a pretty beefy setup though. Unghosted
pages are slower because they require a trip to the database to download the
code whereas ghosted pages do not, they are on the file system of the web
server. Is your SQL server a decent box? Is it bogged down?
The problem with unghosted pages is a couple fold. First, the performance
issue we've talked about. Second is style. If you change your Site
Template, ghosted pages will reflect that page, unghosted pages will not
because they're in the database. Also, upgrades can be tricky if they
update the site definitions. Again, unghosted pages won't get the changes.
That's ghosting/unghosting in a nutshell. Hope it helps some. :)
tk
"Deb" <Deb@discussions.microsoft.com> wrote in message
news:D4B76AF8-5D5B-4EA9-8163-7309F132C799@microsoft.com...
> Bob:
>
> I read up on the ghosted vs. unghosted pages. To put it simply, this
> should
> be a HUGE concern of general users who use FrontPage to do simple things
> like
> I described; i.e., editing the QuickLaunch bar through FP. Or for things
> so
> basic as creating Web Part pages. I have observed a SIGNIFICIANT -- not
> negligible -- performance degradation in sites that have been edited in
> FrontPage. I'm not a developer and would never go in as far as making an
> unghosted page ghosted. I'm speaking from the perspective of an "out of
> the
> box" Sharepoint power user (IT Project Manager) who relies on it as a
> portal
> for project management. I routinely improve on the Sharepoint UI with
> creative uses of Content editor and Page Viewer Webparts. If the result
> of
> that is my sites are going to suffer in performance and it's a cancerous
> type
> of situation that grows worse with time, I'm very concerned about my
> growing
> reliance on Sharepoint. The bottom line is that if I have to place a call
> to
> our Help Desk to fix a site and there is any evidence that it's been
> edited
> in FrontPage, they pull our FrontPage rights.
>
> Just to clarify, I think I gathered from the articles, though, that
> FrontPage isn't necessarily the culprit. A Web Part page is considered
> "unghosted?" What I didn't see in the article I read is "so what?" So
> what
> if a page is unghosted? What's so wrong with that. I wonder if my answer
> isn't, your site will eventually convert from an extremely useful
> collaboration tool to a prohibitive hinderance.
>
> Deb
>
>
>
> "Bob Fox" wrote:
>
>> Deb,
>> This will probably not come out right so let me apologize right away...
>> no
>> offence is intended.
>>
>> Are you the same Deb that posted back on 6/8/2006 with the subject
>> FrontPage
>> Corrupting Sites? The solution to keep alterations to sites via FrontPage
>> is
>> valid. Also using a tool such as GhostHunter or ReGhost would fix your
>> slowness issues. It will also revert the pages back to there default
>> state.
>> There are numerous articles on the problems with UnGhosting pages in
>> Sharepoint and you are experiencing the main issue with this...
>> Performance
>> Degredation.
>>
>> How do I use Frontpage?
>> I do use Frontpage quite a bit. It seems no one is happy with the
>> default
>> themes that Sharepoint has available out of the box so I will use
>> Frontpage
>> to make custom themes. I will also use Frontpage to create DataView and
>> ListView webparts. That is the extent I would recomend. I have done in
>> the
>> past other things such as added Tabs and this did Unghost a page... I
>> have
>> also added links to sites and added headers inside the QuickLaunch area.
>> I
>> have called these templates :) and they were definitly only used for a
>> particular group in a particular situation ( Board of Trustees)
>>
>> Recomendations:
>> For starters I would recomend you google "Sharepoint Ghosted Pages" and
>> read
>> the various posts... I have one out there somewhere in the GoogleSphere.
>> I
>> would also look at setting up a Dev/Test server envrionment and if you
>> must
>> use Frontpage... use it on that box only. Its easy to move the changes
>> to a
>> production box via site template creation.
>>
>> Long winded I know. Let me know if i can be of further assistance.
>>
>>
>> --
>> Bob Fox
>> Web Site
http://bobfox.net
>> Blog Site
http://sharepointblogs.com/bobfox
>>
>>
>> "Deb" <Deb@discussions.microsoft.com> wrote in message
>> news:2257E2BB-00C1-48A0-9698-3D2965F52964@microsoft.com...
>> >I am in an environment with over 1000 Sharepoint sites. I routinely
>> >edit
>> >my
>> > sites in Frontpage. I've noticed that "some" of my sites are growing
>> > increasingly slower and slower to load. All of them have been edited
>> > in
>> > FrontPage (not code, just general UI stuff like the QuickLaunch bar).
>> > I
>> > had
>> > one last week finally die. It wouldn't go into Design mode and I could
>> > not
>> > open it in FrontPage. I now have another one starting to behave the
>> > same
>> > way.
>> >
>> > Does anyone know of why this would be happening? Is it related to
>> > FrontPage. Again, no structural changes are being made to the code via
>> > the
>> > Code view. All FrontPage edits are being done using the
>> > Sharepoint-specific
>> > UI that's in FrontPage.
>> >
>> > Thanks.
>>
>>
>>