This Tutorial will help the Adobe Commerce developers and beginners to easily carry out the Adobe Commerce Development process. It will also help you to customize the checkout process, Customize the product creation form, Custom Admin Design, and Custom Product attributes in your Adobe Commerce store.

1. Custom Checkout:

Custom Product Creation Form UI components are used to implement Adobe checkout. The checkout process generally consists of two steps:

  • Review and Payment Information
  • Shipping Information

Only after the first step is finished are the checkout totals and the corresponding sidebar shown.

The only exception is when only virtual and/or downloadable items are in the shopping cart; in this case, check out automatically becomes a one-step process since shipping information is not needed.

There are numerous ways to customize checkout in the Adobe Commerce store. You can easily customize the checkout process in your Adobe Commerce Store by considering the following customizations.

  • Add a new checkout step
  • Customize the view of an existing step
  • Add a custom payment method to checkout
  • Add custom validations before order placement
  • Add custom shipping carrier
  • Add custom shipping carrier validations
  • Add custom input mask for ZIP code
  • Add a customs template for a form field on the Checkout page
  • Add a new input form to the checkout
  • Add a new field in the address form
  • Add custom shipping address renderer
  • Add a custom field for an offline payment method

Adobe Commerce Customization Tutorial

2. Customize product creation form

Developers can customize product creation forms that appear on the admin’s product creation and edit pages. The form UI component is used to implement the product creation form.

Under STORES > Attributes in the Admin, you can edit and add the product attributes and attribute sets that are currently available in the form. However, you can use code to modify the form’s behavior and view. The files that define the form are listed in the following sections, along with information on how to alter them in your module.

Prerequisites

While carrying out all customizations and debugging, switch Magento to developer mode.

Do not alter the default Magento code for the sake of compatibility, upgradeability, and ease of maintenance. Put your customizations in a separate module instead.

List of customization methods

This tutorial includes the following customizations:

  • Customize the form configuration
  • Customize using a modifier class

The form’s default view on the New Product page is demonstrated in the image below:

Adobe Commerce Customization Tutorial

Customize the design

  • Discover how to alter (add, delete, or change) the configuration choices offered in the Admin. The various elements of storefront design are described by these choices.
  • Your customized location can be found here: Magento Open Source 2.1.0 and later, and Adobe Commerce Configuration options under CONTENT > Design

Environment and technologies

  • Adobe Commerce
  • Adobe Commerce on cloud infrastructure
  • Magento Open Source

Prerequisites

  • Magento installed
  • Credentials or access to Admin

Steps

Versions 2.1.0 and later are used in the following walkthrough.

On a standard Magento installation, the first page that loads displays a grid with the available configuration scopes and assigned themes when you go to CONTENT > Design > Configuration in Admin. It appears as follows:

Adobe Commerce Customization Tutorial

When you click Edit in any of the scope records, the page with available design options is displayed. For example, the default set of design options for the store view level is the following:

Adobe Commerce Customization Tutorial

Both the grid and the configuration form are implemented using UI components.

To change the grid view, you must customize the grid configuration by adding a custom design_config_listing.xml file to your module.

To change the available design settings, you must customize the grid configuration by adding your custom design_config_form.xml file in your module. If you add a new field, you must also declare it in the di.xml file.

Customize the grid

The grid containing the configuration scopes is implemented using the grid UI component.

To customize the grid view, take the following steps:

  1. In the <your_module_dir>/view/adminhtml/ui_component directory, add the empty design_config_listing.xml file.
  2. In the design_config_listing.xml file, create an element to which to add your customizations. For example, if you want to rename the column displaying the selected theme, your grid configuration must contain the following:

<?xml version=”1.0″ encoding=”UTF-8″?>

<listing xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=“urn:magento:module:Magento_Ui:etc/ui_configuration.xsd”>

<columns name=“design_config_columns”>

<column name=“theme_theme_id”>

<argument name=“data” xsi:type=“array”>

<item name=“config” xsi:type=“array”>

<item name=“label” xsi:type=“string” translate=“true”>%New theme column name%</item>

