Forem: Ashish Ranade

Decomposition of Magento Controllers

Ashish Ranade — Tue, 05 Jan 2021 10:17:48 +0000

Controllers are the most important thing in MVC pattern. Controller helps to receive requests, process, and render pages. To create a front-end controller and to process the request, we need to extend our controller class from Magento\Framework\App\Action\Action. This class context gives some added features to handle the request type, and to validate authorized users and so on. But in this process Magento needs to include so many classes which ultimately increase execution time.

To optimize this architecture community members came up with a great solution, i.e. decompositions of controllers.

What is the Decomposition of Magento?

Decomposition of Magento Controllers

As a developer, we no longer need to extend Magento\Framework\App\Action\Action class, instead, we need to implement from \Magento\Framework\App\ActionInterface. If we know the purpose of our custom controller(whether it is use for GET, POST, etc operation) then there are separate interfaces that we can.

\Magento\Framework\App\Action\HttpDeleteActionInterface
\Magento\Framework\App\Action\HttpGetActionInterface
\Magento\Framework\App\Action\HttpPostActionInterface
\Magento\Framework\App\Action\HttpPutActionInterface

For example :

<?php 
use Magento\Framework\App\Action\HttpGetActionInterface;
use Magento\Framework\View\Result\PageFactory;
class MyController implements HttpGetActionInterface
{
    /** @var PageFactory */
    protected $resultPageFactory;
    public function __construct(PageFactory $resultPageFactory)
    {
        $this->resultPageFactory = $resultPageFactory;
    }

    public function execute()
    {
        return $this->resultPageFactory->create();
    }
}

You can see that we have used \Magento\Framework\App\Action\HttpGetActionInterface. It is a method-specific Interface extending ActionInterface.

Performance

In older version of Magento 2(till 2.3), Magento were injecting the \Magento\Framework\App\Action\Context into Actions with a set of following classes:

\Magento\Framework\App\RequestInterface
\Magento\Framework\App\ResponseInterface
\Magento\Framework\ObjectManagerInterface
\Magento\Framework\Event\ManagerInterface
\Magento\Framework\UrlInterface
\Magento\Framework\App\Response\RedirectInterface
\Magento\Framework\App\ActionFlag
\Magento\Framework\App\ViewInterface
\Magento\Framework\Message\ManagerInterface
\Magento\Framework\Controller\Result\RedirectFactory
\Magento\Framework\Controller\ResultFactory

And these classes are no longer injected. It will significantly improve the performance and implementing a method specific interface is a much cleaner approach.

Caution

Keep in mind that some Modules have their own AbstractAction. For example, \Magento\Customer\Controller\AccountInterface additionally handles Customer Authentication.
Controller “Supertypes” are deprecated (\Magento\Backend\App\AbstractAction, \Magento\Framework\App\Action\Action, \Magento\Framework\App\Action\AbstractAction, Magento\Framework\App\Action\Action\AbstractAccount) and you should not use them anymore.
It is recommended to avoid code migration till 2.5.0 since 3-rd party observers may be subscribed to your controllers. Methods like getRequest, getResponse, getActionFlag are eliminated with the inheritance and it will lead to errors when accessing them through controller object from event.
It is recommended to use a new approach for new code only starting 2.4.0 release.
Existing Magento controllers will not be migrated until 2.5.0 to keep backward compatibility.
Please let me know your thoughts about this blog through the comment section below, or write me an email on my email id i.e. admin@asolutions.co.in. Till next time happy coding 🙂

CSP In Magento 2

Ashish Ranade — Thu, 24 Sep 2020 11:38:53 +0000

What is CSP?

CSP is a standard introduced to prevent attacks on your website. Attacks mean an XSS, clickjacking, or malicious code injection. CSP is widely supported by all the modern web browsers and it gives privilege to website owners to approve origins of content that browsers should be allowed to load on that website.

There are two ways that can be used to configure CSP for your website. The first one is by configuring your web server(apache or nGinx to set headers) or another method is to set <meta value on your website. Configuring web servers is beyond the scope of this blog post. Let’s take a look at how Magento configures CSP.

