persisting form data during checkout ...

Hello,

Not sure if this is the right forum category for this question, but others didn't seem to fit ...

I'd like to write an SQL query that is parameterized by the current "active" language, so that i retrieve product names in the correct language. I can't find where this information is stored (in the database) or made available in the code (generated constant).

Any help would be much appreciated,

Dan

p.s. if this is the wrong spot for the question, where do such questions belong?

Why?

zen_get_product_name($products_id) already does that.

In short -- its the learning curve :-)

btw, getting more and more into mod programming, I really would like to add those zencart idioms, as i learn them, to the wiki page ...

thanks.

Is there a function that given a category returns linked products? That's what i am basically coding right now.

To use for what purpose?

I am creating a checkout candy variant module -- that works a bit differently than the ones currently available. It's to support including one or more products during checkout that are then sent to charity. To support indicating which products should appear in the list i am asking the user to create a " charity" category and link products to that category. All active products so linked show up in the charity list during checkout.

Like this i can reuse the current user interface instead of creating a new user interface (and db tables), to indicate which products are eligible for charity.

So, this is related to stuff in 4 or 5 other threads you've got running already?

Yes, its the same store we are working on. And i wanted to give it a try and repackage/generalize/parameterize some hard coded functionality into a new community module.

You might consider zen_get_categories_products_list().

And it would be helpful if you kept related posts in one thread for continuity sake, as it helps ensure you get focused advice instead of being asked to explain the goal all over again each time. Also makes it more meaningful to future readers who might be looking for similar answers. And makes moderators' lives easier too.

ok.

I guess, i wasn't sure where coding questions go -- although they related to an add-on question asked earlier in the add-on topic area.

I hope this is the right sub forum to ask the following:

I have somewhat enhanced the checkout_shipping page with some checkout "candy" -- adding several input fields to purchase charity products during checkout. A problem i encountered is that when the user wants to change the delivery address, the user leaves the checkout shipping page by pressing the "Change Address" button, which takes the user to the checkout_shipping_address page. When returning from there, all data entered in the charity entry fields is of course gone.

To overcome this problem I registered (via page/checkout_shipping/on_load_main.js) a java script function that attaches a "save_charity_quantities" event handler to the page unload event. This event handler adds parameters to the destination URL (checkout_shipping_address page), which are then picked up by event routines in checkout_shipping_address and passed back, when the user returns to the checkout_shipping page, which then inserts them into the entry fields.

A better approach however, would be to use cookies and just store candy quantities in cookies and then retrieve them in the checkout_shipping page. However, this would force the need to use cookies. I understand that zenart typically uses cookies. But also works when cookies are disabled. Does zencart have utility functions to work with cookies -- which take care of situations when cookies are not enabled?

thanks,

Dan

Actually, Zen Cart doesn't use cookies for any of that data.
The only "cookie" ZC uses is the cookie PHP creates for the session ID, and in that respect ZC doesn't actually "use" or "create" the cookie at all ... PHP does.

The way Zen Cart persists data between pages is through session variables, many of which are actually objects which store and retrieve data from database records and aren't actually storing any session data in and of themselves at all.

You could set session variables for your needs. BUT remember, you're dealing with PERSONAL data when you start through checkout, and as such you start getting very close to things covered by PCI rules.
If you're even remotely considering applying similar persistance on the payments page like you've described for shipping page, you'll be dabbling directly smack in the middle of PCI stuff, and I would suggest you steer as far away from that as possible unless you intend to go fully into it and apply for PCI compliance. I doubt you're really interested in that sort of thing, so I suggest you don't even remotely consider persisting anything related to payments or card numbers or any other selections related to billing. Shipping is already sensitive simply because you're dealing with "identity".

Thank you for the detailed response, and alerting me to the privacy and compliance issues. Right now its really only the quantity of charity products that are made persistent.

