Release 1.1.0

Compatibility

This version of the module is compatible with OXID eShop 7.1 - 7.5
This version of the module is compatible with MySQL 8.0
This version of the module is compatible with PHP 8.1 - 8.5

Overview

This release moves all Endereco API traffic server-side, so the API key no longer
appears in the page source, and secures the address save endpoint against
requests for addresses the customer does not own. It completes the integration of
JS-SDK 1.14.5, extends support to OXID 7.4/7.5 and PHP 8.4/8.5, fixes a series of
address check and checkout issues found in the APEX theme, and removes a large
amount of OXID 6 leftovers and dead code.

Improvements

Moved Endereco API Traffic Server-Side

• Issue: The integrator configuration, including the Endereco API key, was
  rendered into the page source, so anyone could read the key from the storefront
  and reuse it elsewhere.
• Solution: A new proxy controller (cl=enderecoproxy) forwards the JSON-RPC
  requests to the Endereco service and injects the API key from the module
  configuration, mirroring the approach already used in the OXID 6 client.
• Impact: The API key stays on the server and cannot be extracted from the
  storefront. The standalone assets/proxy/io.php is gone, replaced by the proxy
  controller.

Secured the Address Save Endpoint

• Issue: The address save endpoint accepted any address id without checking
  ownership, so a logged-in customer could write to another customer's address. It
  also accepted requests by any method and did not validate the request body.
• Solution: The endpoint now rejects non-POST requests, requires a logged-in
  user, validates the JSON body and verifies that the edited billing or shipping
  address belongs to the current customer before saving.
• Impact: Addresses can only be written by their owner. Custom integrations
  calling this endpoint must send a POST from the session of the address owner.

Completed the JS-SDK 1.14 Integration

• Issue: JS-SDK 1.14 introduced subdivisionCode as a first-class address
  field and renamed its internal AMS objects. Both changes needed adaptation:
  the renamed objects broke the POST field names the backend expected, and
  whether a country even has subdivisions is a decision the SDK now delegates to
  the integration.
• Solution: The module resolves country and state server-side and hands them
  to the SDK before OXID's own JavaScript runs, includes subdivisionCode in the
  API payload and address hash only for countries that actually have ISO 3166-2
  states configured, and aligns the AMS field names with the backend again. The
  address hash is now built from an associative array via json_encode instead of
  a flat implode, which no longer produces identical hashes for structurally
  different addresses. The JS-SDK is pinned to the exact patch version 1.14.5 so
  installs are reproducible; that patch also corrects which status codes the SDK
  preloads into its cache on page load.
• Impact: Address validation works correctly for countries with and without
  subdivisions, and stale validation state is now detected and cleared on page
  load, which also catches addresses changed outside of Endereco.
• Reference: DEV-399, DEV-760

Removed Smart Autofill

• Issue: Smart Autofill caused more problems than it solved. Many customers
  did not notice that the feature had already filled in a field and kept typing,
  which produced nonsensical address input.
• Solution: The feature is hardcoded off in the SDK configuration, and the
  setting, its admin checkbox and its translations are removed, so it cannot be
  re-enabled from the backend. Shops with a stale sSMARTFILL=true value in the
  database are covered as well.
• Impact: Address entry behaves predictably. The feature still exists in the
  underlying JS SDK but is permanently switched off here.
• Reference: DEV-368

Extended PHP and OXID Compatibility

The module now officially supports OXID 7.4 and 7.5, and PHP 8.4 and 8.5 in
addition to 8.1 - 8.3. The QA pipeline covers all five OXID versions, PHPStan
resolves OXID-generated classes so shop-specific code is actually analysed, and
the PHP compatibility check runs one container per version in parallel instead of
one per file, which takes it from minutes to about a second.

• Reference: DEV-674

Added a Local Development Environment

playground.sh and a docker/ setup spin up a fully configured OXID 7 test shop
with the module live-mounted from the working directory, for any of OXID 7.1 -
7.5, including an in-browser database manager. The obsolete OXID 6
docker-compose environment is removed.

• Reference: DEV-639

Clearer Name Check Setting

The setting previously labelled "Check salutation" suggested it only controlled
salutation detection, while it actually enables or disables the entire name check
and standardization service. The group and toggle labels now say so, following the
wording used in the Shopware 6 client. Three help texts that existed only in
German were also translated to English.

• Reference: DEV-736

Removed OXID 6 Leftovers and Dead Code

A single cleanup pass removed everything the module carried without using it: the
pre-migration Installer and its bEnderecoUseMigrations flag, the leftovers of
the custom admin settings page, the Smarty-era blocks and templates keys in
metadata.php, three SDK hooks that 1.14 no longer reads, unreferenced
per-theme stylesheets, an orphaned JavaScript file, a duplicate module thumbnail,
an unloadable class stub that made every optimised autoload dump print a PSR-4
warning, and several uncalled methods, dead config entries and unused imports. A
method duplicated between UserComponent and EnderecoService now lives only in
the service; its duplicate contained a stray echo that could have printed an API
error into the response body and left the customer on a page instead of the
intended redirect. Stale package and PHP version lines in the translation file
headers were corrected.

