Modules are a vital architectonical component that, together with language packages, libraries and themes, defines the ecosystem of a Magento platform.
The module’s task is to provide a defined functionality or extend a pre-existing business logic. It’s important to make sure each module is responsible for a single functionality and to not let its dependencies arch out to different modules.
In keeping with Magento's commitment to optimal modularity, a module encapsulates one feature and has minimal dependencies on other modules.
You can find detailed information on modules in Magento documentation here:
A module contains XML configuration files and PHP files, also known as models, blocks or controllers. Each of them fulfills its role in an MVVM (Model, View, ViewModel) design pattern.
In most cases, modules can be found in a vendor folder, in a location Magento is installed in. They can also be kept and developed in Magento’s root directory in
app/code/vendor-name/module-name (for example: app/code/Snowdog/Academy).
Here’s an example of the structure of a module in a module-cms case:
Api — define service interfaces and data interfaces
Block — here you can find view classes
Controller — contains controller classes, which are responsible for user’s interactions with the system
etc — configuration files of a given module
Helper — classes with helper methods, which can be used in each layer of an application
i18n — translations
Model — Models and ResourceModels of data — a Model is a class representing an entire entity or a record from a database. A ResourceModel is a class that allows models to communicate with a database by fetching and saving information.
Observer — observer classes are executed on various system events. Usually, when a given event is dispatched in a system, for example, making an order, the observer creates a model instance to perform a particular business logic (for example, after making an order, send an order confirmation email to the customer)
Setup — classes responsible for updating tables and relations in databases and Data Patches. Because of them, we are able to update, add and delete data (for example, adding a new product attribute). More details about the mechanism here: https://devdocs.magento.com/guides/v2.4/extension-dev-guide/declarative-schema/data-patches.html
Test — unit tests along with definitions of those tests
UI — user interface elements (for example a grid or a form)
view — static view files (phtml)
More details on files in module structure can be found in documentation here: https://devdocs.magento.com/guides/v2.4/extension-dev-guide/build/module-file-structure.html
Defining and activating the module
All you need in order to activate a Snowdog_Academy module that does not yet contain any functionality is:
- registration.php file — place it in the
app/code/Snowdog/Academydirectory, where you can register the module by providing its name and information that the object that’s being registered is a module. We use the following style — Snowdog as the name of the organization or a developer who created the module and module-academy as the module name, which outlines its main use.
- module.xml file, which you can place in:
app/code/Snowdog/Academy/etcwhere you also have to provide the module name and its version (starting from 1.0.0)
After clearing the cache (you have to execute the php bin/magento cache:clean command in the directory where Magento is installed), your new module named Snowdog_Academy will be visible on the list of available Magento modules.
This blogpost is part of the Snowdog Academy series which will help you to become a Junior Magento Developer.