I had though of making these persistent with placing them into $_Session, but wasn't able to learn how the session variable could be set from within java script.

I need to access the charity quantity values after the user presses a change address hyper link -- input fields are not carried over at that point in time, and the only mechanism i found that can access at this stage the values is a java script triggered from the window onunload event.

The other approach i guess could be to turn the hyperlinked change address button to a form with hidden input fields, whereby java script would ensure that those hidden input fields are set -- but then i would change core code in the template file -- something i wanted to avoid.

i now use cookies and it really simplifies matters -- localizing the peristence code to the checkout_shipping page, now i am having the opposite problem -- the cookies set in javascript don't seem to get reset in php -- so the values persist for too long :-)

thanks,

Dan

Hoping this question doesn't sound obtuse, but ... how is "charity selection" relevant to "shipping choices"?

Good question.

It is the design choice we took over, when we "inherited" that project. It is less so related to shipping but more so the first page during checkout. One could envision placing it later in the checkout process -- say just before committing to the order -- but the persistence problem, when, say, continuing shopping, and then returning to checkout would still exist.

Perhaps a better solution would be to have a charity page "squeezed" inbetween others during checkout -- but our client would't probably like the additional clicks it requires.

Your question does alert me to the fact that i need a more global solution -- i.e. not persistent between two pages -- but across one shopping experience. To avoid the need to have to re-enter charity selections/quatities. Cookies appear to fit the bill, so does i guess storing data in the session object -- which i guess also persists (for how long actually)?

thank you,

Dan

Why doesn't it belong on the shopping-cart page? It's essentially a choice with respect to what is included in the overall transaction. Couldn't that be a selection made at that point? The shopping-cart page is really the first step in the actual checkout flow.

Conceptually, its a last minute choice offered and made by the client -- an impulse buy. Although, i guess the shipping page is not "last minute". It surely worth investigating with the client. It does appears beneficial to have the choice on the cart page -- so that other choices -- that require persistence of data is reduced -- or altogether avoided.

Thinking about it more, i think there is no place in the zencart product selection and order workflow where a value entered in a field normally needs to persist on a form -- unless a client specifically wishes to update the value. So, what we are trying to accomplish adds additional complexity.

I have trouble deleting the cookies at the end of the order process. For some strange reason the setcookie('chesed_sz','',$pastdate); command executes successfully (returns true), but the cookie continues to live in IE with the original expiration date.

To go away from a cookie solution i found a coded approach, using ajax, that supports via an "RPC" call, to set session variables.

Essentially, i would be creating an rpc.php file that would receive the ajax call and set the session. Something like below (the actual rpc code is from the internet, not adapted yet to my need): I am however wondering whether i am introducing a serious security risk here. What code should rpc.php additionally include, and where should it reside, to avoid opening any security holes?

thank you,

Dan

rpc.php
switch($_REQUEST['action']) {
case 'charity1':
/* do something */
$_SESSION[charity1]= $+POST[var];
break;
...
}

function createRequestObject() {
var ro;
ro = (window.ActiveXObject) ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();

 return ro;

}

var http = createRequestObject();

function sndReq(action) {
http.open('get', 'rpc.php?action='+action);
http.onreadystatechange = handleResponse;
http.send(null);
}

function handleResponse() {
if(http.readyState == 4){
var response = http.responseText;
var update = new Array();

      if(response.indexOf('|') != -1) {
           update = response.split('|');
           document.getElementById(update[0]).innerHTML = update[1];
      }

Hello,

If i were two complete one purchase order, and then without quitting or login out start a second purchase order, would those two purchase orders share the same zenid -- the unique session identifier -- or would the second time arround a different unique zenid be generated? At the end of an order, when the shopping cart is dropped is this the time when the zenid is also destroyed?

If not, is there some identifier that is unique per each end-to-end order.

thanks,

Dan

The order number (id) is unique to each order. The session id is not reflected in any order records, so is irrelevant.