Adobe Commerce Developer Professional common mistakes
Adobe Commerce Developer Professional · Understand the traps and how to avoid them.
Treating Magento/Adobe Commerce as a single monolithic app and failing to distinguish responsibilities of the app/ code pool, generated/ code pool, lib/internal, and vendor/ directories.
Candidates memorize directory names from tutorials but never learn the code-generation and DI compilation pipeline, so they cannot reason about where compiled factories, proxies, and interceptors live or why a class is missing from generated/.
What to do instead
Trace one concrete example end to end: define a preference in di.xml, run bin/magento setup:di:compile, and locate the generated factory/proxy/interceptor in generated/code. Practice explaining which directory owns framework code vs. modules vs. third-party packages.
Confusing the roles of the various XML configuration files (di.xml, module.xml, routes.xml, webapi.xml) and putting configuration in the wrong file or wrong area (global vs. frontend vs. adminhtml).
All of these are 'just XML' and candidates skim them; they miss that area-specific di.xml files layer on top of the global one and that module.xml controls load order and version, not DI.
What to do instead
Build a small cheat sheet mapping each file to its purpose and valid locations (etc/, etc/frontend/, etc/adminhtml/, etc/webapi.xml). For each, write one scenario where it is the correct place and one where it is not.
Installing or configuring Adobe Commerce without accounting for the required PHP extensions, Elasticsearch/OpenSearch, and correct file permissions, then being unable to explain why setup:install or the setup wizard fails.
Candidates follow a copy-pasted install command and skip the system-requirements and post-install permission steps, so they cannot diagnose install failures conceptually.
What to do instead
Memorize the documented system requirements (PHP version, required extensions, search engine, database) and the two-user permission model (filesystem owner vs. web server user). Practice listing the ordered steps from composer create-project through setup:install to cache flush.
Mixing up the deployment modes and their consequences, e.g., expecting static files to be generated on the fly in production mode or expecting code changes to take effect without recompiling.
Candidates know the three mode names but not what each does to static file generation, DI compilation, and error display, so scenario questions about 'changes not appearing' defeat them.
What to do instead
For each mode (default, developer, production) write down: static file behavior, DI compilation requirement, error reporting, and whether generated code must be rebuilt. Test switching modes on a scratch install and observe the differences.
Editing files in the vendor/ directory or directly in a core module instead of extending via a custom module, and failing to recognize this as the wrong approach in scenario questions.
It is the fastest way to make a change work locally, so candidates default to it and never internalize the upgrade-safety rationale behind the extension model.
What to do instead
Practice reframing every 'modify core behavior' scenario into the correct extension point: plugin, preference, observer, or layout override in a custom module. State explicitly why vendor/ edits break composer updates.
Confusing theme inheritance with layout inheritance and expecting a child theme's layout XML to automatically replace the parent's rather than merge with it.
Candidates assume filesystem-style override semantics apply to layouts, but layout XML from parent and child themes and modules is merged by handle, not replaced wholesale.
What to do instead
Study how layout files are merged per handle and how remove/update/override attributes work in layout XML. Practice predicting the final merged layout for a child theme that adds a block to a handle also defined by the parent.
Overriding a template or block by copying the wrong file path or forgetting the theme's registration.php and theme.xml, so the override silently does nothing.
Theme file paths are long and easy to mis-type, and candidates do not verify that the theme is actually registered and assigned in the admin.
What to do instead
Memorize the theme directory structure (registration.php, theme.xml, etc/view.xml, Magento_Module/templates/). After creating an override, verify the theme is registered, assigned, and that the template path resolves to your theme using template hints.
Writing a plugin with the wrong method signature or wrong plugin type (before/around/after) and expecting it to change a return value it cannot change.
Candidates learn the three plugin types superficially and miss that before plugins cannot modify the original return value and around plugins must call the proceed callback.
What to do instead
For each plugin type, write the exact signature and state what it can and cannot do. Practice converting a requirement ('add a suffix to the returned value') into the correct plugin type and verifying sortOrder and disabled behavior.
Declaring a module without the required registration.php, module.xml, and correct sequence, then being unable to explain why the module does not load or why its dependencies fail.
Candidates copy a module skeleton but do not understand the load-order role of the sequence node or that registration.php is what registers the component with the framework.
What to do instead
Build a minimal module from scratch without copying: registration.php, etc/module.xml with name and sequence, and a routes or di.xml as needed. Enable it, confirm it appears in module:status, and test removing the sequence to observe the failure.
Treating EAV entities like flat tables, e.g., querying product attributes directly from catalog_product_entity instead of the correct attribute backend tables, or misunderstanding attribute scopes and frontend/backend models.
Candidates apply flat-table SQL intuition to EAV and do not internalize that attribute values live in type-specific tables (varchar, int, decimal, text, datetime) keyed by attribute_id and store_id.
What to do instead
Map one product attribute end to end: its EAV attribute record, its backend_type, the value table it writes to, and how store scope affects rows. Practice writing the join path from catalog_product_entity through the correct value table for a given attribute.