</item>

</argument>

</column>

</columns>

</listing>

Your design_config_listing.xml file is merged with the same files from the other modules, so there is no need to copy their contents. You only need to define changes. Even if you want to customize the existing entities, you only need to mention those options for which the values are customized.

For reference, view the grid configuration files of the Magento modules:

  • <Magento_Backend_module_dir>/view/adminhtml/ui_component/design_config_listing.xml
  • <Magento_Theme_module_dir>/view/adminhtml/ui_component/design_config_listing.xml

If you add a certain field as an additional grid column, you must also set the field’s use_in_grid property in the field’s metadata in the di.xml file.

3. Customize the design options

These sections detail how to customize form configuration and field metadata.

Customize the form configuration

The design configuration form is implemented using the form UI component.

To customize the form view, take the following steps:

  1. Create an empty design_config_form.xml file in the <your_module_dir>/view/adminhtml/ui_component/ directory.
  2. Add content similar to the following:

<form xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=“urn:magento:module:Magento_Ui:etc/ui_configuration.xsd”>

<fieldset name=“%fieldset_name%”>

<argument name=“data” xsi:type=“array”>

<item name=“config” xsi:type=“array”>

<item name=“label” xsi:type=“string” translate=“true”>%Fieldset Label as displayed in UI%</item>

<item name=“sortOrder” xsi:type=“number”>%order for displaying%</item>

</item>

</argument>

<!–Field sets can be nested –>

<fieldset name=“%nested_fieldset_name%”>

<argument name=“data” xsi:type=“array”>

<item name=“config” xsi:type=“array”>

<item name=“label” xsi:type=“string” translate=“true”>%Nested fieldset Label as displayed in UI%</item>

<item name=“collapsible” xsi:type=“boolean”>true</item>

<!– Nesting level, the value should correspond to the actual nesting level in the config xml file. For the top field set level = 0 –>

<item name=“level” xsi:type=“number”>%level of nesting%</item>

</item>

</argument>

<field name=“%field_name%”>

<argument name=“data” xsi:type=“array”>

<item name=“config” xsi:type=“array”>

<item name=“%field_option1%” xsi:type=“%option_type%”>%value%</item>

<item name=“%field_option2%” xsi:type=“%option_type%”>%value%</item>

….

</item>

</argument>

</field>

</fieldset>

</fieldset>

</form>

Your custom fields and field sets will be available for all configuration scopes (website, store, and store view).

Your design_config_form.xml file is merged with the same files from the other modules, so there is no need to copy their contents You only need to add your customizations.

To customize an existing entity, declare only those options; the values of which are customized. Do not copy its entire configuration.

For example, if you only want to rename the Other Settings fieldset, your form configuration must contain the following:

<?xml version=”1.0″ encoding=”UTF-8″?>

<form xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=“urn:magento:module:Magento_Ui:etc/ui_configuration.xsd”>

<fieldset name=“other_settings”>

<argument name=“data” xsi:type=“array”>

<item name=“config” xsi:type=“array”>

<item name=“label” xsi:type=“string” translate=“true”>Other Settings</item>

</item>

</argument>

</fieldset>

</form>

To delete an existing field, or fieldset, in your design_config_form.xml file, use the following syntax:

<fieldset name=“%fieldset_name%”>

<argument name=“data” xsi:type=“array”>

<item name=“disabled” xsi:type=“boolean”>true</item>

</argument>

</fieldset>

For reference, view the form configuration files of these Magento modules:

  • <Magento_Backend_module_dir>/view/adminhtml/ui_component/design_config_form.xml
  • <Magento_Catalog_module_dir>/view/adminhtml/ui_component/design_config_form.xml
  • <Magento_Email_module_dir>/view/adminhtml/ui_component/design_config_form.xml
  • <Magento_Swatches_module_dir>/view/adminhtml/ui_component/design_config_form.xml
  • <Magento_Theme_module_dir>/view/adminhtml/ui_component/design_config_form.xml

Add fields’ metadata

