SmartWP Plugins

Thanks for confirming the fixes. We’ve pushed a new release, and it should be available to the public soon. If you have a moment, we’d really appreciate it if you could leave us a review.

We’ve also added both of your feature suggestions to our roadmap and will be looking at including them in a future update.

And you’re most certainly welcome to contribute. The plugin is available on GitHub here:

https://github.com/Smart-WP-Plugins/unwan-address-library-for-woocommerce

Feel free to submit a pull request or open an issue there. We’d be happy to have your contribution!

Thank you for this — it’s an unusually good report, and your reading of
frontend.js pointed straight at the right area.

Up front: we don’t have a Germanized Pro licence here, so we can’t reproduce
your exact setup. But we were able to work out the underlying cause from the
code with confidence, and it isn’t quite where it appears to be.

The custom assignment you quoted sits behind a one-shot guard, so an ordinary
checkout state update can’t reach it a second time. The only way it re-runs is
if the checkout block is fully unmounted and remounted — which is what
Germanized’s multi-level checkout does as it re-renders its address step. Each
remount resets that guard, Unwan re-inspects the address you’re halfway through
typing, finds no exact match against your saved addresses, classifies it as
custom, and collapses the form. Hence “after almost any field change”.

That also caused a second problem, which your suggested one-line fix wouldn’t
have caught: on each remount the half-typed address was being reclassified as
an edit of an existing saved address rather than a new one, which meant an
address you had explicitly chosen to enter as new would silently not be saved
to your address book after the order.

We’ve fixed both:

1. The picker’s selection now persists across remounts, so whatever you chose
   stays chosen no matter how often a third-party checkout re-renders. This is
   the actual root-cause fix, and it holds for any multi-step checkout plugin,
   not just Germanized.
2. The native fields are now hidden only when a genuinely saved address is
   selected. custom keeps them visible and editable — essentially your
   suggestion, generalized. This is a deliberate second layer: even if some
   other extension finds a new way to trigger custom, the form stays usable.

As a side effect this also fixes a related annoyance in classic checkout, where
correcting an address that wasn’t yet in your address book required wiping it
and retyping from scratch.

I’ve attached a test build so you can verify before we publish. It installs
over your current version via Plugins → Add New → Upload Plugin (WordPress will
offer to replace the existing copy). The version number is intentionally left
unchanged, so this build won’t be silently overwritten by an update while
you’re testing. https://drive.google.com/file/d/1vB1oOtEz_oE163WFN4lYliP5IYgNOotM/view?usp=sharing

Since we can’t reproduce the Germanized side ourselves, your confirmation is
what we’d be relying on. If you’re able, could you check three things?

1. The original flow — enter a new address in the Germanized billing step and
   type through first name, postcode, city and street. The form should stay
   open throughout.
2. That the new address actually appears in your address book afterwards
   (this is the second bug described above).
3. That selecting an existing saved address still collapses the fields down to
   the summary with the Change button, as before.

If all three look right we’ll ship it as the next release, and you’ll be able
to re-enable Unwan on your store. If anything still misbehaves, a screenshot or
a browser console log from the checkout step would help a lot.

Thanks again for taking the time to dig into the source — it made this much
faster to pin down.