Magento and CSP

CSP was introduced in Magento version 2.3.5 to prevent the loading of malicious scripts on websites. It helps to prevent websites from clickjacking, XSS(cross-site scripting) and session hijacking, and other attacks like that. Magento has a Magento_Csp module while helping to set the policy rules for adminhtml and for the frontend area separately to accommodate different use cases. CSP has two modes. The first one is to report only and another one is restrict mode.

CSP Modes

Report Only Mode: In this mode, Magento only reports the CSP policy violations errors in the console log but it will not act on those errors. It helps whenever you are in developer mode and needs to debug your functionality.
Restrict Mode: In this mode, Magento acts on any policy violations. Magento will restrict the loading of CSS, JS, and inline script which violates the CSP policy.
To configure report-only mode or restrict mode in your Magento application, you need to set the value in your etc/config.xml file.

To enable the restrict mode we will set attribute value report_only to 1, or else if we need to set a report-only model set the report_only attribute value to 0.

Report Only Mode: report_only = 0

Restrict Mode: report_only = 1

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Store:etc/config.xsd">
    <default>
        <csp>
            <mode>
                <storefront>
                    <report_only>0</report_only>
                </storefront>
                <admin>
                    <report_only>0</report_only>
                </admin>
            </mode>
        </csp>
    </default>
</config>

How To Configure CSP for Custom Module

We can add our whitelisted style, scripts, hashes domains in the csp_whitelist.xml file.

<?xml version="1.0"?>
<csp_whitelist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Csp:etc/csp_whitelist.xsd">
    <policies>
        <policy id="script-src">
            <values>
                <value id="<your_unique_id>" type="host">*.domain.com</value>
                <value id="<your_unique_id>" type="host">https://my-custom-domain.com</value>
            </values>
        </policy>
        <policy id="connect-src">
            <values>
                <value id="<your_unique_id>" type="host">https://my-custom-domain-2.com</value>
            </values>
        </policy>
    </policies>
</csp_whitelist>

We have other types of CSP also, in the above example we have declared our whitelist domain under connect-src and script-src. The other types are.

POLICY NAME DESCRIPTION
default-src The default policy.
base-uri    Defines which URLs can appear in a page’s <base> element.
child-src   Defines the sources for workers and embedded frame contents.
connect-src Defines the sources that can be loaded using script interfaces.
font-src    Defines which sources can serve fonts.
form-action Defines valid endpoints for submission from <form> tags.
frame-ancestors Defines the sources that can embed the current page.
frame-src   Defines the sources for elements such as <frame> and <iframe>.
img-src Defines the sources from which images can be loaded.
manifest-src    Defines the allowable contents of web app manifests.
media-src   Defines the sources from which images can be loaded.
object-src  Defines the sources for the <object>, <embed>, and <applet> elements.
script-src  Defines the sources for JavaScript <script> elements.
style-src   Defines the sources for stylesheets.

If the domains are not whitelisted for your script and styles, you may see the following error like “[Report Only] Refused to load the script ‘’ because it violates the following Content Security Policy directive” in your developer console. To resolve this issue we need to add that domain under the whitelisted domain using the csp_whilelist.xml file.

Inline Script Validation

To validate our in-line script, styles, or hashes we can use the SecureHtmlRenderer class from Magento\Framework\View\Helper. We can create an object of this class and use the renderTag method to whitelist our inline script.

/** @var \Magento\Framework\View\Helper\SecureHtmlRenderer */
private $secureRenderer;
function someMethod() {
   ....
   $html .= $this->secureRenderer->renderTag('style', [], "#element { color: blue } ", false);
   ....
}

But, that is implementation from your block class, let’s say if we need to use the same implementation in your phtml file then we need to create a function in your custom block class and pass the SecureHtmlRenderer object through the public method.

<div id="alert-div">Some text value</div>
<?= $secureRenderer->renderEventListenerAsTag('onclick', 'alert("Whitelist me!");', '#alert-div'); ?>

