Publish Web Site Problem

[Bruce]

Using FrontPage 2003 publishing site from Local to Remote, When I click the
Publish Web Site button I get this message:

The server sent a response which frontpage could not parse.

I contacted the hosting Co. (Host Excellence) they said:

Thank you for your patience!
Our system administrators have investigated your issue and verified that
there are no problems from our side and everything is configured
correctly. Please check local Frontpage logs : wecerr.txt &/or FRONTPG.log
in windows TEMP folder to see if there are any errors since server logs
show no errors.

How do I check Please check local Frontpage logs?

 

[Ronx]

The logs, as stated by your host, are located in the Windows Temp
folder:
Open Windows Explorer or My Computer
In the address bar type:
%USERPROFILE%\Local Settings\Temp
And look for wecerr.txt and FrontPg.log
Both are text files that can be opened in Notepad, provided FrontPage is
not running.

The error " The server sent a response which frontpage could not parse."
usually occurs when the Publish operation is updating meta data on the
server, and is often (though not always) caused by the website being too
big for the server.

While there is no limit to the number of files., or total size of
website, that *FrontPage* can manage, some systems do have limits,
especially web servers that impose time limitations on processing web
requests. This will include the "Recalculate Hyperlinks" command (seen
as "Processing Web Updates") on the server that automatically follows
every publish. Some servers are overloaded with too many busy websites,
so do not have the spare resources required for processing web updates.
The problem may be overcome by publishing at a quieter time of day - 4AM
Sunday morning, perhaps?

If your host supports subwebs it may be a good idea to break the web
into subwebs, where each subweb can be published individually, and thus
considerably reduce the processing load on the server.

Note that since a subweb is an independent web, you will have to create
and apply navigation, themes, include files, shared borders, or DWTs for
each subweb.

 

[Bruce]

The site is very large about 12 GB, lots of mp3 files
We have all files that are already on the server set to (Don't publish) in
FrontPage, thus only publishing new updates.

Thanks,
Bruce

 

[Ronx]

Marking the files as "do not publish" does not exclude them from the web
updates procedure - one of the files marked *could* be used as an
include file, so every one has to be checked.
I suggest that the media files be placed into subwebs, (convert the
folders they are in to subwebs) so they are removed from the processing.
--
Ron Symonds - Microsoft MVP (FrontPage)
Reply only to group - emails will be deleted unread.

http://www.rxs-enterprises.org/fp

 

[Sid Saxon]

I have been following your conversation and using the subwebs is just what I
was thinking. You guys are great Ronx!
Following these user groups is a new thing for me. I have always done
everything the hard way by reading books and blogs etc.
Thanks for all the help that you MVP provide.
-Sid

 

[Randy]

I am having the same problem with another hosting company. My site
is 1.02GB and has 22942 files in 468 folders. I am curious about the number
of files

 

[Thomas A. Rowe]

You need to break your site into smaller sections by separating your content into subwebs / subsites
if allow by your web host is publishing to FPSE enabled server.

--
==============================================
Thomas A. Rowe
Microsoft MVP - FrontPage
http://www.Ecom-Data.com
==============================================

 

[Ronx]

The main limitations are the hardware your site is hosted on, and the
connection between your PC and the server.

While there is no limit to the number of files., or total size of
website, that *FrontPage* can manage, some systems do have limits,
especially web servers that impose time limitations on processing web
requests. This will include the "Recalculate Hyperlinks" command (seen
as "Processing Web Updates") on the server that automatically follows
every publish. A web of the size you have may be too big for the
server.
It would be a good idea to break the web into subwebs, where each subweb
can be published individually, and thus considerably reduce the
processing load on the server.

Note that since a subweb is an independent web, you will have to create
and apply navigation, themes, include files, shared borders, or DWTs for
each subweb.
--
Ron Symonds - Microsoft MVP (FrontPage)
Reply only to group - emails will be deleted unread.

http://www.rxs-enterprises.org/fp