Quote Originally Posted by Dave224 View Post
This post picks up following the discussion of "How to control extra_cart_actions file loading order" in the General Questions forum.

The offer for mc... to add a notifier in the includes/extra_cart_actions/stock_by_attributes.php file would most likely solve my problem, but I'm not sure it's the best solution. If a notifier is added, it should be at the start of the file.

I need to bring up a form and process the customer's responses to the form when a certain product with attributes is added to the shopping cart. So my extra_cart_actions file detects the product being added to the cart, saves the $_POST variables (because $_POST data is lost on redirect), and redirects to files that display the form and when the form is submitted, processes the responses. For reasons that escape me at the moment, the $_POST variables are not restored until the extra_cart_actions file is executed again later in the add product to cart process. When I developed this code, SBA did not have an extra_cart_action file, so the missing $_POST data was not missed by other extra_cart_actions files. But now, SBA has a file there, and it runs before my file, and it doesn't like missing $_POST data. I get a undefined index products_id notice on or about lines 372, 492, and 513.

So while a notifier in SBA could trigger an observer that restores the $_POST data if not present, I think a better solution is to try and display the form, process the results, and restore $_POST (if necessary) all at once, instead of over two cycles through extra_cart_actions. I'm not sure I can accomplish that but that's what I'm going to try.

Dave
So, one way I could see this working is actually through script detection on the product page such that if the conditions to show the form exist, pressing the add-to-cart button would trigger your alternate form (along with capturing the existing $_POST and related data) which then upon submission would push all of the data forwards to the shopping cart... But... This relies heavily on the visitor *not* having disabled javascript/jQuery.

So, looking through the standard ZC code some more for the shopping_cart class, there appear to be notifiers within the add_cart method both relatively early in its execution and also further downstream when exiting the function and then there are multiple notifiers throughout the operation...

Yes, $_POST data is lost on any new/subsequent page load. To "pass it along" the previously received $_POST data can be captured (session wise or stored on a page that is then/again $_POSTed) and a method (probably complicated) could be used to withdraw $_POST data to prevent some level of operation and then later restore it back in follow-on processing...

I may ask, why can the data not be collected after the item(s) have been added or in some other "series/sequence" (asking to possibly identify other solutions, not that the one proposed is necessarily an issue)? Such as when displaying the shopping_cart page (store setup has the option to "stay" on the product page upon adding the item to the cart or to go to the shopping_cart) or when moving away from the shopping_cart page to the checkout process... Again, only exploring other alternatives/areas of flexibility... From my side, it's not difficult to add a notifier towards the top of the file (likely would add one at the bottom as well)... It does make me question if the operation in the extra_cart_actions file shouldn't just be put into an observer; however, I would suspect that the same issue of file load sequence would occur there as well if two or more observers were listening to the same notifier and loaded with the same basic file load operation...

Resummary: goal is to interrupt customer checkout to obtain additional information pertinent to the product at the point the product is added to the cart (not using attributes associated with the product that could be captured at the point of adding the product to the cart and of any type of data input) in such a way that collected data from the point of selecting the product to it actually being added to the cart is not lost as a result of page movement/$_POST data.. I don't yet have information about why it is important to collect the information at the point of clicking add to cart (instead of as presented on screen) or why the data collection couldn't occur at a later point or for that matter how that collected data impacts the product "processing". The information related to that only helps in working together on a path forwards.