Skip to content

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

composer update --with-dependencies hyva-themes/magento2-hyva-checkout:1.1.0

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:

composer require "magewirephp/magewire:1.9.2 as 1.10.5"

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.

public function __construct(FormFieldDependencies $context, array $data = [])

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">
        <argument name="customFields" xsi:type="array">
            <item name="my_field" xsi:type="string">Hyva\Example\Model\Form\EntityField\EavEntityAddress\MyField</item>
This configuration no longer has any effect.
Custom fields now have to be added to the EntityFormFactory constructor argument $elements instead:
<type name="Hyva\Checkout\Model\Form\EntityFormFactory">
        <argument name="elements" xsi:type="array">
            <item name="my_field" xsi:type="string">Hyva\Example\Model\Form\EntityField\EavEntityAddress\MyField</item>
The previous configuration can be removed.

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">
        <argument name="entityFormModifiers" xsi:type="array">
            <item name="with_my_field"

Now a sortOrder is required:

    <type name="Hyva\Checkout\Model\Form\EntityForm\EavAttributeShippingAddressForm">
            <argument name="entityFormModifiers" xsi:type="array">
                <item name="with_my_field"


Changelogs are available from the in the codebase, or here in the docs.