thinkpyxl/magento2-Pyxl_SmartyStreets

Module can cause silent failures on checkout page

Closed this issue · 6 comments

If Auth ID / Auth Token / Website Key values are not set, $block->getSerializedCheckoutConfig() in the file module-checkout/view/frontend/templates/onepage.phtml returns an empty value. This causes a javascript error chain reaction that breaks the rest of the page.

@JRhyne Good find. I don't have a local install of this at the moment, but looking through the module I can't see why it would happen. If the value doesn't exist the helper returns null, and the CompositeConfigProvider shouldn't fail when serializing the array because of a null value. We're simply adding to the existing $config array, so unless something fails silently when getting the value I don't see why it would cause the entire config to be empty.

@JRhyne I can't duplicate the issue you described in a vanilla instance of Magento 2.2.6 with only Pyxl_Core and Pyxl_SmartyStreets installed. I tried it with the AutoComplete feature both enabled and disabled without any values in those fields and the JSON loaded correctly (website_key was just an empty string).

No errors occurred except when I started typing in an address (if AutoComplete was enabled), and those were just Unauthorized errors from hitting the API. The rest of the checkout worked fine.

I did submit PR #3 to change those fields to be required only if their respective feature is enabled. That should at least help prevent this in the future.

Adding some info here; @rain2o, this issue persists and seems to be specific to the staging/production environments in cloud, which makes me think it's env/infrastructure related, specifically, that it may be tied to Fastly. The window.checkoutConfig var is emptied out whenever the module is enabled, regardless of whether the keys are set. I'm working a few debug angles, but open to any thoughts or ideas you might have.

Thanks for the update @tiffanyqm . I don't have access to a cloud environment at the moment, so let me know what you find.

@rain2o just following up to let you know the issue was completely unrelated to the module or to Fastly, but had to do with a misconfig in the cloud environment. (Happy to follow up with details if you're curious, but I thought I'd let you know the module didn't need a massive overhaul to work with cloud. :))

Thanks for the update @tiffanyqm . Glad to hear the fix was just a config setting and not a rework in the module.