Adobe Commerce Front-End Dev Expert common mistakes
Adobe Commerce Front-End Dev Expert · Understand the traps and how to avoid them.
Editing files directly inside vendor/ or pub/static instead of the theme source, then losing the change after a deploy or static content redeploy.
Candidates confuse the deployed static output and third-party packages with the editable theme source; the exam tests knowledge of the theme file hierarchy and how static files are generated.
What to do instead
Make changes only in app/design/frontend/// (and module view/ directories), then regenerate with bin/magento setup:static-content:deploy and clear cache. Treat pub/static as build output, never as a source.
Declaring a new block or container in a layout XML without the correct parent reference, so the element silently never renders.
Layout XML merges by reference name; candidates assume nesting in the file implies hierarchy, but an element only attaches where its parent reference exists in the merged layout.
What to do instead
Use or with a parent that actually exists in the merged layout, verify with bin/magento dev:xml:convert or layout debugging, and confirm the block appears in the rendered page source.
Using $block methods or getData() in a .phtml template for logic that belongs in a ViewModel, and assuming the template can call any model directly.
Templates only have access to the block instance; candidates forget that ViewModels are injected via arguments in layout XML and accessed with $block->getViewModel() or a block argument, not by instantiating classes.
What to do instead
Declare the ViewModel in layout XML as a argument of type object with the ViewModel class, then call it from the template through the block. Keep templates to presentation only.
Overriding a core template by copying it into the theme without the module context path, so the override never takes effect.
Theme template overrides must mirror the full module path (e.g. Vendor_Module/templates/...); candidates copy only the filename or drop the module directory.
What to do instead
Place the override at app/design/frontend///<Vendor_Module>/templates/.phtml matching the original module's view/frontend/templates path exactly, then flush the template cache or run setup:static-content:deploy.
Writing a Knockout component and registering it in the wrong scope, or failing to return the component object from the define() callback, so the UIComponent never binds.
Knockout components in Magento require a define() wrapper returning {defaults, ...} and correct data-bind usage; candidates mix up the component registration with plain Knockout or forget the requirejs-config mapping.
What to do instead
Define the component with define(['ko', 'uiComponent'], function(ko, Component){ return Component.extend({...}); }), map it in requirejs-config.js if needed, and bind with data-bind="scope: 'componentName'" on a parent element so the component initializes.
Mutating observable data directly (e.g. this.items.push(x) on a plain array or assigning to an observable without calling it) and expecting the UI to update.
Candidates treat Knockout observables like plain JS values; observables must be invoked to read/write, and arrays must be observableArray to trigger re-render.
What to do instead
Read/write observables with parentheses (this.value(), this.value(newVal)) and use observableArray for collections; for nested objects use ko.observable and ko.observableArray consistently, then verify re-render in the browser.
Editing .less source but seeing no change because the theme's static files were not recompiled or the wrong theme context was active.
Magento compiles LESS to CSS during static content deploy or on-the-fly in developer mode; in production mode the compiled CSS is served from pub/static and stale until redeployed.
What to do instead
In developer mode clear cache and let client-side compilation run, or run bin/magento setup:static-content:deploy -f for the specific theme/locale; confirm the theme is set as the active design and check the generated CSS in pub/static.
Using @import of a LESS file inside a theme without accounting for the theme's _variables.less/_extends.less override order, so custom variables are ignored.
Magento's blank/luma themes define variables in specific files; overriding a variable in the wrong file or after the import means the compiled output keeps the default value.
What to do instead
Override variables in the theme's web/css/source/_variables.less (or the documented override file) and ensure it is imported before dependent files; verify by inspecting the compiled CSS value, not the source.
Assuming full-page cache will serve personalized cart/checkout content, or failing to add a cacheable=false / private block where customer-specific data is rendered.
FPC caches pages for anonymous visitors; cart, mini-cart, and checkout blocks are customer-specific and must be excluded, and candidates miss the cacheable attribute or the customer-data JS.
What to do instead
Mark customer-specific blocks with cacheable="false" in layout XML or render them via customer-data (private content) JS; for checkout, rely on the checkout session and verify behavior with FPC enabled and a logged-in customer.
Customizing checkout by editing core checkout JS/templates in place rather than using layout XML, mixins, or the checkout component configuration, causing breakage on upgrade or conflicting with the checkout config provider.
Checkout is driven by a JS component tree configured through layout XML arguments and a config provider; candidates patch files directly and then the customization does not load or breaks the step rendering.
What to do instead
Extend checkout via layout XML (checkout_index_index.xml) arguments, a custom config provider implementing ConfigProviderInterface, and requirejs mixins for JS behavior; never edit vendor checkout files, and validate the step renders with the new provider data.