tsteele

Hi Folks, Here's the fix for folks trying to using Mike G's awesome new attributes with Register Globals off (it does not work). If you are using OSC MS 2.2 RC2 or OSC MS 2.2 RC2a (the most recent 2008 releases) from January 15 and January 30, 2008...Mike's new_attributes mod will not work. I spent a lot of time trying to debug and found a very simple fix that only took 7-8 hours to arrive at. I thought I would give a little back to the OSC community and post it in the new_attributes support thread. Here's the fix... 1. Back up your Admin area FIRST! 2. Make sure all files Backed-Up successfully. 3. Install New Attributes as per Mike's instruction...it is a very easy Contribution to install! 4. Open new_attributes.php in you text editor...I use Text Wrangler on a Mac. Do not use Word, instead use Notepad or your favorite editor on the PC. 5. Find the requires in new_attributes.php on line 5 and line 6: require('new_attributes_config.php'); require('includes/application_top.php'); Right after add: if (isset($_POST['current_product_id'])) { $current_product_id = $_POST['current_product_id']; } if (isset($_POST['action'])) { $action = $_POST['action']; } if (isset($_POST['optionValues'])) { $optionValues = $_POST['optionValues']; } if (isset($_POST['x'])) { $x = $_POST['x']; } if (isset($_POST['y'])) { $y = $_POST['y']; } if (isset($_POST['cPathID'])) { $cPathID = $_POST['cPathID']; } if (isset($_GET['current_product_id'])) { $current_product_id = $_GET['current_product_id']; } if (isset($_GET['action'])) { $action = $_GET['action']; } That's it your done! Save new_attributes to your server and enjoy! You do not need to install the Register Globals Patch as mentioned in previous posts. You do not need to add an .htaccess file or anything else. (although I tried both and they worked). The above is a very clean and effective solution, and it leaves Harald's most awesome OSC code untouched. I hope this saves someone else a few hours of time. Enjoy! -Tom

What happens in the sessions table if you are storing in MySQL? Would not the sessions table hold all sessions for 7 days? This would make the sessions table get huge on busy site. Can anyone comment on this?

Nice contribution...one that I felt was always needed in OSCommerce! One thing I noticed is that with the contribution installed, the cart does remain for the customer, but that when the customer returns again to the website the shopping cart shows it is empty (on the first page loaded) until the customer visits their cart. Is there a way to pull the cart info on the first click back into the site? It is a bit missleading... If we can figure out how to retrieve the cart on the first page loaded from the site...it would be better! Keep up the good work!!

Hey Jay, Thanks for your feedback! Here's what I have determined this week. The PWA checkout issue was related to a block of code in the checkout_success.php. The following starts at line 27 in my files: tep_redirect(tep_href_link(FILENAME_DEFAULT, $notify_string)); // Added a check for a Guest checkout and cleared the session - 030411 if (tep_session_is_registered('noaccount')) { tep_session_destroy(); tep_redirect(tep_href_link(FILENAME_DEFAULT, '', 'NONSSL')); } else { tep_redirect(tep_href_link(FILENAME_DEFAULT, $notify_string, 'SSL')); } As you can see the code above looks for the 'noaccount' var and then destroys the session. A bit further down at line 62 in my file: // PWA: Added a check for a Guest checkout and cleared the session - 030411 v0.71 if (tep_session_is_registered('noaccount')) { $order_update = array('purchased_without_account' => '1'); tep_db_perform(TABLE_ORDERS, $order_update, 'update', "orders_id = '".$orders['orders_id']."'"); tep_db_query("delete from " . TABLE_ADDRESS_BOOK . " where customers_id = '" . tep_db_input($customer_id) . "'"); tep_db_query("delete from " . TABLE_CUSTOMERS . " where customers_id = '" . tep_db_input($customer_id) . "'"); tep_db_query("delete from " . TABLE_CUSTOMERS_INFO . " where customers_info_id = '" . tep_db_input($customer_id) . "'"); tep_db_query("delete from " . TABLE_CUSTOMERS_BASKET . " where customers_id = '" . tep_db_input($customer_id) . "'"); tep_db_query("delete from " . TABLE_CUSTOMERS_BASKET_ATTRIBUTES . " where customers_id = '" . tep_db_input($customer_id) . "'"); tep_db_query("delete from " . TABLE_WHOS_ONLINE . " where customer_id = '" . tep_db_input($customer_id) . "'"); tep_session_destroy(); } This is where the PWA deletes all info about the customer. Since it was looking for the noaccoount var that was destroyes in the previous PWA code block, it did not delete the info from the DBs. So, when the PWA customer comes back a second time, their record still exists in the customers DB. Thereby creating major problems when OSC gets to the shipping screen. It sees a cutomer record in the DB and tries to retrieve a shipping address record that does not exisit. This was very hard to debug as it only occured on PWA customers that used exactly the same first name, last name and email on their second purchase from my site You may say what are the odds of that happening? Well pretty good with smart form technology in most browsers. All users of PWA should be certain that the cutomers info on a PWA checkout is really getting deleted, if it is not you will have major problems for those customers in the future. How do I find out if PWA data still exisits in the customer db? Sort your customer table on the PWA data field where 'purchase_without_account' = 1 Delete all matches Then make sure you have your checkout_success.php is correct! I have had several order since discovering the PWA issue and all orders have been perfect. I really hope this helps others as this was a killer bug to squash. Good selling, Tom Steele

