Adobe Commerce Developer Professional key terms

The top-level folder of an Adobe Commerce installation that contains app, bin, lib, pub, and vendor directories. All paths in configuration and code are resolved relative to this location.

A PHP configuration file holding deployment-specific settings such as database credentials, cache backends, and encryption keys. It is generated at install time and is not committed to version control.

A PHP file listing installed modules, their enabled or disabled state, and the active theme. It is generated by setup commands and is typically committed to version control.

The process of declaring a module by placing a registration.php file in its folder and a module.xml file under etc. Registration makes the module discoverable; enabling it happens separately via setup commands.

A configuration file inside a module's etc folder that declares the module's name, version, and dependencies on other modules. Dependency order controls load and setup sequence.

A design pattern where an object receives its collaborators from an external configurator rather than creating them itself. Adobe Commerce builds these objects from XML configuration and caches the resulting factories.

XML files that configure the object manager: constructor argument values, shared versus new instances, virtual types, and preferences. They can be defined globally per area or per module.

The framework service that instantiates classes, resolves their constructor dependencies, and applies di.xml configuration. Direct use in business code is discouraged in favor of injected dependencies.

A di.xml declaration that substitutes one class for another when a given type is requested. It is the standard mechanism for replacing a core implementation with a custom one.

A di.xml construct that defines a named variation of an existing class with different constructor arguments, without creating a new PHP class. Useful for sharing a class with multiple configurations.

A logical context such as frontend, adminhtml, webapi, or crontab that determines which configuration files and di.xml instructions load. Areas keep behavior scoped to the request type being handled.

A class that wraps a public method of another class to run code before, after, or around it, configured in di.xml. Plugins modify behavior without editing the original class.

The ordered sequence of plugins applied to a single method. Sort order values determine execution sequence, and around plugins can stop the chain by not calling the proceed callback.

A class that reacts to a dispatched event, declared in events.xml for a given area. Observers run after the event fires and are suited to side effects rather than altering return values.

Configuration file that maps event names to observer classes, scoped by area. It is the declaration point for event-driven customizations.

A versioned PHP class implementing DataPatchInterface that modifies data or schema once and is recorded in the patch registry. Patches replace older install and upgrade script conventions.

A db_schema.xml-based approach where developers declare the desired final database structure and Adobe Commerce generates the diff. It replaces imperative install and upgrade schema scripts.

The declarative schema file in a module's etc/db_schema.xml that defines tables, columns, indexes, and foreign keys. Running setup upgrade compares it against the live database.

A data model storing attributes as rows rather than columns, letting entities such as products have varying attribute sets. Values are split across backend tables by attribute data type.

A named grouping of EAV attributes assigned to entities like products. The set determines which attributes an entity has and which edit fields appear in admin forms.

The unique machine-readable identifier for an EAV attribute, used in code, queries, and import files. It is distinct from the human-readable frontend label.

A class referenced by an EAV attribute that handles loading and saving its value, and often validation. Different backend models are used for varchar, int, decimal, datetime, and text attributes.

A class supplying the allowed options for an EAV attribute, such as a dropdown's choices. It returns a value-label array consumed by admin forms and filters.

An optional denormalized table where product or category data is copied into columns for faster reads. It must be reindexed when source data changes.

A process that precomputes derived data such as prices, search data, or flat tables into storage tables. Indexers run on save, on schedule, or manually via the command line.

The service contract pattern where an interface defines data operations and a repository class implements it. Code should depend on the interface, with concrete classes bound via di.xml preferences.

A stable, versioned PHP interface in a module's Api folder that exposes business operations to other modules and integrations. It decouples callers from implementation details.

Files under view//layout that declare blocks, containers, and handles for a page. Handles are merged per request to build the page structure.

A named layout instruction set, such as default, cms_index_index, or a custom handle, that is applied when the request matches. Multiple handles merge in a defined order.

A PHP view class that prepares data for a template and participates in the layout. Blocks are declared in layout XML and rendered by their associated phtml template.

A PHP-rendered HTML file in a module or theme that outputs markup using data supplied by its block. Templates should escape output to prevent cross-site scripting.

A theme's declaration of a parent theme in theme.xml, causing it to inherit layouts, templates, and static assets. Child themes override only the files they replace.

A theme's metadata file declaring its title, parent theme, and preview image. It establishes inheritance and identifies the theme to the system.

A command-line step that publishes theme assets such as CSS, JavaScript, and images into the pub/static folder for the chosen locales and areas. It must run after theme changes.

A named cache segment such as config, layout, block_html, or full_page that can be enabled, disabled, or flushed independently. Disabling types aids development but hurts performance.

The configuration hierarchy of global, website, store, and store view levels. Settings can be overridden at narrower scopes, and resolved values depend on the current scope.

A module's file defining admin configuration fields, groups, and sections, including their scope and defaults. Values are read at runtime through the scope config interface.

A presentation-level scope with its own locale, currency display, and theme. Multiple store views can share one website and catalog while differing in language or design.

Bin commands such as setup:upgrade, setup:di:compile, setup:static-content:deploy, and cache:flush that apply configuration, generate code, and refresh state after changes.