This is all about CSP in Magento 2. Please let me know what you think about this post through the comment section or you can write me an email on my email id i.e. admin@asolutions.co.in. Happy coding :). Thanks!

Profiler in Magento 2

Ashish Ranade — Sat, 19 Sep 2020 15:59:42 +0000

Profiler in simple language can be considered as a program, which helps to check and report the performance of another program. Magento 2 is also using a profiler for the same purpose. If we need to check the performance of any specific script or need to check the performance of a complete page, we can simply enable the profiler and look at the output. Magento 2 provides 2 types of profiles i.e. HTML, CSV.

Enable/Disable profiler
There are two ways to enable profiler in Magento 2. The first way is to enable the profiler using the SetEnv variable, we can set this variable in .htaccess like

SetEnv MAGE_PROFILER <type>
Where can be one of the following HTML or CSV based on your need, or we can set the value at the bootstrapping of Magento application through apache or Nginx servers. If you guys need more information about setting up variables at bootstrapping, please check out this link for more information.

To disable the profile, just comment a SetEnv MAGE_PROFILER from your .htaccess file or from your web server config and restart your web server.

There is another way to enable profiler in Magento 2 i.e. using a CLI.

To enable profiler, navigate to the Magento installation directory as the Magento file system owner, enter the following command to configure the profiler.

php bin\magento dev:profiler:enable <type>
Where can be one of the following HTML or CSV based on your need. To disable the profiler, execute the following command from your Magento root directory.

php bin/magento dev:profiler:disable
Once we enable the profiler in Magento, the application creates a flag file inside <magento_root>/var directory as profiler.flag, this file contains the name of profiler type that we have set through CLI or MAGE_PROFILER variable.

HTML Profiler

We can enable the HTML profiler using the following command

php bin\magento dev:profiler:enable html
This command shows the output in your web browser at the bottom of your page.

Note: Just make sure that you are not using varnish or any other caching mechanism or disable before using the Magento profiler.

If you have enabled the “html” type profiler, then it always display the result on the footer section of a web page. You can see in the following image:

Once we enable the dev:profiler:enable without specifying any param, Magento set HTML as a default profiler type.

We can find more detail about this command in Console/Command/ProfilerEnableCommand.php a class file where TYPE_DEFAULT

Is set as HTML. The output driver class resides under Magento’s profiler module i.e. Magento\Framework\Profiler\Driver\Standard\Output

CSV Profiler

CSV profiler type, it gives another way to check the performance of our application. When we trigger a CLI command dev:profiler:enable csvfile the output will be saved to <project_root>/var/log/profiler.csv. The profiler.csv will be overridden on each page refresh. The output driver class resides under Magento’s profiler module i.e. Profiler/Driver/Standard/Output/Csvfile.php

In output profiler, the columns are as follows: (you can find this variable defined in Profiler/Driver/Standard/Stat.php class as constant variables)

Timer Id: This gives the name of the block of code being executed.
Time: The time it took to complete in seconds.
Avg: The average time it took to complete in seconds.
Count: This represents the number of times this individual block ran to generate the output required.
Emalloc: The amount of memory PHP ( the programming language on which Magento runs) assigned to this single operation. This is again represented in bytes.
RealMem: The actual amount of memory used to perform the operation.
This is all about Magento profiling. Please let me know your thoughts about this blog down in the comment section, or, write me an email on admin@asolutions.co.in . That’s all for now, Happy coding

Code Quality Check in Magento 2

Ashish Ranade — Thu, 30 Jul 2020 12:07:04 +0000

What is GrumPHP?

GrumPHP is a composer library which helps to check the code quality at the time of code commit. GrumPHP creates a git hook before your commit and validates the code quality using the set of rules provided by us(in this case a set of rules provided by Magento). It helps to write the same quality of code as Magento core developers.

Installation of GrumPHP

I am assuming that you have already installed Magento’s latest version and composer into your local system. Now, let’s open our terminal or command prompt, navigate to our Magento root directory and run the following command.

composer require --dev phpro/grumphp

This command will help us to install grumphp with all the dependencies. At the end of the installation, GrumPHP will ask to create a grumphp.yml file type ‘yes/y’ and then in the next step, we need to select the coding standard that we need to follow. For our Magento project select PHPCS.

