[ic] 4.7.3 __IMAGE_DIR__ Variable Problem...

[Stefan Hornburg Racke]

John Beima <jbeima@palb.com> writes:

> Wow was this ever a hard one to find...
> 
> Boy do you need a lot of ifs....
> 
> #01) UI must be in secure mode...
> #02) SSL must be a different domain...
> #03) Going into the UI https://www.domain2.com/cgi-bin/cat/admin/index works.
> #04) Going into the UI http://www.domain1.com/cgi-bin/cat/admin/index and
> letting the UI login screen hop you over to the SSL site causes this error...
> It looks like it is possibly in the new image tag...
> Actually just going back and doing step 03 fixes the problem...
> 
> The wierd thing is it is not session specific... Every visitor to the site from
> then on in gets the wrong IMAGE_DIR variable...

Very well spotted, John. Congratulations. Mangling Config stuff is
fine, because it is not persistent, but we shouldn't touch
Variables as it seems. Jon, why we need to set IMAGE_DIR in
UI_STD_HEAD ?

Variable UI_STD_INIT <<EOV
[perl]
	# determine catalog URL before mangling config URLs
	$Scratch->{ui_catalog_url} = $Tag->area('index');

	# replace ImageDir variables with UI equivalents to take advantage
	# of Interchange's automatic image path rewriting
	$Config->{ImageDirOriginal} = $Config->{ImageDir};
	$Config->{ImageDirSecureOriginal} = $Config->{ImageDirSecure};
	$Config->{ImageDir} = $Variable->{IMAGE_DIR} =
		$Tag->image( { ui => 1, secure => 0, dir_only => 1 } );
	$Config->{ImageDirSecure} =
		$Tag->image( { ui => 1, secure => 1, dir_only => 1 } );

	# force using secure URL for this page?
	if ($Tag->var('UI_SECURE', 2)) {
		$Config->{VendURL} = $Config->{SecureURL};
	}

	''
[/perl]
EOV

> 
> John
> 
> 
> 
> Quoting Jon Jensen <jon@redhat.com>:
> 
> > On Wed, 13 Jun 2001, John Beima wrote:
> > 
> > > Has anyone else found that fairly often the new 4.7.3 will overwrite
> > the
> > > __IMAGE_DIR__ variable with the contents of possibly
> > __UI_IMAGE_DIR__?? What
> > > mine winds up with is /interchange/en_US/ then breaking the link to
> > all
> > > images... This might also be a per session problem... However the only
> > thing
> > > that seems to solve it is logging in to the admin pages and going
> > "Apply
> > > Changes"... Then it will work for a short period of time again...
> > 
> > Perhaps some more details would help:
> > 
> > Are you using the same browser to access the storefront and the admin?
> > 
> > Do you have cookies enabled or disabled?
> > 
> > Does the problem happen if you never access the admin after starting
> > your
> > browser?
> > 
> > How many sessions from your IP address show up in the session list?
> > 
> > What pages have you visited in the admin?
> > 
> > I can understand how this could be bug, but it works fine for me. Even
> > when going back and forth between store and admin with the same session
> > ID, I don't have any trouble. Maybe your answers will shed more light.
> > 
> > Jon
> > 
> > _______________________________________________
> > Interchange-users mailing list
> > Interchange-users@lists.akopia.com
> > http://lists.akopia.com/mailman/listinfo/interchange-users
> > 
> 
> 
> 
> John Beima
> jbeima@palb.com, support@alocalagent.com, and support@alocalchurch.com
> 
> P.A.L.B. Systems - Phone: (780)451-1086 - Fax: (780)447-4760
> 11639-122 Street, Edmonton, Alberta, Canada, T5M 0B6
> 
> Affordable Web Pages - Phone: (888)932-9990 - Fax: (256)351-7297
> 2713B Spring Place SW, Decatur, Alabama, United States, 35603
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@lists.akopia.com
> http://lists.akopia.com/mailman/listinfo/interchange-users
> 
> 

-- 
Master of Swiss Web 2001: http://www.zweifel.ch/

For projects and other business stuff please refer to COBOLT NetServices
(URL: http://www.cobolt.net; Email: info@cobolt.net; Phone: 0041-1-3884400)