[ic] New to Interchange, trying to upgrade from a VERY old version

Scott Courtney cto at sca.org
Mon Dec 31 18:22:51 EST 2007

On Monday 31 December 2007 16:25, Jordan Adler wrote:
> Greetings fellow SCAdian,
> On Mon, December 31, 2007 14:55, Scott Courtney wrote:
> >   This is odd, because there is no mention of special_pages under the
> >   catalog tutorial.
> Yes, there is: 
> http://www.icdevgroup.org/doc/iccattut.html#special_pages/missing.html

Ah, I hadn't gotten there yet, but was taking the tuturial step-by-step. :-)
So this thing is equivalent to ErrorDocument in Apache. Got it, thanks!

> > * In my example setup, I can successfully bring up the catalog's main
> >   page with https://myserver.example.org/test.cgi but all the links from
> >   that page want to point to http://myserver.example.org/test.cgi. I
> > thought
> >   this was just a matter of setting SECURE_SERVER in variables.txt, and
> As I understand it, variables.txt is usually used to define runtime
> variables, for use in ITL.  See Variable and VariableDatabase config
> directives docs: 
> http://www.interchange.rtfm.info/icdocs/config/VariableDatabase.html
> But what you really need to do (probably) is set SecureURL:
> http://www.interchange.rtfm.info/icdocs/config/SecureURL.html

Found it! As it turns out, I needed to do the following:

1. Changed ENABLE_SECURE from 0 to 1.
2. Changed SECURE_SERVER (this I had already done, just documenting here)
3. Changed VendURL to also point to the SSL server. If you don't do this,
   then Interchange will do some things (like user account edit) in SSL
   but most catalog browsing remains insecure.
4. Removed the contents of $CATALOG_ROOT/tmp/ (but not the directory
   itself). This area was caching the generated menus.
5. Restart Interchange daemon.

After these changes, all the links appear to be SSL-enabled.

> Note, however, that links in the markup of your pages are totally
> dependent on how they are set-up.  In other words, if you have static
> links in your pages, you will need to change them by hand (to something
> less static, preferably).

The example store is well-behaved in this regard. Kudos to its developers.

> > * What do I need to clone over from the old server to make the page
> > layouts the same as we had before?
> You will suredly need to copy over any non-interchange static files.  CSS
> files, images, static html, flash files, etc.  See your apache (or $httpd)
> config for paths.

I'm going to try this with a clone of the test store, which is now completely
working (except for credit card processing, which I haven't yet tried to
set up because I'm not ready for that yet).

> >   I'd like to use /test/incex.cgi if possible, as a friendlier URL. My
> I'm not sure what the appropriate solution to this would be, but using
> mod_rewrite, at the very least, would work.

(Of course, I meant to type index.cgi not incex.cgi...)

This is a small issue. I'm happy just to have the sample store working for
now, so I can start trying to port the templates. I'll play with this later
if time permits.

> > * Is there any way to have the URL simply be https://mystore.example.org/
> This will likely need to be set up from apache (or the httpd you are
> using).  IC, afaik, does not handle anything before the request to its
> linker program.

I was just looking for a way to have $DOCUMENT_ROOT/index.cgi become
associated with a particular store, whereas by default it needs
$DOCUMENT_ROOT/$STORENAME.cgi instead. But again, this is a small issue
that can wait.

Thanks for the tips...at least now I'm making some progress forward!


()xxxx[]::::::::::::::::::>                   <::::::::::::::::::[]xxxx()

Scott Courtney, Chief Technology Officer, Society for Creative Anachronism
cto at sca.org                                           http://www.sca.org/

More information about the interchange-users mailing list