LookUpSectionID() & Add to Cart

[chivalry21]

Hi All,

This question has been posted many times over the years with no-one at Actinic or outside posting a solution (as yet) to the problem of SectionID (SID) lookups.

From the information I have found on this forum and from my own observations there is a PERL function in Cart.pm called LookUpSectionID().

There are also many references to $::g_InputHash{SID} within ShoppingCart.pl.

I have found the main dispatch routine that calls related add to cart subroutines at line 777 in ShoppingCart.pl which is fine. It appears that $::g_InputHash{SID} is called twice: in ProcessAddToCartCall() and in AddItemWithDefaultParams() with our setup.

We have tried with no avail to get ShoppingCart.pl to accept a blank SID InputHash and we are now asking for a little help/advice.

This doesn't work since there is no $::g_InputHash{"PRODREF"} when adding to the cart.

my ($nStatus, $sSID) = CART::LookUpSectionID(ACTINIC::GetPath(), $::g_InputHash{"PRODREF"});	# look it up
my ($Status, $Message, $sSectionBlobName) = ACTINIC::GetSectionBlobName($sSID); # retrieve the blob name

This didn't seem to work when we tried to extract the product reference from the .x and .y Inputs.

my ($key, $value);
while (($key, $value) = each %::g_InputHash)	# locate the product reference
	{
	if ($key =~ /(.+)\.([xy])$/ &&			# Looks like an image co-ordinate, but we must rule out
		 $key !~ /_/)								# product variants (handled below)
		{
		#
		# We have something that ends in .x or .y.  If both are present
		# we assume that this came from an IMAGE button
		#
		if($sImageButtonName)					# already found a .[xy] suffix?
			{
			if($sSuffix ne $2)					# and the suffix is different
				{
				$ProductRef = $sImageButtonName;	# use the de-suffixed name
				}
			}
		else											# first [xy] suffix
			{
			$sImageButtonName = $1;				# save the key without the suffix
			$sSuffix = $2;							# save the suffix
			}
		}
	}

Can anyone shed some light on how to use Cart::LookUpSectionID (passing it the Product Reference) if the SID isn't found in the input hash?

Perhaps someone has tried this already, or perhaps someone at Actinic can shed some light on this.

I have found the following threads that have similar questions with helpful pointers but no solutions:

http://community.actinic.com/showthr...tHash%7BSID%7D
http://community.actinic.com/showthr...tHash%7BSID%7D

Thanks in advance.

[NormanRouxel]

I used this successfully in my Add Items To Cart By Product Reference patch. A little form that customers can use to type in a product ref and directly add it to cart.

I recall that I copied the LookUpSectionID routine from Cart.pm into ShoppingCart.pl (no need to load a huge module) and renamed it.

As I was posting the Product Reference as part of my form submission, I didn't need to use one from the existing Actinic input hash.

However I'm pretty sure that the product ref is easily decoded. Watch out for Duplicates as they are of the form n!<prodref> and you need to strip the n! bit as Actinic only uses the main ref internally.

[chivalry21]

Hi Norman,

Thanks for the quick reply, just to confirm you copied

sub LookUpSectionID
	{
	my ($sPath, $sProdRef) = @_;						# get parameters
	
	my %Product;
	my $rFile = \*PRODUCTINDEX;
	my $sFilename = $sPath . "oldprod.fil";
	my ($status, $sError) = ACTINIC::InitIndex($sFilename, $rFile, $::g_nSearchIndexVersion);
	if ($status != $::SUCCESS)
		{
		ACTINIC::TerminalError($sError);
		}
	#
	# Do the product lookup
	#
	($status, $sError) = ACTINIC::ProductSearch($sProdRef, $rFile, $sFilename, \%Product);
	if ($status != $::SUCCESS)							# search engine error
		{
		ACTINIC::CleanupIndex($rFile);
		return ($::FAILURE, 0);							# report it
		}
	return ($::SUCCESS, $Product{SID});
	}

from Cart.pm and added it into ShoppingCart.pl and renamed the routine something like LookUpSectionID2 for example.

That would then allow you to use that routine within ShoppingCart.pl.

There seem to be two points where the $::g_InputHash{SID} is used: in ProcessAddToCartCall() and in AddItemWithDefaultParams()

the ProcessAddToCartCall sub seems to use it only to work out the CART_MODE so we could hard code that if necessary. I'm still a little vague on how to get the Product Reference though as $::g_InputHash{"PRODREF"} doesn't appear to work.

Any thoughts?

[chivalry21]

Hi,

I seem to have solved the issue of looking up some products when the SID is not defined, however this only seems to work for some products and not others.

You can find the site at http://www.charlottenaturals.co.uk/ I'd really appreciate any advice or pointers on why this issue is occuring.

Thanks
Andy

[NormanRouxel]

There's no sign of any way of calling your code on that page.

More detail of where to look would help.

PS the lookup routine is case sensitive and won't work on product duplicates.

[chivalry21]

Hi Norman,

Thanks for that you pointed me in the right direction.

I'm now checking for a gInputHash{SID} and if there is one use the default method and if not use the lookup method. It seems to be working on all products at present. Once I've finished this mod I'll post the results for others who might want to use this.

[chivalry21]

Hi Norman,

Why does the lookup routine not work on duplicates?

Andy

[chivalry21]

Also,

While testing with and without the SID the cart seems to add the same product on a different line.

So two products added as normal goes into the cart as you would expect with an incremented quantity, however if you then add a product with no SID displayed it will add the exact same product as a new line in the cart and subsequent products with no SID increment that line.

Strange.

[wjcampbe]

Not really. You are leaving part of the identification out - the product with and without the SID are NOT identical in data comparison terms, whilst by the same token multiple items without SID may easily be seen as repeats of the same product.

[NormanRouxel]

Why does the lookup routine not work on duplicates?

I wasn't being clear. The problem is in detecting the correct product reference if you're getting it from Actinic generated variables.

If you use an Actinic one (e.g. by examinimg the Q_<prodref> field) then this will be Q_1!<prodref> for the 1st duplicate, 2!<prodref> for the second, etc.

So whatever code you use to detect references would fail if it just looked for Q_<prodref>. You'd have to allow for (and strip) any n! at the start.

[chivalry21]

Hi Norman,

I've stipped the Q_! from all product references and still have a problem with certain products. The error message I'm getting is as follows:

Error: The specified product (reference 50) has just been removed from the catalog. Please return to the catalog and continue shopping. If you press the Refresh or Reload button on your browser, the removed products will no longer be visible in the catalog. We apologize for the inconvenience. 50 A0004.cat

The lookup seems to be a little off because the Section ID should be 5 and therefore the cat file should be A0005.cat. It's only happening on certain products, not just duplicates. All product references should be unique because they are being generated by Actinic (autonumber in access).

It's almost working ... but not quite.

[NormanRouxel]

I've no ideas regarding this. Sorry.

[chivalry21]

Hi Norman,

Thanks for all your help so far.

I'll keep working on it until I find a solution.

[Kermy]

Hi,

I'm replying to this thread rather than the similar one in Developers. I had a similar SID lookup function working, but I was always dealing with raw product IDs, never with duplicates. It was never extensively tested but seemed to work fine. Sorry I can't provide any more light for you on this.

Graham

[chivalry21]

Hi Kermy,

Thanks, I've re-posted this question in the developers forum.

I have got the lookup working for 75% of the products but somewhere along the line there are errors creeping in. I would like to know more about oldproduct.fil and why that's used in the lookup routine.