The post How to customize pagebuilder first appeared on Tag Vibe.

The configuration layer is designed to provide a hierarchical structure for managing different configuration settings. The hierarchy starts at the default level and extends to the store level. This hierarchical structure allows the settings to be inherited from the default level to the store level, making it easy to manage settings for multiple stores.

The configuration settings are stored in the database in the core_config_data table. This table contains a row for each configuration setting and stores information such as the configuration path, the value of the configuration, and the scope of the configuration (i.e. website, store view, or default).

The Configuration module also provides an API for retrieving and modifying configuration settings. This API can be used by developers to read and modify configuration settings programmatically.

The configuration layer is used extensively throughout Magento 2, and it is an integral part of the system architecture. It is used to manage a wide range of settings, including store-specific settings, system-wide settings, and module-specific settings.

Overall, the configuration layer in Magento 2 is a critical component of the system architecture, and it provides a flexible and hierarchical structure for managing configuration settings.

Here is some more information about the configuration layer in Magento 2:

1. Configuration Scope:

The configuration layer in Magento 2 allows developers to set configuration settings at different levels of scope. The available scopes are “Default”, “Website”, and “Store View”. This means that a configuration setting can be applied to the entire Magento installation (Default scope), to a specific website, or to a specific store view. When a setting is applied at a higher scope, it is inherited by lower scopes. For example, if a configuration setting is set at the website level, all store views under that website will inherit that setting.

2. Configuration Path:

Each configuration setting in Magento 2 has a unique configuration path. This path is used to identify the setting and to retrieve or modify its value. The configuration path is a combination of a group name, a field name, and (optionally) a website code or a store code. For example, the configuration path for the store name setting is “general/store_information/name”.

3. Configuration Structure:

The configuration settings in Magento 2 are organized into different groups based on their functionality. For example, there are groups for General Settings, Catalog Settings, Sales Settings, etc. These groups are defined in XML files located in the etc/adminhtml/system.xml and etc/frontend/system.xml files of each module. Each group contains one or more fields, which are the individual configuration settings.

4. Configuration Override:

The configuration layer in Magento 2 allows developers to override the default configuration settings by creating custom XML files. These files can be placed in the app/code/[Vendor]/[Module]/etc directory of a custom module, and they can be used to set custom values for specific configuration settings. When Magento 2 loads the configuration settings, it will merge the custom XML files with the default XML files, and apply the custom values for any overridden settings.

Overall, the configuration layer in Magento 2 provides a flexible and hierarchical structure for managing configuration settings, and it is an essential component of the system architecture. It allows developers to customize the behavior of the system and provides store owners with the ability to manage their stores efficiently.

Example of how to use the configuration layer in Magento 2:

Let’s say you want to change the maximum order amount allowed for your store. By default, Magento 2 sets the maximum order amount to 10,000. To change this setting, follow these steps:

1. Log in to the Magento 2 admin panel and navigate to “Stores” > “Configuration” > “Sales”.
2. Click on the “Payment Methods” tab and then click on the “Credit Card” section to expand it.
3. Scroll down to the “Maximum Order Total” setting and change the value to your desired maximum order amount (e.g. 20,000).
4. Click the “Save Config” button to save your changes.

Now, let’s say you want to change the maximum order amount for a specific website. To do this, follow these steps:

1. Log in to the Magento 2 admin panel and navigate to “Stores” > “Configuration”.
2. From the “Scope” dropdown menu, select the website for which you want to change the maximum order amount.
3. Follow the same steps as above to locate the “Maximum Order Total” setting under the “Credit Card” section, and update the value to your desired maximum order amount (e.g. 30,000).
4. Click the “Save Config” button to save your changes.

These changes will now apply to the specific website you selected, and any store views under that website. If you want to apply the same changes to all websites or store views, you can follow the same steps and select the “Default Config” scope from the dropdown menu in step 2.

