Upgrading to 1.1.0
Amongst other things, this release introduces a new API for address form customizations.
However, the new API necessitated making some backward incompatible changes (see below).
This release introduces a new API to customize checkout address forms.
Much of the internal code has been changed to use this new API, too.
Please refer to the changelog for details.
Please check the upgrade process overview for Hyvä-Checkout first.
Then, to upgrade, run the command
Magewire 1.10.5
This release of Hyvä Checkout requires Magewire 1.10.5 (which is a security release from the previous version).
Using a different version of Magewire
To override the pinned version of Magewire, you can add it as a root dependency with an inline alias.
For example, if you prefer to keep using Magewire 1.9.2, run the following command before upgrading the checkout:
This will install version 1.9.2 of Magewire, while allowing Hyvä Checkout 1.1.0 to be installed despite it's dependency on Magewire 1.10.5.
Use at your own risk
Please be aware that you are responsible for the stability of your checkout when using inline aliasing to install a different version of Magewire.
We only test the checkout with the pinned version of magewirephp/magewire
listed in the Hyvä Checkout composer.json
file in the require
section.
Backward incompatible changes
There are quite a number of backward incompatible changes in this release, but we expect the impact to be limited, as many are in classes and interfaces not commonly used for checkout customizations.
The changes are related to the new form customization API. Much of the internal code has been changed to use the new API, too.
We expect the most impact to be for custom form field implementations.
Other noteworthy changes are a new translation phrase and a template change.
The detailed list of backward incompatible changes can be found on the dedicated 1.1.0 BC breaks page. Be aware that most will not have any impact on customizations.
We expect the following changes to be sufficient for almost all instances of Hyvä Checkout after upgrading to 1.1.0:
New phrase "Preparing form"
A new translation phrase "Preparing form" was added, in addition to the previously used phrase "Preparing address form".
Add the new phrase to all localizations before upgrading.
Template section "Save in address book" moved
Previously the "Save in address book" checkbox was rendered by the frontend template Hyva_Checkout::checkout/address-view/address-list/form.phtml
, if $magewire->canSaveToAddressBook()
was true.
Now the checkbox is added as a form field dynamically using the form modifier API.
If you override the template in your theme, be sure to remove the section from the template after the upgrade, otherwise the checkbox will be rendered twice.
Required changes to custom fields
These actions are only required if you implemented custom fields in your Hyvä Checkout instance.
Two changes are required in order to keep custom field classes working.
Custom field constructor signature update
Custom field classes extending from EavAttributeField
or AbstractEntityField
overriding __construct
need to be updated, so their constructor signature matches the parent::__construct
signature.
All parent dependencies have been encapsulated in a container to avoid future constructor signature changes.
Custom field DI registration update
The way custom fields are registered in etc/frontend/di.xml
changed.
Previously field types were registered with EntityFormFieldFactory
like this:
<type name="Hyva\Checkout\Model\Form\EntityFormFieldFactory">
<arguments>
<argument name="customFields" xsi:type="array">
<item name="my_field" xsi:type="string">Hyva\Example\Model\Form\EntityField\EavEntityAddress\MyField</item>
Custom fields now have to be added to the
EntityFormFactory
constructor argument $elements
instead:
<type name="Hyva\Checkout\Model\Form\EntityFormFactory">
<arguments>
<argument name="elements" xsi:type="array">
<item name="my_field" xsi:type="string">Hyva\Example\Model\Form\EntityField\EavEntityAddress\MyField</item>
Required changes to form modifiers
Form modifier DI registration update
The registration of form modifiers in etc/frontend/di.xml
now requires a sortOrder
for each entry.
As a default we recommend using the value 200.
Previously, modifiers were registered without a sortOrder
attribute:
<type name="Hyva\Checkout\Model\Form\EntityForm\EavAttributeShippingAddressForm">
<arguments>
<argument name="entityFormModifiers" xsi:type="array">
<item name="with_my_field"
xsi:type="object">Hyva\Example\Model\Form\EntityFormModifier\WithMyFieldModifier</item>
Now a sortOrder
is required:
<type name="Hyva\Checkout\Model\Form\EntityForm\EavAttributeShippingAddressForm">
<arguments>
<argument name="entityFormModifiers" xsi:type="array">
<item name="with_my_field"
sortOrder="200"
xsi:type="object">Hyva\Example\Model\Form\EntityFormModifier\WithMyFieldModifier</item>
Changelogs
Changelogs are available from the CHANGELOG.md
in the codebase, or here in the docs.