1. Server Side Includes (SSI). Our site search will uncover lots of resources.
2. Global search and replace (many editors have this function)
I'd suggest not using FrontPage extensions. They can really hamper search engine spidering.
With Macromedia Dreamweaver you can create 'library items' of page elements that are used in multiple pages. When you decide to change such an item, Dreamweaver automatically updates all files that use that library item.
Tedster.. We have thought about using SSI, but have not becuase we thought 1. With SSI you have to rename the pages to shtml or someting like that, playing havoc with search engines listings for a while anyway and 2. It meant the browser has to parse the whole page before dispaying slowing down the time it takes to read anything on the page.
Is this still the case?
We are using PHP includes, still has problem (1) but it seems not to have to parse the whole page before displaying. (Correct?)
JS to an external file also sems a good solution, but can the robots parse there? We have used this for 2 or 3 years but are careful as we dont want too much js - again as we are not sure how SE robots handle them.
Global Search and Replace in the end in NoteTab is what we use the most. Potentially dangerous however if you dont make a backup first!
>I'd suggest not using FrontPage extensions. They can really hamper search engine spidering.
Actually, I use the FP "Include Page" function all the time and can see no ill effects whatsoever. If used wisely, some FP functions can prove to be very useful.
Further to the discussion above, our experiments with Movabletype have now moved on to managing a whole subsite of one site using that system. What an elegant and useful way of making websites! We are old time text editor type guys but have seen the potential and practicality of these systems.
They usually use scripts (mainly perl or php) to update pages on the server, however the resultant HTML/XML code is transparant to readers and Robots, unlike a system which uses databases on the fly or when requested from a browser. Make one change like adding a page, hit SUBMIT, and perl will update every affected page and edit them for you on the server, changing all your indexes, footers and headers, at one time.
Systems like MovableType, Greymatter plus others (which we rejected as they are still a bit unstable and surprisingly inflecible - PHP nuke, postnuke and the numerous clones), provide great ways to be able to update sites automatically.
|brotherhood of LAN|
Been making a 10 page site all day today from bare bones and this is pretty relevant to what ive been doing ;)
Following on from Tedsters tips I totally agree, and agree with Woz because I do the same thing - FPage Include Pages
Its divided into four bits,
1 The logo at the top and template
2 The 10 Page Navigation & Contact Info placed to the left of the pages
3 The main...and alias unique text on each page is in the main part of each screen
4 Navigation also at bottom, and address of company
Changes to 1 2 or 3 can all be done from the one page. So when Ive done doing that its just the content to go in the middle of pages
I said to the guy gimme 2 weeks to make it, but since the templates done its just a matter of filling in the blank spaces on each page :)
Since 3 out of 4 parts of the site are easily changed, you should check out your HTML and get rid of any that Frontpage makes, which has a habit of doing so if you dont know how it does each of your WYSIWYG commands. Right now the site is 60K in size for the 10 page site :)
After the text implementation, perhaps double. After a little database, double that again.
Well Im rambling a bit now ;) but ive put the URL of the site on my profile. I am in now way promoting it, but you can look at the source code and it should indicate how the include pages work! Nor am I promoting the company, just to be on the safe side.
Im just making the site for someone on a sub-URL of the site I run and making sure its A ok ;)
Hope that is of some use phillypleez
You can use SSI without those damn .shtml extensions by doing the following:
Copy the following text:
AddType text/html .html
AddHandler server-parsed .html
AddType text/html .htm
AddHandler server-parsed .htm
Then edit the .htaccess file in your root web directory (either in the following way or whatever is you favorite)
hit the i key
hit shift and insert to paste that 'AddType...' text in
Now you should be able to use SSI without the .shtml
Thanks very much physics..
Thanks for the info fellas, I think the frontpage includes seem like the easiest way to do this but I am really concerned about search engines. Tedster made a comment about problems with search engines... Is this for a fact?
I was referring to general reports on SE problems with all the FrontPage extensions. Those reports, plus some tedious jobs I've had resurrecting a few FP sites from SE oblivion make me very wary. I wiped those sites clean of ALL traces of Front Page, just to be safe.
So I have no direct data specifically on the Include function, in and of itself.
Both Woz and brotherhood_of_LAN report no problems with it, and that's a good recommendation for me. As long as the spider gets the "included" content nice and clean, then I'd assume that FP Includes can work out fine.
If you have Dreamweaver or UltraDev you may want to use templates and library items. There is a little code (Comment tags) added for the template, but it's not over the top like FP junk. :o)
|I think the frontpage includes seem like the easiest way to do this but I am really concerned about search engines. Tedster made a comment about problems with search engines... |
FP Includes do not require FP server extensions. They are more like SSI, but are done internally in FP prior to publishing. You can use them safely without worry of their effect on the SEs.
The FP generated junk that tedster had problems with was probably the result of someone using FP server extension dependent webbots. These include FP Themes and FP Navigation. It is best not to use these on your sites. The code generated is bloated and the cause of many people's complaints on this and other forums.
> FP Includes do not require FP server extensions. They are more like SSI, but are done internally in FP prior to publishing.
If I get this right, only your local copy will show the FP "Include tag" instead of the actual content. When FP publishes pages to the server, it inserts the actual code on every page where you've placed the Include tag.
So the final HTML is totally standard, just as if you had typed in everything yourself on every page. Only FP did the typing for you, giving you easier site maintenance and avoiding any server complications or overhead from SSI.
Now that's good to know. Thanks.
You nailed it tedster :)
The only residue you will see in the HTML from an FP Include is something like this:
<!--webbot bot="Include" U-Include="_private/include.html" TAG="BODY" startspan -->This toggles the FP WYSIWYG editor but doesn't invalidate your HTML like the other examples I mentioned.
<!--webbot bot="Include" endspan i-checksum="46091" -->
The limitation of the FP Includes compared to SSI is that the FP Includes can only be used between the <BODY> tags, not the header.</added>
I should have been more specific on that, thanks for clearing it up Bill.
The bad thing about FP includes is that they are done internally, meaning if you make a change to an included section you then need to upload every page affected by that change.
The good thing about FP includes is that they are done internally, meaning when the affected pages are uploaded they are pre-included thus requiring no server resources for includes thus giving faster page loads.
I like that idea.....
To take this one step further, edit the site live using the edit feature in IE and set your default editor as FP. No need to upload any pages at that point, make a change to any of your includes, save, and its a sitewide change.
You can make a backup afterwards to your local drive. I work backwards, making changes live, then backing them up to a local system.
The FP includes are 100% spider friendly and make site management a breeze. Its the FP Themes and Navigation features that generate the code bloat!