Alternatively, you can use the configuration override feature to set a custom value for the “Maximum Order Total” setting in a custom module. To do this, you can create an XML file with the following content:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Store:etc/config.xsd">
    <default>
        <payment>
            <ccsave>
                <order_total>40000</order_total>
            </ccsave>
        </payment>
    </default>
</config>

This XML file sets the “Maximum Order Total” value for the “ccsave” payment method to 40,000. You can place this file in the app/code/[Vendor]/[Module]/etc directory of your custom module and enable the module in the Magento 2 admin panel.

The post Configuration layer in Magento 2 first appeared on Tag Vibe.

Best Practices for caching

• Enable Full Page Cache (FPC): Adobe Commerce comes with a built-in Full Page Cache that can dramatically speed up the loading time of pages. Enabling FPC can be done by going to System > Cache Management > Full Page Cache and selecting “Enable” from the drop-down menu. Once enabled, FPC will store the HTML of each page, reducing the amount of processing required to generate each page.
• Use Varnish Cache: Varnish Cache is a powerful caching solution that can be used in conjunction with Adobe Commerce’s built-in FPC. Varnish Cache sits between the web server and the client and caches the content of each request, serving cached content to subsequent requests. To enable Varnish Cache, you need to configure it in your web server and configure Adobe Commerce to use it as a caching proxy.
• Use Redis Cache: Redis is an in-memory key-value store that can be used as a cache backend for Adobe Commerce. By default, Adobe Commerce uses file-based caching, which can be slow and inefficient. Redis can be faster and more efficient because it stores data in memory instead of on disk. To use Redis Cache in Adobe Commerce, you need to install and configure the Redis extension, and then configure Adobe Commerce to use Redis as a cache backend.
• Use Content Delivery Networks (CDN): A CDN is a network of servers that cache static content, such as images, CSS, and JavaScript files, and serves them from the server closest to the user. This can dramatically improve the loading time of static content and reduce the load on your server. Adobe Commerce has built-in support for CDN integration, which can be configured under System > Configuration > Web > CDN.
• Monitor Cache Performance: It’s important to regularly monitor the performance of your caching solutions to ensure they are working effectively. You can use tools like New Relic or Blackfire to monitor the performance of your website and identify any caching-related issues.

Types Cache:

• Configuration Cache: Stores configuration settings for the website, including the website’s system configuration and database configuration.
• Layout Cache: Stores the layout of pages and blocks on the website, including the position of blocks, their content, and other layout settings.
• Block Cache: Stores the HTML output of blocks on the website, reducing the amount of processing required to generate each page.
• Collections Data Cache: Stores data related to collections, such as product or category data, to speed up database queries.
• Reflection Cache: Stores metadata about classes and interfaces, reducing the amount of time required to load and process classes.
• Page Cache: Stores the entire HTML output of a page, including dynamic content, to reduce the amount of processing required to generate each page.
• EAV Cache: Stores data related to entities, attributes, and values, speeding up database queries.
• Translations Cache: Stores translations for the website, reducing the amount of processing required to generate translated content.
• Integration Configuration Cache: Stores configuration settings for integrations, including third-party integrations and APIs.
• Web API Cache: Stores data related to the Magento Web API, reducing the amount of processing required to generate API responses.

Create a custom cache list in Magento

• Create a new file named cache.xml in the directory app/code/<Vendor>/<Module>/etc/.
• In the cache.xml file, define the custom cache type by adding the following code:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Cache/etc/cache.xsd">
   <type name="custom_cache_type" translate="label description" instance="<Vendor>\<Module>\Cache\Type\CustomCacheType">
       <label>Custom Cache Type</label>
       <description>Custom Cache Type Description</description>
   </type>
</config>

In this code, replace <Vendor> with the name of your module vendor, and <Module> with the name of your module. Also, replace CustomCacheType with the name of your custom cache type.

• Create a new file named CustomCacheType.php in the directory app/code///Cache/Type/.
• In the CustomCacheType.php file, define the custom cache type class by adding the following code:

