How to "un-defer" a basket?

[Kent Multer]

Most of you are probably familiar with my upload module, which lets customers upload an image or other file, and attach it to an item they're buying. I just found out that it doesn't work correctly when the store has turned on "Defer creation of empty baskets." The store doesn't create an entry in the Baskets table for the shopper until they actually put something in the basket. But my module operates before the Add-to-basket occurs, and it uses the basket ID to identify the uploaded file.

I've been studying the LSK, and it looks like I can fix my module by adding some code like this, just before the point where it needs to know the basket ID:

<MvIF EXPR="{ g.Basket:basket_id EQ 'provisional' }">
  <MvASSIGN NAME="l.xx" VALUE="{ [g.Module_Library_DB].Basket_Create(g.Basket) }">
</MvIF>

Can someone please confirm that I've understood this correctly?

Thanks --

[ids]

I don't know if this applies. The 9.13.02 version has a bug fix for provisioning and I think it might have something to do with this. Have you looked or tried this in the lastest streaming update?

Scott

[Scot - ScotsScripts.com]

I'm interested in knowing if that code fixes this issue because it's a problem in one or two of my modules (although the store admins had no problem turning off the basket defer thing which fixed the issue immediately.)

Hopefully Scott's info is correct and this recent update fixes this issue.

[dcarver]

You are probably looking for Basket_Register.

[Kent Multer]

Oh yeah, looks like it does what I just described. Thanks!

[Bruce - PhosphorMedia]

Most of you are probably familiar with my upload module, which lets customers upload an image or other file, and attach it to an item they're buying. I just found out that it doesn't work correctly when the store has turned on "Defer creation of empty baskets." The store doesn't create an entry in the Baskets table for the shopper until they actually put something in the basket. But my module operates before the Add-to-basket occurs, and it uses the basket ID to identify the uploaded file.

I've been studying the LSK, and it looks like I can fix my module by adding some code like this, just before the point where it needs to know the basket ID:

<MvIF EXPR="{ g.Basket:basket_id EQ 'provisional' }">
<MvASSIGN NAME="l.xx" VALUE="{ [g.Module_Library_DB].Basket_Create(g.Basket) }">
</MvIF>

Can someone please confirm that I've understood this correctly?

Thanks --

Yes, we found that with defer baskets turn on, miva doesn't set a static g.session_id (and its cookie). This also has implications for SMT code and module code that references g.session_id. I know in the past, a good deal of code relied on that value to track a VISITORS session.

[Scot - ScotsScripts.com]

DRCarver- would it be a good SOP to simply add the "Basket_Register" function to any module that needs g.session_id or g.basket? Would it cause any issues if the basket has already been registered for that session?

[Kent Multer]

Yes, we found that with defer baskets turn on, miva doesn't set a static g.session_id (and its cookie). This also has implications for SMT code and module code that references g.session_id. I know in the past, a good deal of code relied on that value to track a VISITORS session.

David, is this correct? From my look at the LSK, I thought that the session ID is always established, even if the basket is still provisional.

Thanks --

[ILoveHostasaurus]

I'm curious why there would be a scenario where you upload a file before any adding of a product to basket? Would it be a something like a store has an "upload your logo" option and then it shows up on every product that is customizable? The defer baskets feature can be a significant performance improvement in high traffic stores, or stores where an abnormally long basket timeout is being used intentionally. Undoing that behavior by forcing the store to go back to creating empty baskets for every entity browsing the site, including those that are not actual shoppers, would not be desirable. If there is no way around it, you may want to add a disclaimer about that.

[Kent Multer]

The upload works like any add-to-basket operation: you select all your options first, then click the Add To Cart button. When I wrote the module, the basket ID and session ID were always fixed by the time a module began running. (This was in 2006.)

In many cases, the problem is not the basket ID; it's the session ID, which changes with every page view until the basket is registered. As the above posts show, a number of modules are having problems as a result (including a couple more of mine).

"Upload Magic" only calls Basket_Register when it needs the basket to have a numeric ID. This only happens when the customer actually clicks a button to upload a file, or at least to start the upload process. There are no URLs on the pages that can trigger it to register a basket (unless search engines follow Javascript links that open pop-ups?).

If the module is installed correctly, this code will only be present on the PROD or PATR pages for products that actually uses uploads. The code doesn't get included on every PROD page in the store.

I do think about performance when I'm writing modules. I've slipped up a few times in 17 years; any time you report a performance problem with one of my modules, I fix it promptly.

Thanks --