1.02 وصف هيكل الموديول

text20 min

1.02 وصف هيكل الموديول

Do not memorize files first. Understand the job of a module.

A Magento module is a self-contained unit of functionality. The easiest way to understand module structure is to ask:

How does Magento recognize the module, load its PHP classes, and understand its dependencies?

The three ideas you need

  • Identity: Magento knows the module as Vendor_Module.
  • Namespace: PHP code uses Vendor\Module.
  • Location: A custom module usually lives in app/code/Vendor/Module.

So if you see Bonlineco_Blog in Magento config, the matching PHP namespace is usually Bonlineco\Blog.

Think of a module like a packaged feature

A module is not just a folder. It is a feature package with three responsibilities:

  • Tell Magento it exists.
  • Tell Composer how PHP classes should autoload.
  • Tell Magento what other modules it depends on.

The required files, explained simply

1. registration.php

This is the “I exist” file. Without it, Magento will not properly register the module.

php
1<?php
2use Magento\Framework\Component\ComponentRegistrar;
3
4ComponentRegistrar::register(
5    ComponentRegistrar::MODULE,
6    'Vendor_Module',
7    __DIR__
8);

2. composer.json

This explains package metadata, dependencies, and PSR-4 autoloading. For exam thinking, remember two things:

  • It should declare "type": "magento2-module".
  • It maps the namespace such as Vendor\\Module\\ to the module path.
json
1{
2  "name": "vendor/module-name",
3  "type": "magento2-module",
4  "autoload": {
5    "psr-4": {
6      "Vendor\\Module\\": ""
7    },
8    "files": [
9      "registration.php"
10    ]
11  }
12}

3. etc/module.xml

This is where Magento sees the module name and dependency sequence.

xml
1<?xml version="1.0"?>
2<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3        xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
4    <module name="Vendor_Module">
5        <sequence>
6            <module name="Magento_Cms"/>
7        </sequence>
8    </module>
9</config>

How to reason about sequence

If your module depends on behavior from another module, Magento needs to load things in a safe order. That is why <sequence> matters.

Do not think of sequence as “random XML.” Think of it as dependency order.

When should you create a new module?

  • When you are adding a real feature, not just changing one tiny line.
  • When you want custom code separated by business area.
  • When you need to customize or extend another module cleanly.
  • When a theme needs supporting PHP, layout XML, or view models.

The install flow that the exam likes

After creating the required files, the normal flow is:

bash
bin/magento module:enable Vendor_Module
bin/magento setup:upgrade

module:enable marks the module as enabled.

setup:upgrade synchronizes Magento with the module, updates setup state, and runs needed schema/data work.

What about --keep-generated?

Use it carefully. It can save time, but if your changes affect generated code behavior such as plugins or extension attributes, stale generated classes can hide your real changes.

If you are unsure, clean rebuild is safer than chasing a fake bug.

Memory shortcut

  • registration.php = register the module
  • composer.json = package + autoload rules
  • etc/module.xml = module name + dependency sequence

Reference notes: MageForge Topic 1.02 Documentation