<?php
namespace <Vendor>\<Module>\Cache\Type;
class CustomCacheType extends \Magento\Framework\Cache\Frontend\Decorator\TagScope
{
   const TYPE_IDENTIFIER = 'custom_cache_type';
   const CACHE_TAG = 'CUSTOM_CACHE_TYPE';
   public function __construct(\Magento\Framework\App\Cache\Type\FrontendPool $cacheFrontendPool)
   {
       parent::__construct($cacheFrontendPool->get(self::TYPE_IDENTIFIER), self::CACHE_TAG);
   }
}

In this code, replace <Vendor> with the name of your module vendor, and <Module> with the name of your module. Also, replace CustomCacheType with the name of your custom cache type.

• Clear the cache by running the following command in the Magento 2 root directory:

php bin/magento cache:clean

• Verify that your custom cache type is listed in the cache list by going to System > Cache Management in the Magento 2 admin panel.

Once your custom cache type is added, you can use it to cache custom data or functionality in your module.

By effectively using cache in Adobe Commerce, you can significantly improve the performance of your website and provide a better user experience for your customers.

Also read the what is partial caching in Mageto 2

The post How to effectively use cache in Adobe Commerce(Magento) first appeared on Tag Vibe.

Magento 2 Access Control List Rules
The Magento 2 Admin ACL resources are visible under the Magento 2 admin System > Permissions > User Roles area. When we click on the Add New Role button or access a role.  In Magento 2, we can apply the ACL rule in the menu or form, but this article will help you apply the ACL rule on specific filed in the form.

Step: 1

Create a UI component file vendor\module-name\Ui\Component\Form\Field\DisableField

<?php


namespace vendor\module-name\Ui\Component\Form\Field;

use Magento\Framework\View\Element\UiComponent\ContextInterface;
use Magento\Framework\View\Element\UiComponentFactory;
use Magento\Framework\View\Element\UiComponentInterface;
use Magento\Framework\AuthorizationInterface;
use Magento\Ui\Component\Form\Field as FormField;

/**
 * Class DisableField
 *
 * @package I95DevConnect\CloudCustomizations\Ui\Component\Form\Field
 * @author Rajat Kar
 */
class DisableField extends FormField
{
    /**
     * @var AuthorizationInterface
     */
    private $authorization;

    /**
     * Constructor
     *
     * @param ContextInterface $context
     * @param UiComponentFactory $uiComponentFactory
     * @param AuthorizationInterface $authorization
     * @param UiComponentInterface[] $components
     * @param array $data
     */
    public function __construct(
        ContextInterface       $context,
        UiComponentFactory     $uiComponentFactory,
        AuthorizationInterface $authorization,
        array                  $components = [],
        array                  $data = []
    )
    {
        $this->authorization = $authorization;
        parent::__construct($context, $uiComponentFactory, $components, $data);
    }


    /**
     * Prepare component configuration
     *
     * @return void
     * @throws \Magento\Framework\Exception\LocalizedException
     */
    public function prepare()
    {
        parent::prepare();


        $isAllowed = $this->authorization->isAllowed(‘Vendor_ModuleName:: editable_fields’);
        if (!$isAllowed) {
            $currentConfig = $this->getData(‘config’);
            $currentConfig[‘disabled’] = true;
            $this->setData(‘config’, $currentConfig);
        }
    }
}

Step: 2

Create etc/acl.xml

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../../lib/internal/Magento/Framework/Acl/etc/acl.xsd">
    <acl>
        <resources>
            <resource id="Magento_Backend::admin">
                <resource id="Magento_Customer::customer">
                    <resource id="Magento_Customer::manage">
                        <resource id="Vendor_ModuleName:: editable_fields" title="allow edit some field" translate="title" sortOrder="110" />
                    </resource>
                </resource>
            </resource>
        </resources>
    </acl>
</config>

Step: 3

view/adminhtml/ui_component/customer_form.xml

<form xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Ui:etc/ui_configuration.xsd">
    <fieldset name="customer">
        <field name="customer_field_name" formElement="input" class="Vendor\ModuleName\Ui\Component\Form\Field\DisableField">
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="source" xsi:type="string">customer</item>
                    <item name="sortOrder" xsi:type="number">100</item>
                    <item name="visible" xsi:type="boolean">true</item>
                </item>
            </argument>
        </field>
    </fieldset>
