Quote Originally Posted by BlessIsaacola View Post
Can you please tell me if this update is suppose to fix the issue where User Shopping Cart (when viewing user tracking) is the same across multiple visitors? Thanks!
Quote Originally Posted by mc12345678 View Post
While aware and familiar with the results of an item being in the cart causing visual chaos, I have not tackled that one yet. I realize that there is some incorrect logic that predates my changes to the plug-in, but if I remember correctly that area of the code is integrated with the area that does the logging of the visit, which is why I have put a bit of a precedence on squaring away the logging/capturing of data first. I once had a bot add something like 4 million dollars of items to it's cart and while looking at UT you could imagine my surprise that a single "user" wanted to buy that much from our little organization. Looked into it, and ah well just some computer adding stuff to the cart that it wasn't going to buy.

Anyways, as much as I would like to straighten the cart issue out, I need to stick with the plan to address capture of the data first which may lead to an easy fix on the cart issue.
So was thinking about the above thiss morning. I have a few ideas associated with it.
1) Sessions have a limited life. As such, UT as currently constructed is only setup to reoprt carts that are active.
2) Storing information related to all carts created would utilize more database capability which could be an issue forfor some users having a limited capacity. Enabling this capability would require an additional table in the database (to maintain correct table form) and also a control to prevent populating the table. Considering the default would be not to populate the table and that the table would be created in the code of usage rather than the install/upgrade sql.
3) Current carts are available through SQL inspection. UT apparently uses the version of cart identification similar to who's online in that it presents all current carts whenever/wherever cart information is displayed. At the point of display, there is sufficient information available to pull only the cart associated with that session. This information is currently not being used to provide just that cart info. Adding in the code to pull the current cart content for an active cart should be available from who's online with modification to apply only to the current session of the record being displayed.
4) Logic/display of cart information would need to consider gathering "all" info from 2 and current information of 3, but also take into account that on each page load the contents of the cart for the session being tracked such that as long as the cart's session is active the tracked cart is updated to reflect the current contents in both thetable of 2 and the active display of 3. Once the cart's session is inactive/has expired, then the data displayed identifies that this is basically an abandoned cart. This is not to take the place of any abandoned cart plugin, though may duplicate effort. This method would increase traffic withthe database, more so if option 2 above is active.
5) This may be possible to partially implement without correcting the tracking method of spiders/users as described above as it would affect only the display of session/cart information associated with existing variables and data that is readily available. Subsequent mod to address the tracking/identification of spiders may affect this area; however, that would just be part of updating the code to address any other changes/ensure continuity.

Ideas?