Compatibility
This version of the plugin is compatible with Shopware 6.7.0.1 - 6.7.13.0
This version of the plugin is compatible with MySQL 8.0 - 8.4
This version of the plugin is compatible with PHP 8.2 - 8.5
Overview
This release makes the result of the address check available on the order itself: on request, the validated address data is copied into the order address and stays readable there after the checkout is finished. It also reworks the plugin's logging so that Endereco log entries end up in their own logfile instead of cluttering the Shopware log, updates the bundled Endereco JS SDK, and fixes issues that affected webhooks and requests sent through the Store API.
Improvements
Address Check Results Are Now Preserved on the Order Address
- Issue: The result of the address check is stored on the customer address. A customer can change or delete that address after ordering, so for a completed order there was no reliable record of which address data had actually been validated.
- Solution: When the cart is converted into an order, the current customer address extension is copied into the order address extension, including the sales channel of the order, which a new database migration adds as a column. Order addresses that are edited afterwards get their stored check result invalidated, so no stale validation status is kept. The integrity checks that complete missing extension data now only run for order addresses that actually carry an Endereco extension, so historic orders from before this feature are left untouched. The whole behaviour is bound to a new plugin setting, "Copy data of the address check into the order address", which is disabled by default.
- Impact: Shops that enable the new setting keep the check status, the predictions and the split street and house number of the validated address available per order, readable through the API by associating the order address extension. Since the feature is opt-in, it can also be switched off again on its own, without deactivating the entire plugin. Existing orders are not changed by the update.
- Reference: DEV-675, DEV-676, DEV-677, DEV-691, DEV-735
Reworked Plugin Logging
- Issue: Logging inside the plugin was inconsistent. The API proxy controller wrote into Shopware's standard log and filled it with entries that looked more relevant than they were, while the server-side services logged through an in-memory logger whose entries were never persisted and never read back, so they were lost at the end of each request. On top of that, timeouts and connection failures were logged as errors, although they do not necessarily mean that the Endereco services are unavailable.
- Solution: The plugin now uses its own Monolog channel with a rotating logfile (
var/log/endereco_shopware6_client_<environment>.log, up to 30 files, warning level and above). Only entries with a severity of critical or higher are additionally escalated into Shopware's standard log. The API proxy controller and the server-side services were switched to this channel, the obsolete in-memory logger infrastructure was removed, and transport and connection exceptions are now logged as warnings instead of errors. - Impact: Shopware's standard log stays clean, information that is useful for debugging is persisted, and temporary connection problems no longer show up as errors.
- Reference: DEV-715, DEV-721, DEV-722, DEV-724, DEV-725, DEV-726
Code Cleanup and Extended QA Coverage
An older implementation wrote the result of the address check into the custom fields of the corresponding order. That logic had already been deactivated by an early return and therefore never wrote any data. Since the check result is now kept on the order address extension instead, the deactivated subscriber and everything that had become dead code because of it — the services it consumed and the unused parts of the corresponding struct — were removed. Only the custom field keys remain, because the uninstall routine still uses them to clean up the data of shops that were on a version where this option was available and enabled. This is a pure cleanup with no effect on the storefront or on existing orders. (DEV-673, DEV-783)
The QA gates were updated to the most recent Shopware 6.7 releases, 6.7.12.2 and 6.7.13.0. In addition, the code style check was run against a glob that silently skipped parts of the source tree, so it only covered files exactly two directory levels deep. The check now walks the source directory recursively, and the code style warnings that this uncovered were fixed. No functional behaviour was changed by these fixes. (DEV-781)
Bug Fixes
Fixed Webhooks for Addresses Without Endereco Data
If a customer managed to register without an Endereco address extension, the plugin added an extension with default values to the address, which established a circular reference between address and extension. Serializing a webhook payload then failed with a recursion error and the webhook was not sent to the target system. The extension no longer serializes its reference back to the address, and a new test case guards against this regression. (DEV-650)
Fixed Crash When Cloning an Address With a Freshly Created Endereco Extension
The Endereco address extension keeps a back-reference to the customer address it is attached to, and that address holds the extension in its extension list, so both objects reference each other. Shopware clones structs and entities by deep-cloning every object property without detecting such cycles, which meant that cloning either side of this pair called itself until the PHP call stack was exhausted and the request aborted with a critical error. The cycle only existed while the extension had been recreated with default values during the running request, which happens when an address was changed outside of the storefront, for example through the administration or directly in the database. In practice this surfaced on logout, where Shopware clones the customer data. The extension now drops the back-reference when it is cloned, so the cycle is broken and cloning works normally again. (DEV-795)
Fixed Address Selection During Street Splitting Validation
While building the validation definition for the registration, the branch for the shipping address read the billing address from the request data. In the storefront this never surfaced, because the register form always submits a billing address, but through the Store API a payload without a billing address could reach that branch and cause a fatal error before the validator was able to reject the request. The correct address is now read for each branch, and payloads that do not contain proper address data are ignored. (DEV-787)
Fixed Status Code Issues via Endereco JS SDK 1.14.5
The bundled Endereco JS SDK was updated to version 1.14.5, which fixes three issues relevant for this plugin: conflicting address check status codes caused by trimming address fields while generating the address cache key, a wrong field status for first and last name on requests following a "name not found" response, and conflicting selection states when an already checked address was edited again. (DEV-759)
Migration Notes
This update contains a database migration, which adds the sales channel to the order address extension. Make sure to click "update" in the plugin list so the migration is executed.
The new setting "Copy data of the address check into the order address" is disabled by default. Shops that want the address check result to be preserved per order have to enable it explicitly; it only applies to orders placed after it was enabled.
Endereco log entries are no longer written into Shopware's standard log, except for entries with a severity of critical or higher. If you evaluate the plugin's log entries, read them from var/log/endereco_shopware6_client_<environment>.log from now on.
Update Notes
If you had previously installed the store version of the plugin (installed either through Shopware store, through composer or via upload of EndrecoShopware6ClientStore.zip), then make sure you download and install EndrecoShopware6ClientStore.zip again.
After the upload of plugin zip you must click on "update" in the plugin list for the plugin to execute migrations, especially if the plugin update is 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 plugins and custom modifications you have in your shop, so we advise to update in a test environment first to see if the plugin still works as expected before applying the update to production system.