If you’re receiving this error when you Compile Components, chances are you have multiple websites on the same computer, and you’ve simply connected to the wrong one. Exit FrontPage or Dreamweaver, then start back up again and open your site. Run Compile Components again, and make sure you’re connecting to the correct site. The path should read http://localhost/SITENAME/ssl/management/clientaccess.aspx.
Category: StoreFront 6
Using An Alternate Stylesheet With StoreFront 6.x
StoreFront includes some client-side design tools which plug into FrontPage or Dreamweaver, and they’re not too bad (especially for beginners). One downside to these tools is that they completely rewrite the styles.css file each time you save your settings. Not so good if you’ve made some CSS changes. Instead of altering the styles.css, I recommend using an additional stylesheet. Remember that styles are cascaded—that is, if you specify the same class in two stylesheets, the browser will mash them together and use both sets of settings. If you specify the same element in both stylesheets, then the sheet which is listed last wins. This is excellent for us, because you can add settings to all the basic classes in styles.css, and you don’t have to worry about losing your settings if you still want to use StoreFront’s design tools.
To make sure our new stylesheet is added to every page, you need to add one line of code to the CWebPage.vb file and recompile your site. Open CWebPage.vb in FrontPage or Dreamweaver, and find the subroutine named PageHeader. Scroll down to the end of the subroutine (marked by ‘End Sub’, at roughly line 938). Add the following line of code right above End Sub:
response.write(“<link type=””text/css”” rel=””stylesheet”” href=””MyStyleSheet.css””></script>”)
You do need the double double-quotes where you see them, and remember to change the name of MyStyleSheet.css in the line of code. This line of code will add a stylesheet link to the end of the header of every page. Recompile your site using Compile Components on the StoreFront menu, and you’ll be good to go.
Now playing: Eddie Money – Gimme Some Water
Tweaking StoreFront 6 Page Layout
The design and layout of pages in StoreFront 6 can be somewhat controlled through their design and configuration tool. When the page is rendered, the values you set in the configuration tool overwite the defaults set at design time, generating the final layout.
As it turns out, the physical layout of the pages is controlled by two tables. One, named PageTable, is the outer table, and its defaults are not overwritten. PageTable contains a single row, with a single cell, no borders, 100% width. The inner table, PageSubTable, is the one whose settings are overwritten. Maybe there’s a good reason for this, or maybe LaGarde didn’t read the “Good HTML” chapter in their books. Whatever the reason, with some small tweaking, you can use PageTable to your advantage with more stylized layouts.
Rather than change the tag on every page, it would be nice to assign PageTable a CSS class, so we can control its appearance using stylesheets. Rather than edit each and every page, we can use FrontPage’s “search all pages” feature for the string ‘id=”PageTable”‘, and edit the tage ourselves. Unfortunately, not all the tags are the same, or we could just use the Replace feature as well. There’s less than 50 instances you’ll need to edit, so it’s not so horrible. Bare minimum, the TABLE tag should have an id attribute and class attrribute. After this, you can control its appearance through CSS.
If you want to tie PageTable’s appearance into the SF/FP configuration tool, you can skip the editing of each tag. Instead, open CWebPage.vb, and find the sub named SetDesign (around line 289 in my version). Several lines into this sub is the block of code which overwrites PageSubTable’s default values with the ones you set through the designer. Make a copy of this block, ad change PageSubTable to PageTable. This will apply the designer settings to PageTable. You can comment out PageSubTable (you really shouldn’t apply the settings to both tables, the results could be a little unexpected), or change it to suit your needs.
StoreFront 6: The Annoying TopSubBanner, and How To Fix It
Don’t let anyone ever tell you LaGarde’s StoreFront produces clean HTML. Far from it! Most modern browsers will work around the duplicated attributes, missing tags and non-compliant HTML. But, if your site is targeted to users who may be using assistive devices, you or your technical staff have a lot of cleanup work ahead of you. Additionally, some of this non-compliant HTML affects your design in very annoying ways.
One problem StoreFront has is with the TopSubBanner. To start with, it’s named TopBar in the configuration tool, but the files are named TopSubBanner, and the documentation refers to TopSubBanner. Maybe they’ll invest in a proofreader for version 7.
The display of TopSubBanner is controlled by a checkbox in the configuration tool. This checkbox determines whether or not the contents of TopSubBanner.ascx are displayed. So far, so good, right? So much you know.
The display of the control is actually handled by setting the visibility of the table cell. The control is still loaded and processed (a waste of time and CPU cycles), but visibility is controlled at the HTML level. You can see in this snippet below:
<tr>
<td class=”TopSubBanner” id=”TopSubBannerCell” width=”100%” colSpan=”3″>
<!– Top Sub Banner Start –>
<uc1:topsubbanner id=”TopSubBanner1″ runat=”server”></uc1:topsubbanner>
<!– Top Sub Banner End –>
</td>
</tr>
<tr>
If you choose to display TopSubBanner (or TopBar), this is all well and good. However, if you turn off the display, when your page is rendered, the final HTML is thus:
<tr>
</tr>
An empty pair of TR tags. Not compliant at all! The effect differs with the browser. In some older browsers (and don’t think people aren’t still using them) this will throw your page layout way off. IE will compensate by inserting the missing TD tags, leaving you with a blank row (1 px in height, unless you’ve added additional padding or spacing or such)–see below.
FireFox ignores the tags, which in this case is a better way to handle it.
There are a couple fixes, but unfortunately you will have to make these changes on every page. One simple solution, if you won’t be using the TopSubBanner at all, is to turn off the visibility of the TR tags with a simple HTML modification:
<tr runat=”server” visible=”false”>
<td class=”TopSubBanner” id=”TopSubBannerCell” width=”100%” colSpan=”3″>
<!– Top Sub Banner Start –>
<uc1:topsubbanner id=”TopSubBanner1″ runat=”server”></uc1:topsubbanner>
<!– Top Sub Banner End –>
</td>
</tr>
This will prevent the blank TR tags from showing, and correct the IE rendering of the code. Another fix that will allow toggling of the TopSubBanner with proper display is a little more involved. This might be overkill on a single site, but for developers with the XE version, you might want to update the source files which are copied when a new store is created (be sure to keep backups).
First, give the TR tags an ID attribute:
<tr id=”TopSubBannerRow”>
Then, open the file CWebPage.vb, and do a find for TopSubBannerCell. The first entry (around line 327 in my version) is what sets the visibility of the table cell. Inside the If…Then block, add the following code:
dim TempRow as HtmlTableRow
TempRow = CType(PageSubTable.FindControl(“TopSubBannerRow”), HtmlTableRow)
TempRow.Visible = False
TempRow = Nothing
Compile the code and load your page. The page should display properly, and if the TopSubBanner is set to not display, you should not have an empty set of TR tags. All you need to do from here is give every TR tag which contains the TopSubBannerCell the same ID (FrontPage’s Find command can be used to search all files for TopSubBannerCell, which makes ife easier). When done, compile and you should be good to go.
I’m not sure who’s supposed to check this (if anyone), but this never should have left the farm.
StoreFront 6 Error: “Database does not exist”
If you’re setting up a new store through LaGarde’s wizard in FrontPage, and you get a “Database does not exist error”, check the user ID and password if you’re positive the database exists. “Database does not exist” is a generic error message-StoreFront doesn’t tell you if your credentials are wrong, or if the server is stopped, etc.
Developing Locally with LaGarde’s StoreFront 6.x
I’ve used LaGarde’s StoreFront product for years, and currently have a number of websites running it. Although it’s been out for a few years, I’ve started upgrading them this year from SF 5 to SF 6. There were serious issues in the early versions that I wanted LaGarde to resolve before I subjected my customers to their bad coding (which is a topic for another post).
StoreFront’s manuals suck. Really bad. Information is spread out in on-line tutorials, the printed manual, and a downloadable CHM. Some of this information contradicts the other sources. Some information is totally missing. Like anyone with a clue, I develop locally. StoreFront 6 does allow you to do this, but it’s not documented well.
For my local database, I use SQL Server 2000 Developer Edition, which for all intents and purposes is SQL Server 2000 Standard Edition with a licensing restriction. LaGarde’s connections use SQL Authentication, so if you’re used to having a trusted connection, get out of that habit. This means you’ll need to create a SQL Server user that has DBO role for your StoreFront DB, and it doesn’t hurt to make its server role be system admin. Use 127.0.0.1 as the address for your server, and the user you just created for the user. The database name you ought to know by this point.
In order to connect LaGarde’s client tool to your database, you need to make some IIS configuration changes. Open the IIS management panel, and drill down to your SSL folder. Right-click on the SSL folder, and open the Properties. Go to the Directory Security tab, turn off Allow Anonymous, and enable both Basic and Windows Integrated.
You’ll also need a username and password for a user that can access this folder. You can create users through the Control Panel. The user only needs to be a Limited Account, but it does need a password. In FrontPage, when you open the StoreFront configuration tool, you’ll be prompted for the URL of clientaccess.aspx (usually Posted on Categories StoreFront 6