Forum Moderators: open
I asked this question a year or so ago when my site was at around 3,500 pages and the answer I got was that it could go much larger.
Now my site is approaching 10,000 pages with about half of them containing webbot includes, and it's becomming a major struggle just to get it published everytime I make changes.
It appears to me that the server times-out before the extensions complete their tasks right at the end of the publishing cycle. I know this has been a problem for FP before because there's a procedure that ISP's use to increase a certain setting ("max time-out", I think it's called) to give the server the max amount of time during publishing.
My ISP says they have it set to the max amount/value.
My FTP program resumes broken uploads, and only uploads what has changed since last time.
What would you lose if you transformed all the webbot MSFP include pages into straight SSIs? It's my rought grasp that the answer is "not much".
As I recall one of the selling points of the MS server extensions is that they track changes on pages. However, if the principal changes you are making attach to the MS include pages, that causes the server extensions to validate every page that has the MS code for include page. Takes time and processor cycles.
If they were straight SSIs, instead of MS include pages, then it's my understanding that there is no page checking process involved. Just change the 1 referenced file and the server just waits for the next call of the file. No checking.
My lacking in techno expertise analysis suggests that the benefits of the MS SEs are exhausted, and unnessary or counterproductive at a certain point.
I guess what I'm asking is what is the justification for continued reliance on the MS SEs once a website gets that big? I don't need to hear from MS FP bashers but from MS FP savvants.
What am I getting wrong here?
what is the justification for continued reliance on the MS SEs
Based on the exact question you've asked, there isn't.
I'm moving away from anything proprietary to FP2003 and using includes and other things. However, there is still the factor of getting things done FAST. I hand code a lot, but the WYSIWYG is so sweet for moving things faster in certain cases. (Thumnail? Right click, select, done. Copy a jpeg? Copy it from the web page, paste into the page. Done.) No-one can say they can do it quicker by hand-coding. It's a lie.
Getting back to the original question...If the site is getting quite large then perhaps a database is in order? But I haven't seen a limitation on any site size at this point.
and it's becomming a major struggle just to get it published everytime I make changes.
Whoa! You make changes then publish? That is something I don't do. I use a dummy directory for changes and then rename...all live. (I DOWNLOAD a backup of my website.)
There are a couple of advantages to using this approach:
1) It saves time in publishing, and you won't get false timeout errors after the pages are uploaded and FP tries to confirm the changes.
2) You can use different shared borders for different sections of your site.
BTW, I normally use ftp if I'm just uploading pages and image files, and I save the "Publish with FrontPage" routine for larger updates or global changes.
If you create a new folder via ftp it won't even show up on your side panel.
EFV - I thought that FTPing updates to a MS SE extended website would corrupt the MS server extension files used to track updates/changes. Am I wrong?
I've never encountered such a problem, and I've been using FrontPage since version 1.0 or 1.1 back in 1996.
I don't think you have to worry about corrupting the server extensions; the main reason for using the FP publish routine is to make sure that advanced features and global changes (such as changes to shared borders) work correctly. If you're just uploading some pages that you've revised (or even new pages that don't rely on automated FP features), ftp should work just fine.
