Adobe Commerce Front-End Dev Expert cheat sheet

Theme inheritance: a theme's parent is declared in theme.xml ; child themes override parent files by identical path, and fallback order is child, parent, then module view directories.

Layout XML merge order per handle: module layout files load first, then theme layout files; within the same stage, later files override earlier ones for the same element name.

Handle naming: default, then page-type handles (cms_page, catalog_product_view, checkout_cart_index), then route/controller/action handles such as catalog_product_view_id_123.

and modify existing nodes; and create new nodes; reorders, deletes, and display="false" hides without removing.

Layout arguments: with pass data to blocks; calls a setter at block instantiation.

Container vs block: containers render children only and have no template; blocks require a template or renderer to output HTML.

Layout updates are cached per page; changing layout XML requires a cache clean of layout, block_html, and full_page caches to appear.

theme.xml also defines , <media> preview image, and <parent>; registration.php registers the theme via ComponentRegistrar::THEME.</p>

Block template resolution: getTemplate() path is resolved against the theme directory chain; $block->getTemplateFile() returns the resolved absolute path.

Escaping rule: use $block->escapeHtml(), escapeHtmlAttr(), escapeUrl(), or escapeJs() for output; __() handles translation and should wrap user-facing strings.

View models are plain PHP classes passed via Model\Class; they are not blocks and hold no template.

Block caching is controlled by the cacheable attribute and getCacheKeyInfo(); a false cacheable attribute disables block_html caching for that block.

Phtml templates receive $block (the block instance) and $this (the template engine); $escaper is available in templates as a helper alias.

Child blocks render via $block->getChildHtml('alias'); getChildBlock('alias') returns the block for direct method calls.

Template hints are enabled per store view under Advanced > Developer > Debug; they append block name and template path as HTML comments.

Blocks extend AbstractBlock; data access uses getData()/setData(), and getData('key') falls back to the block's declared arguments.

Knockout bindings in Magento use data-bind attributes; the component is initialized by the x-magento-init or data-mage-init script tag with a selector.

x-magento-init maps a CSS selector (or *) to a JS module config object; data-mage-init applies to the single element and takes a JSON config.

UI components extend Knockout via uiComponent; the component's defaults come from the module's view config (view/frontend/web/js/... and view config .xml).

Observables: ko.observable() for values, ko.observableArray() for lists; use ko.computed() for derived values and subscribe() for side effects.

Component registration: define([...], function(...){ return Component.extend({ defaults: {...}, initialize: function(){...} }); });

The 'ko' module is provided by Magento; require(['ko', 'uiComponent'], ...) is the standard AMD import for UI components.

Cart and checkout UI use the quote item provider and totals collectors; custom totals require a JS total component plus a PHP TotalCollector.

Custom bindings register via ko.bindingHandlers.name = { init, update }; Magento's scope binding 'scope' is used for component ownership.

LESS compilation: Magento compiles .less files under web/css/source into pub/static; variables and mixins come from lib/web/css/source/lib/ and theme _variables.less.

Theme LESS fallback: a theme's web/css/source/_extend.less imports additional rules; _module.less files override module styles.

Static file deployment: bin/magento setup:static-content:deploy -f compiles and publishes assets; -l lists locales, and --theme/--area restrict scope.

Static versioning: dev/static/sign appends a version hash to static URLs; disabling it removes ?version= query strings from asset URLs.

Asset URL helpers: $block->getViewFileUrl('Vendor_Module::path') resolves the theme-aware URL for images, JS, and CSS.

Responsive breakpoints use @screen__m (768px), @screen__l (1024px), @screen__xl (1440px) variables from the blank theme.

CSS critical path: critical.css is inlined for the initial viewport; the remaining styles load asynchronously via media=print onload swap.

RequireJS config: map and paths in requirejs-config.js merge across modules; a theme can override module JS by placing a file at the same relative path.

FPC (full_page cache) stores rendered HTML per URL and customer segment; it is bypassed for logged-in customers unless a customer segment or private content block is used.

Private content in FPC pages loads via customer-data JS and section XML (sections.xml) declaring the AJAX endpoint per section.

Cache types: config, layout, block_html, collections, reflection, db_ddl, eav, full_page, translate; bin/magento cache:clean flushes by type.

Block cache lifetime is set by getCacheLifetime() (default null = infinite) and invalidated by cache tags from getCacheTags().

Varnish sits in front of Magento; cache invalidation is pushed via the purge endpoint configured under cache/varnish settings.

JS bundling (dev/js/enable_js_bundling) and merging (dev/js/merge_files) are disabled by default in production mode and generally not recommended.

Production mode disables on-the-fly LESS compilation and static file materialization; static content must be pre-deployed.

Image optimization: use the image resize helper or view.xml image dimensions; srcset/sizes are emitted by the responsive image helper in product galleries.

Checkout is a single-page UI component (Magento_Checkout/js/view) with steps: shipping, shipping method, payment, billing; each step is a Knockout component.

Cart totals are collected by PHP TotalCollector classes registered in sales.xml and rendered by JS totals components in the checkout/cart UI.

Quote item options and custom attributes are added via the quote item repository; the cart API endpoint is /rest/V1/carts/mine/items.

Shipping method rendering uses the shipping method component; carriers declare methods in config.xml under default/carriers.

Payment method rendering: the payment method's JS renderer is declared in the method's di.xml or the checkout config; it must provide getCode() and validate().

Checkout layout: checkout_cart_index, checkout_index_index, and checkout_onepage_success handles control the cart, checkout, and success pages.

Custom checkout fields are added as a UI component in the checkout layout XML; data is persisted via the quote's extension attributes or additional data.

Order placement flow: the checkout JS calls the payment method's placeOrder(), which submits to the order service; failures surface via the message container.