Magento 2 Certified Professional Developer Guide

How can you override native files?

In order to override the parent theme files, put the file in the current theme folder at the same path it was located in the parent theme. Example:

If you need to override a file in the parent theme /Magento_Catalog/templates/product/view/gallery.phtml, then create a file in the child theme /Magento_Catalog/templates/product/view/gallery.phtml.

In order to override module’s view files, create them at the same path as they were located in the module’s view folder, but deleting from the path and adding the module name. Example:

If we want to override the module file vendor/magento/module-catalog/view/frontend/templates/product/view/gallery.phtml, create a file in the theme

/Magento_Catalog/templates/product/view/gallery.phtml

This method overrides templates files and all the files in web folder. However, if you try to override the layout file the following way, instead of overriding the parent theme file will be added up to. To learn more about the layout files override in Magento 2, follow the link

(https://belvg.com/blog/override-a-layout-in-magento-2.html)

3.2 Determine how to use blocks

Demonstrate an understanding of block architecture and its use in development

Blocks are PHP classes that provide data for template files (.phtml) and implement rendering. Also, blocks can cache the results of template rendering.

Which objects are accessible from the block?

All blocks extend \Magento\Framework\View\Element\Template, so by default blocks are injected with a \Magento\Framework\View\ Element\Template\Context object and support getters and setters for returning and storage of any objects or data. This object contains a number of other objects that are loaded into the instance:

• $this->validator: \Magento\Framework\View\Element\Template\File\Validator
• $this->resolver: \Magento\Framework\View\Element\Template\File\Resolver
• $this->_filesystem: \Magento\Framework\Filesystem
• $this->templateEnginePool: \Magento\Framework\View\TemplateEnginePool
• $this->_storeManager: \Magento\Store\Model\StoreManagerInterface
• $this->_appState: \Magento\Framework\App\State
• $this->pageConfig: \Magento\Framework\View\Page\Config

What is the typical block’s role?

Separation of blocks and templates allows you to divide design related logic and design. Blocks are usually, but not always, connected to PHTML template files. Blocks can be thought of as data containers for a template, which represents a piece of the HTML on the page. In layouts XML, you can manage blocks on page and add new ones, set templates to move and delete.

Identify the stages in lifecycle of a block

The block life cycle consists of two phases: generating blocks and rendering blocks. Blocks are instantiated at the moment the layout is created. They are not executed at that time, just instantiated. Also during this phase, the structure is built, the children of blocks are set, and for each block, the prepareLayout() method is called. However, rendering occurs in the later rendering phase.

Generating phase:

1. Magento\Framework\View\Page\Config::publicBuild()
2. Magento\Framework\View\Page\Config::build()
3. Magento\Framework\View\Layout\Builder::build()
4. Magento\Framework\View\Layout\Builder::generateLayoutBlocks()
5. Magento\Framework\View\Layout::generateElements()
6. Magento\Framework\View\Layout\GeneratorPool::process()

GeneratePool goes through all generators and generates all scheduled elements. It has generators with the following elements:

Magento\Framework\View\Page\Config\Generator\Head

Magento\Framework\View\Page\Config\Generator\Body

Magento\Framework\View\Layout\Generator\Block

Magento\Framework\View\Layout\Generator\Container

Magento\Framework\View\Layout\Generator\UiComponent

Rendering phase:

1. Magento\Framework\View\Result/Page::render()
2. Magento\Framework\View\Layout::getOutput()

At this moment, we already have all the layout xml for the generated page, and all block classes are created.

1. Magento\Framework\View\Layout::renderElement()
2. Magento\Framework\View\Layout::renderNonCachedElement()

In this method, we check the type of rendered elements. It creates them and returns html using toHtml() method. This method is not recommended to override. If you want to change block rendering, override _toHtml() method.

In what cases would you put your code in the _prepareLayout(), _beforeToHtml(), and _toHtml() methods?

_prepareLayout() – most often used for:

• adding child’s Magento\Eav\Block\Adminhtml\Attribute\Edit\Options\AbstractOptions::_prepareLayout()
• adding tabs on backend Magento\Backend\Block\System\Design\Edit\Tabs::_prepareLayout()
• set title Magento\Wishlist\Block\Customer\Sharing::_prepareLayout()
• adding pager, breadcrumbs and so on Magento\Sales\Block\Order\History::_prepareLayout()
• set renderer Magento\Catalog\Block\Adminhtml\Form::_prepareLayout()

_beforeToHtml()

• data preparing Magento\Catalog\Block\Product\ProductList\Related::_beforeToHtml()
• assign values Magento\Backend\Block\Widget\Form\Element::_beforeToHtml()
• adding child’s

Magento\Shipping\Block\Adminhtml\Create\Items::_beforeToHtml()

_toHtml()

Using this method, you can manipulate block rendering, complement the condition, make wrappers for html, change the template for the block, etc.

Magento\GroupedProduct\Block\Order\Email\Items\Order\Grouped::_toHtml() , Magento\Sales\Block\Reorder\Sidebar::_toHtml()

How would you use events fired in the abstract block?

view_block_abstract_to_html_before – use for editing params:

• templates
• caches
• grids

view_block_abstract_to_html_after – use for html manipulation – editing, adding conditions, wrappers

Describe how blocks are rendered and cached

The most important method for rendering a block is Magento\Framework\View\Element\AbstractBlock::toHtml(). First, it runs _loadCache(), and if the cache is missing, then it run _beforeToHtml() after the block is rendered by the method_toHtml(). Afterward, the cache is saved _saveCache($html) and run _afterToHtml($html).

Method _loadCache() uses cache_key return by getCacheKey() and _saveCache($html) – cache_tags obtained by the method getCacheTags(). Cache_key each block is added up like BLOCK_CLASS::CACHE_KEY_PREFIX. $cache_key , if this property not defined – BLOCK_CLASS::CACHE_KEY_PREFIX . sha1(implode(‘|’, $this->getCacheKeyInfo())). Cache_tags is an array and consists of a property $cache_tags, if it defined in block and if block instance of Magento\Framework\DataObject\IdentityInterface values returned by the method getIdentities() are added to the array. We can manage $cache_lifetime variable. Value will be in seconds, if you want to disable cache, you can set value to 0 or not set the value at all, because all blocks are non-cacheable by default.

Identify the uses of different types of blocks

• Magento\Framework\View\Element\AbstractBlock – parent block for all custom blocks
• Magento\Framework\View\Element\Template – block with template
• Magento\Framework\View\Element\Text – just rendering text
• Magento\Framework\View\Element\FormKey – return hidden input with form key
• Magento\Framework\View\Element\Messages – rendering notification message by type

When would you use non-template block types?

Applying non-template block types is wise when we use simple renderers. Another reason for using such block types is when block content is dynamic generated or stored in database or in containers. For example, if you want form_key in template, you can insert block Magento\Framework\View\Element\FormKey.

In what situation should you use a template block or other block types?

Using a template block or other block types is recommended when complicated renderers are used, or when you want to customize themes or add new blocks. А prime example is a breadcrumbs block Magento\Catalog\Block\Breadcrumbs. If you want to customize breadcrumbs, you can set template in layout.

3.3 Demonstrate ability to use layout and XML schema

Describe the elements of the Magento layout XML schema, including the major XML directives. How do you use layout XML directives in your customizations?

Magento layouts contain instructions that allow to:

• Add and delete static resources (JavaScript, CSS, fonts) into the head section of the page;
• Create and modify containers;
• Create and modify blocks;
• Set the templates for blocks;
• Pass arguments into blocks;
• Change the location of the elements (blocks and containers);
• Change elements’ order (blocks and containers);
• Delete elements (blocks and containers).

Let us examine the cases of each instruction application:

Adding and deleting static resources

To add static resources to the page, first create default_head_blocks.xml file at the following path: /Magento_Theme/layout/default_head_blocks.xml.

Add a CSS file with the following instruction:

To add a locally located JavaScript file, use one of the following instructions:

In case you need to initialize JS module with connection to HTML Element, there are two ways to do this:

1) Use data-mage-init attribute of the element, to which the component should be connected. For example:

2) Use

Initialization in PHTML template is commonly used to pass parameters from php to javascript module. But we can also initialize javascript module in another javascript file.

Example:

vendor/magento/module-swatches/view/adminhtml/web/js/visual.js

…
$('[data-role=swatch-visual-options-container]').sortable({
   distance: 8,
   tolerance: 'pointer',
   cancel: 'input, button',
   axis: 'y',
   ....
   }
});
...