A module’s configuration files are stored in your modules etc/ directory,
like app/code/Kaushik/HelloWorld/etc/. In there, you will find several important files.
Many of these files can be found in a module’s etc/ directory. However, you sequester these to a particular area (frontend, adminhtml, webapi_rest, as a couple of examples). This is useful if you want a particular modification to only affect a particular area. For example, let’s say you want to prevent a payment method from being used on the frontend. You would configure an event observer in etc/frontend/events.xml (notice the frontend directory = the frontend area code) to observe the payment_method_is_active event. You would then create a class for this observer that implements the ObserverInterface.
These are the most common ones:
module.xml: this file defines the module and what modules on which your module depends.acl.xml: this creates permissions that can be referenced in a module. An admin can enable/disable these permissions for a particular role.catalog_attributes.xml: this instructs Magento to automatically load specified attributes for particular entities. These attributes are usually installed by the module (in a Data Patch, in your module’sSetup/Patch/Data/directory).config.xml: this file stores default values for Stores > Configuration values that you configure inetc/adminhtml/system.xml.crontab.xml: this is where you configure scheduled jobs.db_schema.xml: this is how you add and update tables in the database. The sister file,db_schema_whitelist.jsonwill be also stored in theetc/directory.di.xml: this file contains plugin details and configuration of Magento’s Dependency Injection framework.email_templates.xml: this is where you configure email templates and their associated.htmltemplate.events.xml: when you need functionality to execute in response to an action taken in Magento, creating an event observer may be the best solution.
In this file, you configure what classes + methods response (observe) a given event. This file can also be placed into a particular area’s directory (frontendfor example) to limit when this observer is triggered.extension_attributes.xml: this file configures extension attributes. Magento has many models created (Order, Order Item, Customer, etc.). There are many cases in which you want to attach more information (“have we exported this order to our ERP?”). Each extension attribute has a type (bool,string,OrderDetailsclass, as examples). Classes that can use extension attributes extend\Magento\Framework\Model\AbstractExtensibleModel.adminhtml/menu.xml: this adds and customizes the Magento admin menu.product_options.xml: this configures new types of custom options for a Magento product. For example, you can use an entry in this file to create a “Length” attribute for custom-sized products.product_types.xml: this is where you set up a new product type. For example, if you need to create a new Kit product type (as a modification of a Grouped product), you would configure that in this file.sales.xml: adds a new total, for example, a “fee.”system.xml: this adds new entries into Stores > Configuration.webapi.xml: this configures a new API request route.widget.xml: this configures a new CMS widget.routes.xml: this file tells Magento about a URL path that your module will understand. We will talk about this more later but for now, when you browse tobkaushik.com/cms/page/view/id/1, the routefrontName(for the sake of consistency,idshould match) would becms. This matches the first word in the path.
One thing to note: thefrontNameandidcan be different. frontName determines the word(s) that are matched in the URL. Theidis used to create the Layout XML handle. In the above example, if this is a code snippet:<route id="content_management_system" frontName="cms">
...
</route>Our layout XML file to accommodate this request would be:
app/code/Kaushik/HelloWorld/view/frontend/layout/content_management_system_page_view.xml