Chris, Glad to help out! Definitely get the sessions and globals figured out first. For security reasons you will want to have globals off...from what I've read. Cheers, -Tom

Chris, For all links into the account area (my account) you need to add a condition to the link like: if (!tep_session_is_registered('noaccount')) { then show link } Whether it be in your header or on any other php file. That way only customers that are not using PWA (ie registered members) will see the my account link during chcekout. Hope this helps... -Tom

Hey toasty, You are right on with the PWA code problem there! Try the following: Checkout using PWA using First name: Test Last name: Customer email: [email protected] Make the address anything you want... Complete a transaction of anything in your store. Go all the way to checkout success. Quit browser. Go back to your store and checkout again using PWA and the same first, last and email. I'll bet when you get to the shipping screen the delivery address is blank! I believe that is becuse the PWA customer data still exists in the customer DB. Let me know what you find... -Tom

Hi Ed, Thanks for your efforts on this contribution, it a very useful tool! You are probably right that the 7200 second time frame is too long, but I want to have a snapshot that is a bit longer that the 900 second default. I will set all to 1800 and give that a try. Im also running using the user tracking contribution to look at user sessions and user paths in greater detail. It is a good analysis tool, but I tend to use your WOL mod more fequently for a quick peek at what is going on customer-wise on my site. Keep up the good work and thanks for your help!! -Tom Steele

I've got WOL 1.6 installed and working great. I'm having a small problem with the track_time variable. On my store I have the session duration set for 7200 seconds. I would like to track WOL for that same time period. I set the track_time var to 7200, yet it seems as though WOL is removing the data after about 10 mins. Am I missing something or is there a problem with the WOL track time feature? Thanks in advance, tsteele

I've identified an issue in the checkout process that is caused by users during the PWA checkout. Here is the scoop... After reviewing many user sessions, and oberserving how users interact with my site, I've found what is potentially a big issue affecting many OSC/PWA users. Some customers will have a browser running for days, much longer that the stock OSC 24 min session duration. Cookies set by OSC have a lifetime of the active browser session, meaning that until the customer quits their browser, the OSC session cookie is present client side. I've observed serveral instances where a customer comes into the site, places items in the cart, and then proceeds to checkout hours or even days later. When using PWA checkout, customers fill in the billing address info screen (1st one), then proceed to shipping screen and the session vars from the billing screen are normally added to the billing array. Next, we calculate shipping based on entries from the 1st PWA screen. Well, here's the problem... When PWA goes to write the customer data to the table...IT CAN NOT...SEESION INFO LOST. This is only only long sessions. It is very hard to identify unless you really are paying attention to how users are interacting with your site. Here's the other bummer, shipping fails because we can not do any calculations. This is happening on an average of about 1 in 4 checkouts. Have other OSC developers/users experienced this issue? I'll bet there are many out there... I think what we need is better session expiration handling. Has anyone made inroads with this? Any thoughts on how to resolve this? What about a pop-up screen that tells the user that their session has expired? I urge all users to take a very close look at PWA sessions, you may be loosing a lot of customers! This is a very important issue, as in today's market customers will have browser running for days if not weeks on end. Thanks in advance for your input... -tsteele