</form>

Hope this article help you. Thank you

The post Magento2: Apply ACL to custom field first appeared on Tag Vibe.

Follow the below steps to achieve this:

Add the below code into your existing menu.xml

File path: app\code\Vendor\Extension\etc\adminhtml\menu.xml

<?xml version="1.0"?>

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Backend:etc/menu.xsd">
    <menu>
        <add id="Vendor_Extension::extensionmenu" title=" Extension Menu" module="Vendor_Extension" sortOrder="10" resource="Vendor_Extension::mainmenu" dependsOnConfig="section/group/field"/>
    </menu>
</config>

let us know via the comment box if you need any help on this, we will be happy to solve it! Do share the article with your friends and stay updated with us.

The post Hide Admin Menu Based on System Config in Magento 2 first appeared on Tag Vibe.

Debug the Knockout JS issue

• At first we need to get a Knockout instance from the browser console.
  • var ko = require('knockout');
• Now we have Knockout instance in the ko variable. We can use it to get a context of any DOM element.

var context = ko.contextFor($0);

• where $0 is a special variable in browser console. It contains a link to a DOM element that is last inspected.

// Admin > Products > Catalog > Add Product
// Inspect "Product Name"
var fieldName = ko.contextFor($0).$data;

console.log(fieldName.name); // product_form.product_form.product-details.container_name.name

OR

You can install this https://chrome.google.com/webstore/detail/knockoutjs-context-debugg/oddcpmchholgcjgjdnfjmildmlielhof?hl=en knockout debugger and debug.

Hope this article helped you in some way. Please leave us your comment and let us know what do you think? Thanks.

The post How to debug Magento 2 issues? first appeared on Tag Vibe.

As a Magento developer we are facing lot of issue which is common while developing and customizing a module. Today we are going to discuss about How to fix the “Area code not set” issue. This error occurs mainly from four reason CRON, CLI , Setup Scripts and use of session in wrong area and it will pop up when you are either compiling or running setup upgrade command. In both of the cases, it tries to create an object using the constructor of your classes but couldn’t find the area code and it fails to load.

WHAT IS AREA CODE IN MAGENTO 2?

Magento uses area codes to define the entry point to application to load given a specific request context. There are seven distinct ‘areas’ of the system, each with their own area code:

1. global
2. doc
3. crontab
4. frontend
5. adminhtml
6. webapi_rest
7. webapi_soap

When setting the session for customer or Order we should define the area.

It’s Fixed related to this :

1. Magento 2.2 area code not set: area code must be set before starting a session.
2. upgrading data.. area code not set: area code must be set before starting a session.
3. Magento 2 setup upgrade import failed: area code is not set
4. import failed: area code not set: area code must be set before starting a session.
5. Magento 2 area code admin does not exist
6. processing configurations data from configuration file… import failed: area code is not set
7. import failed: area code is not set magento2
8. area code “” does not exist Magento 2

For Example:

We are creating a plugin or overriding a method of core class in custom class and we have injected Magento core session manager and customer session in custom class constructor.

For overriding the existing core class method we are using preference in di.xml and keep in global onside our custom module. when we run complile and upgrade we will get “AREA CODE NOT SET” issue.

Solution:

To resolve this issue we should keep the di.xml in frontend area as we are using customer session in our class. Likewise if you are using Magento Backend session in your custom class you should keep the di.xml in adminhtml area.

Hope this article helped you in some way. Please leave us your comment and let us know what do you think? Thanks.

The post How to fix the “AREA CODE NOT SET” issue? first appeared on Tag Vibe.

For an easy way to change the password for bulk of customer in Magento 2, you can import customer CSV file data of existing customer email id and password field. You can give your password which you want to change and password_hash should be blank.

Please refer the below sceenshots:

The post How to change customer password quickly in Magento 2 first appeared on Tag Vibe.