After re-processing the output of uc_shipping_address_form(), $form_state['values']['pickup_address'] is an object, not an array. This blew up on me when I altered uc_shipping_shipment_edit() to add some AJAX. Changing the reference to an object member instead of an array element stops it from blowing up.

I'll attach a patch in a reply. That's the right way to do it, right?

Comments

Dan Z’s picture

Status: Active » Needs review
StatusFileSize
new813 bytes

Here's the patch. Short and sweet and squashes the bug.

Dan Z’s picture

Issue summary: View changes

Punctuation fix.

longwave’s picture

Status: Needs review » Needs work

The origin address fields don't seem to work anyway. Without the patch, if I change the country, it blows up with an Ajax error. With the patch, there is no error, but after saving the shipment it still has the original address.

DanZ’s picture

Title: Bad data type in re-processed uc_shipping_address_form causes AJAX crash » AJAX crash and address load/save failure in uc_shipping_shipment_edit_submit()
Status: Needs work » Needs review
StatusFileSize
new3.2 KB

Ok, I fixed that.

The $form_state['values']['pickup_address'] origin address object created by the uc_address entity does not update when the user modifies a text field. The updated text field values end up in the bottom level of $form_state['values'], so I made a patch to take the values from there.

Also, I found another problem.

While the form correctly saves the destination address, it does not (later) load it from the $shipment object when the shipment is edited. It just takes it from the $order object, even if the $shipment has already been saved. I patched the form to load from the shipment object if there is address information there.

The previous fix is still in the patch.

Now I've patched three bugs and resorted to using git so I can do a multi-file patch. My patches are getting bigger. The direction I'm heading is ominous.

DanZ’s picture

Title: AJAX crash and address load/save failure in uc_shipping_shipment_edit_submit() » AJAX crash and address load/save failure in uc_shipping_shipment_edit() form

Status: Needs review » Needs work

The last submitted patch, shipping_form-1844402-3.patch, failed testing.

DanZ’s picture

Status: Needs work » Needs review

#3: shipping_form-1844402-3.patch queued for re-testing.

"Connection refused" from the GIT server? That can't be good.

DanZ’s picture

We have five followers. The patch in #3 works. Perhaps someone can test it. To execute the test:

A) Create an order (probably as a customer).

B) Go to admin/store/orders/view.

C) Click on the "package order ## products" icon for the new order from step A.

D) Create at least one package for the order. The simplest way is to select all the products and click on "Create one package".

E) Click on the Shipments tab.

F) Select the packages from step D and the "Ship manually" shipping method and click "Ship packages". The shipment creation form appears.

G)Modify the country of the sender address. Just select a different country.

Confirm: Without patch -> AJAX crash. With patch -> No crash, and the state/province selection list is updated.

H) Modify the sender and recipient street addresses then click on "Save shipment". The order shipments tab will re-display.

Confirm: Examine the {uc_shipments} table with phpmyadmin or similar tool. Without patch -> sender address is not updated. With patch -> sender address is updated.

I) Click on "edit" for the new shipment. The shipment editing form re-appears.

Confirm: Examine the destination address field. Without patch -> destination address does not reflect changes from step H. With patch -> destination address does reflect changes.

longwave’s picture

A slightly shorter patch that should solve all these issues. DanZ, can you confirm this works for you?

longwave’s picture

Doesn't seem like that country check is needed in the first place.

DanZ’s picture

Status: Needs review » Reviewed & tested by the community

Confirmed! Patch #9 passes all the tests in #7 with the vanilla version of the form and also a heavily _alter'ed version.

longwave’s picture

Status: Reviewed & tested by the community » Fixed

Committed #9.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Mentioned main form function.