Posted: Tue Aug 15, 2006 6:18 am Post subject: SBI and Server-Side Includes (SSI and .SHTML)?
I was about to sign up with SBI, but I was told the most amazing thing that gave me serious pause. In fact, it was so amazing that I refuse to believe it unless others can coonfirm it?
I was told that SBI does not support SSI and .SHTML.
Please, someone, tell me that the person who told me this was mistakend. This has to be a mistake. In this day and age, it's beyond belief that a sane person might, in his wildest dreams, even speculate about the merest possibility that a major hosting company might not support the most time-saving device ever created for web site developers.
I am converting an old consulting site over to a content and marketing site. I expect to add new content almost daily and even more often, if possible. That means that my site-wide menus will change every day or even two or three times a day. I did a rough calculation and if I don't have access to SSI and I end up with 100+ pages on the site, it will cost me more than 10 hours a week, to keep the menus on all 100+ pages up-to-date and likely much more time. That will be more than twice the time that it takes to write and post the articles, in the first place.
Since I can't imagine any modern hosting company not supporting SSI, I really think that SBI will save me several hours a week. But, if this SSI thing is true, then SBI would, in all likelihood, end up costing me much more in time, than it saves. You can see why I am concerned. I can't sign up with SBI until this probable incorrect information is set to right.
Your source is 100% correct. With SBI, you won't have access to cgi, ftp, scripts, subdomains and subdirectories.
You'll need a traditional web host for what you have in mind.
Although SBI offers hosting, they're more of a suite of software for website building and marketing.
Hope this help... _________________ All the best,
Jarod
^^^^^^^^^^^^^^^^^
How to sell multiple digital products on multiple SBI sites with your own 2-tier affiliate program. Read the free report here: http://www.radicasolutions.com/sbi-ecom.html
Posted: Tue Aug 15, 2006 7:26 pm Post subject: SBI and Server-Side Includes (SSI and .SHTML)?
Quote:
Your source is 100% correct. With SBI, you won't have access to cgi, ftp, scripts, subdomains and subdirectories.
I think that because of the broad way I worded my question, you may have misunderstood my intent. I'm not talking about cgi, ftp, scripts, subdomains or even subdirectories.
In fact, I'm not interested in any of the fancy third-party programming magic that can be enabled through the use if SSI, if the hosting company chooses to do so. All that I am talking about is the most basic SHTML that requires NOTHING beyond what is included with the web server software. Similarly, although SSI files are often put in a subdirectory, they don't have to be in a subdirectory. In its most basic form, the SSI file is nothing more than plain old HTML that is inserted ("INCLUDED") into whatever file calls it, at the point of the "INCLUDE" statement.
Without access to basic SSI, if you have 100 pages on a site and you have a copyright date at the bottom of each page, then you will have to change all 100 pages every January. But with SSI, you simply include in each file, a line like:
Code:
<!--#include file="copyright.html" -->
Then, in the file "copyright.html", you have something that looks like this:
Code:
<p>?</p>
<p><font size="1">Copyright 2006 My Successful Company</font></p>
Then, each January, you change only one file. You can do the same thing with complex menus, too. Add one line to one HTML file and you have changed the menus on every page on your site.
That's it. No CGI. No Perl. No scripts. Just plain old SHTML.
That's why is surprises me so much, that any hosting company, especially a major player, like SBI, would even consider turning off such a VERY basic and hugely useful feature, even if they don't want to support the various scripting languages that might also make use of SSI.
In fact, not only does it speed up site-wide changes, but it reduces server load and speeds up loading of subsequent pages from the same site, since the included file is cached in most browsers. In other words, the things that are common to every page (not just images) do not have to be reloaded after the visitor hits your first page. Therefore, more speed and less server load. That alone, should be incentive enough for a hosting company to keep it enabled.
Although it's been a while since I installed a web server and I'm not 100% certain, I believe that the default for both Apache and IIS is now to have SHTML turned ON. That means that the hosting company would have to intentionally turn it OFF. What's wrong with this picture???...
It just doesn't make sense.
Again, let me emphasize that my question has NOTHING AT ALL to do with the advanced, add-on capabilities of SSI, such as scripting, cgi, php, ftp, asp, Perl or any of the other alphabet soup of add-ons. It's not some fancy web design magic that requires special software on the server.
I'm only interested in just PLAIN OLD SHTML that is built into every modern web server engine.
Does SBI support just the most basic implementation of SSI, employing nothing other than standard, SHTML that is part of every web server engine?
My first post on this subject was made at 1:18AM, so I was not thinking very clear and phrased my question too broadly. I hope that I made myself clear this time.
Actually, SBI does support SSI but a modified version of what you may see elsewhere on the web.
You create your SSI file for SBI using the following
<<include.shtml>>
(soon to be ***include.shtml*** as Frontpage likes to mutilate the double <<>>)
so your include file may be called
include.shtml (Must end in .shtml)
then in your html page you put the
<<include.shtml>>
code where you want the include to appear
your actual html pages will still have the .html extension and the includes will work fine
when you upload your html page, you are prompted to upload your .shtml files as well
if you make changes to your .shtml file, you can reupload just it via Quick ReUpload It and it will overwrite the old version
This is a recent addition to SBI; it just came out this year and I love it!
Debs _________________ Learn how to turn keyphrases into quality, well-targeted articles your visitors and SE's will love with Gary Antosh's new ebook "Web Content Made Easy!"
Thanks for the SSI update. I must have missed that one...
Hi John,
I reread your question again.
Correct me if I'm wrong, the reason you're asking this question is because you want to be able to update your menu easily should you have 100's of pages in the future, right?
In SBI, you can update your menu (aka navigation bar) by itself and the change will be reflected throughout your site. The same goes for your header and footer.
So, you won't even need SSI.
Hope this helps... _________________ All the best,
Jarod
^^^^^^^^^^^^^^^^^
How to sell multiple digital products on multiple SBI sites with your own 2-tier affiliate program. Read the free report here: http://www.radicasolutions.com/sbi-ecom.html
Posted: Wed Aug 16, 2006 9:59 am Post subject: Thanks
Thanks, folks.
Debs, it sounds like SBI implements SSI in exactly the opposite manner that most hosts do. Normally, the URL of the file that appears in the address bar, ends in ".shtml" and the URL of the INCLUDE file ends in ".html". Do I understand correctly that the only differences are that those two extensions are reversed and that the actuall call is different?
I can live with the call being different. But, it does make it difficult to test, on my system, with Dreamweaver, since Dreamweaver will parse a normal INCLUDE statement and display it in your browser and it won't understand that simple, "<<include.shtml>>". I'll have to generate the page, with a normal INCLUDE statement, for testing and then change the INCLUDE statement, before uploading, I suppose.
Jarod, it sounds like everything in SBI is using a database for generating the menu bar and other fixed features. If that is correct, I would think that it would affect the ability of the search engines to see those links, since most SE's don't play well with database driven links. This might explain why SBI takes the very unusual tack of submitting often to the SE's. By using SSI for my menus and other fixed features, all of my links are visible to all of the SE's and a new post usually appears in the major SE's within less than 24 hours.
Another reason why I am uncertain about using SBI's menus, is because I have not seen any SBI site that had multi-level, drop-down or fly-out menus, which is a necessity for a large content site. I'm obviously going to be starting small, but I want what I start with to be compatible with what I expect to end up with, so I don't have to change in mid-stream.
Also, I know that some SEO's will try to tell me that you can't put multi-level menus at the top or left side of your page, without adversely affecting your keywords and hurting your SE placement. That is not exactly true. In fact I am in the process of writing a book that will explain how to do that, without harming your SE placement and maybe even help it.
FYI, when I began designing web pages you had to hand code your HTML, the Internet was not public, but was available only to colleges, government and government contarctors (which I worked for) and was called DARPANET. I've seen many changes. Some were clear improvements and I was an early adopter. Others only appeared to be improvements and often carried with them, some serious caveats. They usually went away or quiclky morphed into something better. Yet others were a mixed bag and you have to be careful how you implement them.
Database driven sites fall into that last category. They speed up development, but at the expense of SE visibility, thus requiring you to submit every page on your site to the SE's, on a regular basis, which means that your newest pages often do not show up on the SE's for well over 24 hours after you submit the new page. That's because the SE's tend to crawl linked pages first and submitted pages last. Also, with the database scenario, your page only appears on the SE's that you submitted to. With plain links, every SE that has found any one of your pages can crawl your entire site.
I'm certainly not affraid to implement new stuff. In fact, I am always looking for newer and better ways to do things. but I have to have a good reason, related to functionality.
Joined: 09 Aug 2003 Posts: 1838 Location: Columbus, OH
Posted: Wed Aug 16, 2006 2:14 pm Post subject: Re: SBI and Server-Side Includes (SSI and .SHTML)?
I think SBI primarily limits their SSI abilities is because of security issues. Don't quote me on that, though.
GurusInc wrote:
In fact, not only does it speed up site-wide changes, but it reduces server load and speeds up loading of subsequent pages from the same site, since the included file is cached in most browsers. In other words, the things that are common to every page (not just images) do not have to be reloaded after the visitor hits your first page. Therefore, more speed and less server load. That alone, should be incentive enough for a hosting company to keep it enabled.
Actually, your logic is backwards here. Using any type of SSI actually forces the server to process the page rather than merely serve it up like a static HTML page. You can find exact specs out there interms of server load differences, but most of them agree that using SSI actually increase server load times.
And the browser doesn't cache the include file - it never sees it. A SHTML page with SSI and a HTML page are treated exactly the same by the browser, as the web server does the work behind the scenes before the page is ever delivered to the end user. The browser doesn't cache "things that are common to every page," it caches the whole page. Because I visited index.shtml and then visit anotherpage.shtml, if they have the same menus, headers, footers, etc. all included by SSIs, anotherpage.shtml will not load any quicker. The browser won't store the header, footer, etc. in separate files in the cache - it will store an entire copy of index.shtml in the cache that will only be referenced if I visit index.shtml again, not if I visit anotherpage.shtml.
I agree with the fact that SSI are easier to manage, but they do require more work by the server, not less. _________________ Robert
Instant Site Comments - Allow Visitors to Comment On Your Content! EbookNiches.com - 4 PLR Ebook Packages Each Month
Learn About DropShipping
Posted: Tue Aug 22, 2006 8:51 pm Post subject: SBI does support SSI and SHTML
Hi to all in this thread
My SBI site now has 88+ pages, which were built in DreamWeaver and uploaded to the SBI server. They all use lots of SHTML subpages, and are based on CSS.
The main reason I use SHTML pages is exactly that that you have already mentioned: the ease of change of all pages at once. For instance, in the beginning of all these pages you will see my picture, brought there through an SHTML add-on. Next, I'll replace the picture with a video introducing me and my medical astrology services (my site is about applying alternative medicine techniques to help women with gynecological problems), and I'll do it only once, by changing the corresponding SHTML file only.
Please note that if you go to a typical page such as
The database and dynamic urls you speak of are not a problem with SBI; SBI is all about static urls for pages; there are none of the ?/+ etc you commonly see in database urls. SBI sites do not have a problem getting indexed at all.
The database in SBI is a totally different animal than what you are thinking of for other sites.
SBI uses databases to manage all our pages, content, traffic reporting, rankings, monetizing, etc. behind the scenes (hundreds of things actually!); this way, we have a lot more data available to us to help improve our sites than standard sites do.
Debs _________________ Learn how to turn keyphrases into quality, well-targeted articles your visitors and SE's will love with Gary Antosh's new ebook "Web Content Made Easy!"
Last time I checked, SBI includes were "limited" to text and HTML as opposed to anything calculable server side.
In other words, SBI includes can't be used to write anything that depends on accessing server variables. This might or might not be important. It depends what you want to do.
For example...
You cannot use SBI includes to write content based on IP address of the visitor.
Can anyone confirm - can you use Javascript in SBI includes? (I'm supposed to know these things, but I've forgotten.)
Cheers,
Charlie. _________________ "Before I speak, I have something important to say."
- Groucho Marx
Last time I checked, SBI includes were "limited" to text and HTML as opposed to anything calculable server side.
...
Can anyone confirm - can you use Javascript in SBI includes? (I'm supposed to know these things, but I've forgotten.)
Cheers,
Charlie.
Thanks, Charlie.
This could be important to me, since I usually include Javascript in my dropdown or fly-out menus, which are almost always in an include file.
Although my menus always have an alternate version that will work if Javascript is not available, it makes navagation much more difficult (whole pages devoted to intervening menus and such). On one of my sites, I include a Javascript statistical clock on certain pages and that clock is pulled from an include file.
Therefore, if Javascript cannot be called in the include file, it would have the same effect as all of my visitors having Javascript turned off. My menus, copyright notices and other site-wide JS features would not work, without including them as discrete code, in each file, which would mean that every time I need to make site-wide changes, I would have to re-upload the entire site.
That would be a real bummer.
(BTW, they say that the memory is the second thing to go. I forget what the first is, though.) _________________ John
GurusInc.com
http://www.GurusInc.com/index.shtml
This could be important to me, since I usually include Javascript in my dropdown or fly-out menus, which are almost always in an include file.
Sounds like a job for The R Team...
(That secret army of Sitesell agents undergoing training as we speak. You'll know they're on the way when you hear the bugle. But I'm too scared to say anything positive about Sitesell right now in case I don't use the right wording, and get accidently ridden down, by the Forces of Conditional Good.)
Almost as seriously, I think JS will be OK but I'm just too scared to say so.
Quote:
(BTW, they say that the memory is the second thing to go. I forget what the first is, though.)
Me too. But if you're anything like me, it must have gone (whatever it was) so long ago that you've got a good excuse for not remembering what it was.
Keep your legs crossed,
Charlie. _________________ "Before I speak, I have something important to say."
- Groucho Marx
(That secret army of Sitesell agents undergoing training as we speak. You'll know they're on the way when you hear the bugle. But I'm too scared to say anything positive about Sitesell right now in case I don't use the right wording, and get accidently ridden down, by the Forces of Conditional Good.)
Almost as seriously, I think JS will be OK but I'm just too scared to say so.
I'm glad to see I'm not the only SBI user who the Response Team doesn't sit well with. Somehow a bunch of people who post the "official" response to any negative comments about SBI seems just as bad as people who post information with inaccuracies (or even just negative comments) in the first place.
Anyway, on the original topic of this thread, I use Javascript in my includes and it works fine. It's just a simple bookmark me script, but if it works I imagine something more complicated like cascading menus should work as well.
I'm glad to see I'm not the only SBI user who the Response Team doesn't sit well with.
Couldn't have put it better myself. I love the idea of encouraging people to stand up for what they use and love, but this is being handled badly. It risks achieving just the wrong result with any prospect with a brain.
In contrast, if I was running The R Team, this is pretty much how I'd go about it...
Oh heck, please tell me it isn't true.
Quote:
Anyway, on the original topic of this thread, I use Javascript in my includes and it works fine.
Thanks for the clarification.
Cheers,
Charlie.
P.S. Actually, between you and me, I'm beginning to think Ken realises this is a booboo. I'm just guessing. Time will tell.
The daftest thing of all is that everyone knows how many raving fans there are using SBI and how vocal they are. That's probably because it does what it says on the tin. _________________ "Before I speak, I have something important to say."
- Groucho Marx
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Your host: Allan Gardyne. Earning a good living from affiliate
programs since 1998.
FAQ
Search
Memberlist
Usergroups
Register
Profile
Private Messages
Log in
Oh heck, please tell me it isn't true. 