If in the design configuration form you add new fields, <your_module_dir>/etc/di.xml, you must specify their parent field sets and the path in the database. You can also declare the backend model used for processing the field values. If you do not specify any model, the default MagentoFrameworkAppConfigValue model is used.

The field declaration in a di.xml file looks like the following:

<type name=“MagentoThemeModelDesignConfigMetadataProvider”>

<arguments>

<argument name=“metadata” xsi:type=“array”>

<!– field name as described in configuration –>

<item name=“%field name%” xsi:type=“array”>

<!– the path to the field in system configuration storage in DB–>

<item name=“path” xsi:type=“string”>%path in system config%</item>

<!– the name of field set for current field, as described in form configuration –>

<item name=“fieldset” xsi:type=“string”>%parent_fieldset%</item>

<!– The php model used for field value processing –>

<item name=“backend_model” xsi:type=“string”>%BackendModelForFieldProcessing%</item>

<!– Define whether the field value is displayed in the Design Configuration grid –>

<item name=“use_in_grid” xsi:type=“boolean”>true|false</>

<item name=“base_url” xsi:type=“array”>

<item name=“type” xsi:type=“string”></item>

<item name=“scope_info” xsi:type=“string”></item>

<item name=“value” xsi:type=“string”></item>

</item>

</item>

</argument>

</arguments>

</type>

Example of a field declaration:

<type name=“MagentoThemeModelDesignConfigMetadataProvider”>

<arguments>

<argument name=“metadata” xsi:type=“array”>

<item name=“head_shortcut_icon” xsi:type=“array”>

<item name=“path” xsi:type=“string”>design/head/shortcut_icon</item>

<item name=“fieldset” xsi:type=“string”>head</item>

<item name=“backend_model” xsi:type=“string”>MagentoConfigModelConfigBackendImageFavicon</item>

<item name=“base_url” xsi:type=“array”>

<item name=“type” xsi:type=“string”>media</item>

<item name=“scope_info” xsi:type=“string”>1</item>

<item name=“value” xsi:type=“string”>favicon</item>

</item>

</item>

</argument>

</arguments>

</type>

For more examples and references, view the di.xml files of these Magento modules:

  • <Magento_Backend_module_dir>/etc/di.xml
  • <Magento_Catalog_module_dir>/etc/di.xml
  • <Magento_Email_module_dir>/etc/di.xml
  • <Magento_Swatches_module_dir>/etc/di.xml
  • <Magento_Theme_module_dir>/etc/di.xml

Accessing the options values in backend models

The design configuration option values are stored in the core_config_data table in the database, similar to the values of System Configuration options, and can be accessed using the MagentoFrameworkAppConfigInterface mechanism.

Custom Product Attributes:

In order to add visual treatments to products based on custom product attribute values, developers frequently need access to those values in recommendations units on storefronts.

If your store sells organic goods, for instance, you might have a custom attribute on those goods indicating Organic = Yes. If you want to give these products a unique visual treatment when they appear in recommendations, you might need access to this attribute value on the storefront. The same goes for the ability to badge products or implement custom logic in your site’s presentation layer thanks to accessing these custom product attribute values.

Set the Used in Product Listing property to Yes on the Product Attributes page in the Admin to guarantee that a custom product attribute is accessible when you render the recommendation unit on the page.

The JSON payload includes an attribute object with an array of attribute codes and values when this property is set. Based on these attribute values, you can then apply custom storefront stylings, such as the previously mentioned addition of special visual treatments or badges.

Why Choose Us?

With years of Magento and eCommerce experience, we are a custom Magento theme development company and we can implement the best eCommerce strategies and solutions that are tailored to your company’s needs and market trends. Get a free trial for 8 hours. Our goal is to offer Adobe Commerce customization services that will improve your Magento store’s competitiveness. We know how to increase conversion rates, improve user experiences, streamline workflows, and outperform the competition.

admin

Published On: June 29th, 2022 / Categories: Magento / Tags: , , /

Get our tips straight to your Inbox

Best Sources for eCommerce Store and Online Marketers

admin