• Reference: DEV-765

Rebuilt Bundled Frontend Assets

The bundled JavaScript was rebuilt with an updated build and lint toolchain. The
dependency list now declares what the build and endereco.js actually use instead
of relying on packages pulled in transitively through the JS-SDK.

Bug Fixes

Fixed Address Checks Failing with a 502

When a mapping lookup missed — a country reset to "-" during registration, or the
"no salutation" option — the resolvers returned undefined instead of an empty
string. That value propagated into autocomplete requests and address checks and
the endpoint answered with a 502. Both resolvers now fall back to an empty string.
(DEV-684, DEV-734)

Fixed JavaScript Breaking on Special Characters

A translation, country or state name containing an apostrophe (for example "Côte
d'Ivoire") broke out of its JavaScript string literal and left the integrator
half-initialized. Prediction data echoed back into the address forms was escaped
twice, so JSON.parse failed in the JS-SDK. Both values are now escaped exactly
once for the context they land in. (DEV-707, DEV-723)

Fixed Validation Metadata Not Persisting

A newly created shipping address never got its address hash written, because the
write was gated on an address id that does not exist yet on first save — permanently
so for checkout registration and guest orders. The empty hash then looked like a
mismatch on every page load, which cleared the validation status that had just
been written and rewrote the same empty state to the database on every request. The
hash is now resolved from the actually saved address and written on first save, and
the invalidation runs exactly once instead of on every page load. (DEV-678, DEV-679)

Fixed the Address Correction Flow on the Order Page

Clicking "edit" in the address check modal on the order confirmation page
redirected the customer to the address step, but the edit form never opened there,
leaving them unable to correct the flagged address. The page reload after a
correction was decided through a single shared slot that both addresses raced for,
so a reload could be silently dropped, and the two branches disagreed on when
another check was still in flight. The edit form now opens after the redirect, and
the reload is registered before any check can start and triggered once the save
actually succeeded. (DEV-687, DEV-681)

Fixed Checkout Buttons in the APEX Theme

The theme's "Next" button in the checkout address step sits outside the form and
submits it natively, so the address check never ran and could not block submission
— the checkout proceeded with an unresolved address. The "pencil" edit-address
toggle, on the other hand, is marked as a submit button although it only shows and
hides the form, so the SDK wired its submit logic to it and closed the form again
after validation. Both buttons are now handled explicitly. (DEV-680, DEV-708)

Fixed Name Check Using the Previous Address's Name

The theme's "add new delivery address" control reuses the existing address form
and clears it by plain assignment, which leaves the previously cached name in
place while the salutation is already blank. The name check then ran against that
stale name. The cached name and salutation are now reset when the control is
selected, in both the account area and checkout. (DEV-752)

Fixed the Prediction Country Being Ignored

Server-side validation read the prediction's country from the SDK-internal field
name rather than the one the Web API returns, which raised a PHP warning on every
prediction and silently fell back to the requested country instead of the
predicted one. (DEV-685)

Fixed Predictions Not Rendering in the Admin

The three admin controllers listed subdevisionCode among the prediction fields
they render while the service writes subdivisionCode, so the row stayed empty and
an "Undefined property" warning was raised on every customer master data and
address page. The name is corrected and the prediction reads are guarded, since
subdivision and additional info are only present when the API returns them.
(DEV-765)

Fixed a Warning and a Path Disclosure in the Transaction Referer

The referer was read from the request without a guard, raising a PHP warning
whenever the header was absent, and all three call sites then fell back to the
server's absolute file path, which was sent to the Endereco API. All three now
resolve the referer through one helper that falls back to the shop URL.
(DEV-686)

Migration Notes

No new database migrations ship with this release, but run
vendor/bin/oe-eshop-db_migrate migrations:migrate as usual after the update, then
clear the cache and rebuild the views.

The address hash formula changed with the JS-SDK 1.14 integration. Existing
addresses therefore no longer match their stored hash and have their validation
state invalidated once on the first page load after the update; they are re-checked
the next time they are used. This is expected and happens exactly once per address.

Smart Autofill is gone from the module configuration and can no longer be enabled.
A stale sSMARTFILL value left in the database has no effect.

Shops with a custom integration should be aware that the Endereco API is now
reached through the module's own proxy controller rather than directly from the
browser, and that the address save endpoint requires a POST from the logged-in
owner of the address.

Update Notes

The module is installed and updated through Composer:

composer require endereco/endereco-oxid7-twig-client:1.1.0

There is no 1.0.0 release. The predecessor is published as 1.0, which Composer
normalizes to the same version as 1.0.0, so this release is numbered 1.1.0.

After the update you must run the migrations, clear the cache and rebuild the
database views for the module to work correctly, especially for a major or feature
release (but even patches might contain migrations to clean up something).

Despite very thorough testing, we can hardly predict what other dependencies in
form of modules and custom modifications you have in your shop, so we advise to
update in a test environment first to see if the module still works as expected
before applying the update to production system.