Now, we need to install other required dependencies like phpcs and phpmd. PHPcs stands for PHP code-sniffer whereas phpmd stands for PHP mess detector.

Execute the following command from our terminal to install these dependencies.

composer require --dev squizlabs/php_codesniffer phpmd/phpmd

Once both the dependencies are installed successfully, it’s time to set our coding standards in a grumphp.yml file. Open grumphp.yml file in any text editor and add the following content.

# grumphp.yml grumphp: tasks: phpcs: standard: "dev/tests/static/framework/Magento/ruleset.xml" tab_width: ~ ignore_patterns: [] phpmd: exclude: [] ruleset: ['dev/tests/static/testsuite/Magento/Test/Php/_files/phpmd/ruleset.xml']

Here, inside the tasks option, we have set the standards for PHPcs and PHPmd. We can add different sets of rules based on our requirements.

Now, to check that our grumphp is working or not, navigate to our Magento root directory and check the git status for any changes using the following command.

git status

Now add the file that we need to commit using the following command

Git add <your-file-name>

You will not get any error or warning message this point of time, because the grumphp hook only works on before commit. Let’s commit our code using the following command.

Git commit -m <your-commit-message>

Once we execute this git commit command the code is validated by the coding standard that we have set inside the grumphp.yml file and it will throw an error message.

Once you resolve all the issues and code quality matches with the standard, you will be able to see the success message.

Grumphp adds a hook before your commit and terminates the process to restrict the code from being committed. This will help to match the code quality and maintain the coding standards as core Magento developers. Your colleagues will also learn to write better code according to the best practices of your team.

Scalar Type Declaration

Ashish Ranade — Mon, 20 Jul 2020 16:16:12 +0000

Today, I like to share some of the key features provided in PHP. The PHP community has introduced some good features like Scalar type declaration, Return type declarations, etc.., which add some extra features to the PHP development, and provides flexibility in the development lifecycle. In this blog, I would like to explain the Scalar type declaration feature, I hope this will help you to improve your knowledge and help you somehow in the future.

Scalar Type Declaration

Type declaration is also known as Type Hinting, allows a function to accept a parameter of a certain type if the given value is not of the correct type (Integer, Float, Boolean, string) PHP will return a fatal error. The older version of PHP (PHP 5) gives a recoverable error while the new release (PHP 7) returns a throwable error.

PHP 7 has introduced the following Scalar type declarations.

1.Boolean
2.String
3.Float
4.Integer
5.Iterable
Scalar Type Declaration comes in two types Coercive(i.e. default), and another one is Strict, if we want to enforce PHP to use a strict type declaration then, we should set the strict value to 1 using a declare directive, please check the example below.

declare(strict_types=1);
Please check the example below for Coercive and Strict type declarations.

Coercive Scalar Type Declaration

try{
     function sum(int …$ints) 
     {
         return array_sum($ints);
     }
}catch(Exception $ex)
{
   echo $ex->getMessage();
}
print(sum(2, ‘3’, 4.1));

In the above example just want to highlight one thing i.e. we are not using a strict value for parameter type like 2 of Integer type, 3 of String type 4.1 of Float type. The above code will output the value int(9).

Strict Scalar Type Declaration

declare(strict_types=1);
try {
      function sum(int …$ints) 
      {
         return array_sum($ints);
      }
} catch (Exception $ex) 
{   
   echo $ex->gt;
   getMessage();
}
print(sum(2, ‘3’, 4.1));

Note that, if we declare the strict_type value to 1, the above code will output “Fatal error: Uncaught TypeError: Argument 2 passed to sum() must be of the type integer, string is given”.

The above code will help us to enforce the other developer to use a variable of strict type i.e. Integer, Float, etc.

Use of Scalar Type Declaration

The scalar type declaration can be used in different areas of development, like, defining strict values in an interface, so that, the child class which is overriding the interface must follow the strict type.

I hope that will help you somehow. Feel free to leave a comment below. Let me know what you think about this