$Pinfo->Products_id not set when you do back from editing a product

[brittainmark]

Trying to write a plug in to add additional info to a product. When I go to edit the product i Use the $pinfo->products_id which is set and passed in by in $p1 by the notifier ($zco_notifier->notify('NOTIFY_ADMIN_PRODUCT_COLLECT_INFO_EXTRA_INPUTS', $pInfo, $extra_product_inputs); collect_info.php line 210 ). When i hit the back button the $pinfo->Products_id is set to "".
This causes my addin to fail as it is trying to read an additional table to get the data it needs.
My question is should I be using $_GET("Pid") instad of relying on the $pinfo array or is this a bug in zen cart or is there another way that i should get the products id.

Thanks in anticipation.

[mc12345678]

While might have an idea, can you explain a little more?

From the above explanation, this is what it (incorrectly) states.
When looking at the list of product within a category, the edit button is selected which takes the admin to the product detail page where data is collected about the product and displayed through the associated collect_info.php page for the product type. The message above then says that the back button is selected (the browser? The cancel button on the page? What back button?)

This action would be expected to take the admin back to the list of product within the category and doesn't make sense that the notifier would even be triggered. It is this last part that offers confusion and why I say I have the situation wrong.

So, assuming that after capturing the data through the notifier the first time, that the next action is/was to Preview the page and it is *there* that the back button shown on the preview info page is clicked, note that the products_id was not posted to the page because it wasn't posted to the page in the initial collect_info. Therefore, when selecting the back button, there is no products_id posted back to the collect_info page. But... at that point the uri also changes to have the action parameter set to "update_product" which could at least be in part an indication that pID is/might be set.

Because note, a new product won't have a products_id until it is actually saved. So... yes, could maybe investigate the existence of pID and use it if it is set, but even then there may be some discrepancy as in if someone types it on the browser or changes it in the html code of the preview_info page... not expected, just saying...

[brittainmark]

Sorry, I'll try to be a little clearer.
From products category you select edit (pencil icon) this takes you to the product to be edited. Via collect product info and within that the $pinfo array had products_id set. You then edit the product and press the preview button to start the process of updating the product. At this point you are presented with three buttons Back, Update and cancel to choose what to do with the product. If you press the Back button, you are returned to the product again via collect product info, but this time the $pInfo array does not have the products_id set. In my observer, I used the values passed to the observer (the $pInfo array) to determine the products_id.

The other confusing thing is that when you edit an existing product (click the pensil icon on product in product category) the url used is https://innerlightcrystals.co.uk/sal...pe=1&pID=1407&action=new_product&search=t001
I don't think there is an edit action for product.

So I think you the logic is:
1) new product $pInfo->products_id not set, $_GET['pID'] not set
2) edit a product from products category $pInfo->products_id set, $_get['pID'] set
3) pressing back button from the product edit screen $pInfo->products_id not set, $_GET['pId'] set

I will have to retink my logic in my observer to match this.

Thanks for your input if you have any further thoughts please let me know.

[carlwhat]

yeah, i think this is a bug in the ZC base.

when you edit a product, the url action (and pid) is:

&pID=3823&action=new_product

when you use the ZC back button (not your browser back button), the url action is:

&pID=3823&action=update_product

and the data passed to the observer in the first element (in this case $pInfo) is slightly different.

$pInfo->products_id is now empty.

my limited testing also suggests:
$pInfo->products_name is now an array.
$pInfo->products_description also now is an array.

i would think you should use the $_GET var as opposed to the $pInfo var in this observer as that should always be set.

else if you could do an empty check on $pInfo->products_id and then use the $_GET['pID'].

best.

[mc12345678]

yeah, i think this is a bug in the ZC base.

when you edit a product, the url action (and pid) is:

&pID=3823&action=new_product

when you use the ZC back button (not your browser back button), the url action is:

&pID=3823&action=update_product

and the data passed to the observer in the first element (in this case $pInfo) is slightly different.

$pInfo->products_id is now empty.

my limited testing also suggests:
$pInfo->products_name is now an array.
$pInfo->products_description also now is an array.

i would think you should use the $_GET var as opposed to the $pInfo var in this observer as that should always be set.

else if you could do an empty check on $pInfo->products_id and then use the $_GET['pID'].

best.

Slight correction since it appears the mindset of using the notifier is when *editing* an existing product. A new product would cause $_GET['pID'] to *NOT* be set.

As to it being a "bug", looks to me like it was an accepted difference by "minimizing" file modifications to incorporate all of the changes that were made in product handling. The fact that editing an existing product as approached from the categories/products area wasn't made the same as returning to that same page from the preview page seems problematic/unusual, not even sure why it was changed to update on clicking the back button instead of just going to the collect page the same way.

But... can say that with those differences in the action parameter it is easier to determine what arrangement the observer data is expected to take. In one case there is the single set of data associated with the admin's language in the other it is the array of data that had previously been posted.

To get both sets to align more closely a number of code sections would need to be revised/moved within collect_info so that those language dependent variables could be built in advance of the notifier even though that would simplify the language loop(s) around each of those variables.