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?



Reply With Quote
