Advanced module.xml Attributes
Beyond the basics, module.xml supports several advanced attributes for module control.
Complete module.xml schema:
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
<module name="Vendor_Module" setup_version="1.2.0" component_type="module">
<sequence>
<module name="Magento_Catalog"/>
<module name="Magento_Inventory"/>
</sequence>
<suggest>
<module name="Magento_Elasticsearch"/>
</suggest>
</module>
</config>
Attributes explained:
| Attribute | Description | Default |
|---|---|---|
name |
Module identifier (Vendor_Module) | Required |
setup_version |
Schema/data version for upgrades | Required |
component_type |
Type of component (module/theme/language) | module |
sequence |
Hard dependencies (must load first) | Empty |
suggest |
Soft dependencies (optional) | Empty |
component_type values:
module— Standard PHP module (most common)theme— Magento theme componentlanguage— Translation packagelibrary— Shared library component
Example — Language package:
<module name="Vendor_Module_de_DE" component_type="language" setup_version="1.0.0">
<sequence>
<module name="Vendor_Module"/>
</sequence>
</module>
Sequence Dependencies Deep Dive
Understanding how sequence dependencies affect module loading, upgrades, and configuration.
Dependency resolution order:
1. Magento_Store (always first)
2. Magento_Directory
3. ... other core modules ...
4. Your module's dependencies
5. Your module
What sequence affects:
1. Load order:
php bin/magento module:status --dependencies
# Shows the resolved dependency order
2. Schema upgrade order:
- Dependencies upgrade BEFORE your module
- Your module upgrades AFTER dependencies
- Ensures tables/columns exist before you reference them
3. Configuration merge order:
- Dependencies' XML files merge first
- Your XML files merge second
- Your config can override dependency config
4. Code generation order:
- Dependencies are compiled first
- Generated classes are available for your module
Dependency pitfalls:
<!-- BAD: Circular dependency -->
<!-- Module A depends on B -->
<module name="Vendor_A">
<sequence><module name="Vendor_B"/></sequence>
</module>
<!-- Module B depends on A -->
<module name="Vendor_B">
<sequence><module name="Vendor_A"/></sequence>
</module>
<!-- GOOD: Unidirectional -->
<module name="Vendor_A">
<sequence><module name="Vendor_B"/></sequence>
</module>
<module name="Vendor_B">
<!-- No dependency on A -->
</module>
Soft vs Hard dependencies:
<!-- Hard: Module MUST exist and load first -->
<sequence>
<module name="Magento_Catalog"/>
</sequence>
<!-- Soft: Module MAY exist, enhances functionality -->
<suggest>
<module name="Magento_Elasticsearch"/>
</suggest>
Check dependency chains:
# Full dependency tree
php bin/magento module:status --dependencies | grep -A 5 Vendor_Module
Setup Scripts and Version Management
Setup scripts handle database schema creation and data migration.
Setup script locations:
app/code/Vendor/Module/Setup/
├── InstallSchema.php # First installation
├── UpgradeSchema.php # Schema changes per version
├── InstallData.php # Initial data seeding
├── UpgradeData.php # Data changes per version
├── Recurring.php # Runs on every setup:upgrade
└── Patch/
└── Data/
└── AddCustomAttribute.php # Data patches (2.4+)
InstallSchema.php:
<?php
namespace Vendor\Module\Setup;
use Magento\Framework\Setup\ModuleContextInterface;
use Magento\Framework\Setup\SchemaSetupInterface;
class InstallSchema implements \Magento\Framework\Setup\InstallSchemaInterface
{
public function install(SchemaSetupInterface $setup, ModuleContextInterface $context)
{
$setup->startSetup();
$table = $setup->getConnection()->newTable(
$setup->getTable('vendor_module_items')
)
->addColumn(
'entity_id',
\Magento\Framework\Db\Ddl\Table::TYPE_INTEGER,
null,
['identity' => true, 'unsigned' => true, 'nullable' => false, 'primary' => true],
'Entity ID'
)
->addColumn(
'name',
\Magento\Framework\Db\Ddl\Table::TYPE_TEXT,
255,
['nullable' => false],
'Name'
);
$setup->getConnection()->createTable($table);
$setup->endSetup();
}
}
UpgradeSchema.php:
public function upgrade(SchemaSetupInterface $setup, ModuleContextInterface $context)
{
$setup->startSetup();
if (version_compare($context->getVersion(), '1.1.0', '<')) {
$setup->getConnection()->addColumn(
$setup->getTable('vendor_module_items'),
'description',
[
'type' => \Magento\Framework\Db\Ddl\Table::TYPE_TEXT,
'nullable' => true,
'comment' => 'Description'
]
);
}
$setup->endSetup();
}
Module State and Management
Managing module state through command line and database.
Module status commands:
# List all modules and their status
php bin/magento module:status
# Enable a module
php bin/magento module:enable Vendor_Module
# Disable a module
php bin/magento module:disable Vendor_Module
# Check specific module status
php bin/magento module:status Vendor_Module
# Enable with dependency check
php bin/magento module:enable Vendor_Module --force
Disabled flag in module.xml:
<!-- Module is disabled in XML (not recommended) -->
<module name="Vendor_Module" setup_version="1.0.0" disabled="true">
<sequence>
<module name="Magento_Catalog"/>
</sequence>
</module>
Module state in database:
-- Check module version in DB
SELECT * FROM setup_module WHERE module = 'Vendor_Module';
-- Module enabled/disabled state
SELECT * FROM module_status WHERE module = 'Vendor_Module';
-- Force module state
UPDATE module_status SET is_enabled = 1 WHERE module = 'Vendor_Module';
Module registration lifecycle:
1. Create module files (module.xml, registration.php)
2. Run php bin/magento module:enable Vendor_Module
3. Run php bin/magento setup:upgrade
4. Module appears in generated code
Removing a module:
# Disable module
php bin/magento module:disable Vendor_Module
# Remove database tables (manual)
# Run setup:upgrade to clean up
php bin/magento setup:upgrade
# Clean generated code
rm -rf generated/code/Vendor/Module/
php bin/magento setup:di:compile
Common module issues:
# Module not appearing
php bin/magento module:status | grep Vendor_Module
# Check: registration.php exists? module.xml exists?
# Version mismatch
php bin/magento setup:upgrade
# Check setup_version matches DB record
# Dependency not found
php bin/magento module:status --dependencies
# Ensure dependency module is installed and enabled
Quiz
1. What does component_type attribute in module.xml control?
2. What is the difference between sequence and suggest in module.xml?
3. When does Magento run UpgradeSchema.php?
4. How do you check a module's version in the database?
Flashcards
Question
What are the valid component_type values?
Click to reveal answer
Answer
module, theme, language, library
Question
What does sequence in module.xml ensure?
Click to reveal answer
Answer
Dependencies load and upgrade before your module
Question
Where are setup scripts located?
Click to reveal answer
Answer
Vendor/Module/Setup/ (InstallSchema.php, UpgradeSchema.php, etc.)
Question
How do you enable a module via CLI?
Click to reveal answer
Answer
php bin/magento module:enable Vendor_Module
Question
What table tracks module versions?
Click to reveal answer
Answer
setup_module
Revision Notes
Key Takeaways
- 1. module.xml supports component_type for module/theme/language/library
- 2. Sequence ensures dependencies load and upgrade first
- 3. Suggest indicates optional dependencies
- 4. Setup scripts run when setup_version increases
- 5. Module state is managed via CLI commands and database records
- 6. setup_module table tracks installed versions
Interview Tips
- • Explain the difference between hard and soft dependencies
- • Describe the module upgrade lifecycle
- • Know how to enable/disable modules via CLI
- • Understand component_type and when to use each
Cheat Sheet
module.xml Deep Dive Cheat Sheet
Attributes:
- name: Vendor_Module
- setup_version: 1.0.0
- component_type: module/theme/language/library
- disabled: true/false
Elements:
- sequence: Hard dependencies (must load first)
- suggest: Soft dependencies (optional)
Setup scripts:
- InstallSchema.php: First install
- UpgradeSchema.php: Schema changes
- InstallData.php: Initial data
- UpgradeData.php: Data changes
- Recurring.php: Every setup:upgrade
CLI commands:
- module:enable/disable/status
- setup:upgrade (runs setup scripts)
- setup:di:compile (generates code)