Show Menu

Magento 2 Cheat Sheet (DRAFT) by [deleted]

A quick reference guide for Magento2, command line, xml snippets, template file snippets, Models and other useful bits of information.

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Command line

Cache Management
Example of use
Clear all caches:
php magento cache:­clean
Clearing a single cache:
php magento cache:­clean config
Flush all caches:
php magento cache:­flush
Flushing a single cache:
php magento cache:­flush config
Index Management
Example of use
Runs all available indexes:
php magento indexe­r:r­eindex
Example of use
Runs all cron jobs by schedule:
php magento cron:run
Help & Knowledge
Example of use
Display help/infos about a command
php magento help indexe­r:r­eindex
Lists all available CLI commands
php magento list
Develo­pement & Production
Example of use
Set to the production mode to harden your setup
php magento deploy­:mo­de:­set­pro­duction
(excep­tions are not displayed to the user, only logged to log files)
Developer mode is less secure than Production mode
php magento deploy­:mo­de:­set­dev­eloper
provides verbose logging (errors displayed in browser) enhanced debugg­ingand disables static view file caching
Recompile Store
Example of use
Recompile the Magento 2 codebase
php magento setup:­di:­compile


Custom events can be dispatched by simply passing in a unique event name to the event manager when you call the dispatch function. Your unique event name is referenced in your module’s events.xml file where you specify which observers will react to that event.
The observer xml element has the following properties
name (required)
The name of the observer for the event definition
instance (required)
The fully qualified class name of the observer
Determines whether this observer is active or not. Default value is false
etermines the lifestyle of the class. Default is false
<event name="my_module_event_before">
<observer name="m­yOb­ser­ver­Nam­e" instan­ce=­"­MyC­omp­any­\My­Mod­ule­\Ob­ser­ver­\My­Obs­erv­er" />


What case we use di.xml ?
We can use di.xml for (rewrite) preference of a particular class.
We can send a new or replace the existing class arguments.
Use plugins to do some stuff before, after and around a function
By using virtua­lTypes creating a sub-class of another class.
Example for Preference
<pr­efe­rence for="Ma­gen­to­\Cus­tom­er­\Api­\Ad­dre­ssR­epo­sit­ory­Int­erf­ace­"             type="M­age­nto­\Cu­sto­mer­\Mo­del­\Re­sou­rce­Mod­el­\Add­res­sRe­pos­ito­ry" />
Above code, When someone asks you to instan­tiate a Magent­o\C­ust­ome­r\A­pi­\Add­res­sRe­pos­ito­ryI­nte­rface it will instan­tiate a Magent­o\C­ust­ome­r\M­ode­l\R­eso­urc­eMo­del­\Ad­dre­ssR­epo­sitory object (the type attrib­ute).
Example for Arguments
<type name="M­age­nto­\Cu­sto­mer­\Mo­del­\Re­sou­rce­Mod­el­\Gro­up" shared­="fa­lse­">     <ar­gum­ent­s>         <ar­gument name="g­rou­pMa­nag­eme­nt" xsi:ty­pe=­"­obj­ect­"­>Ma­gen­to­\Cus­tom­er­\Api­\Gr­oup­Man­age­men­tIn­ter­fac­e\P­rox­y</­arg­ume­nt>     </a­rgu­men­ts> </t­ype>
In the above code, We are sending object as an argument, we are saying system to insert "­Pro­xy" class as an object with the name of groupM­ana­gement. Also we can use Arguments for replacing the existing argument too.
Example for Plugin
<type name="M­age­nto­\Cu­sto­mer­\Mo­del­\Re­sou­rce­Mod­el­\Vis­ito­r">     <plugin name="c­ata­log­Log­" type="M­age­nto­\Ca­tal­og­\Mod­el­\Plu­gin­\Lo­g" /> </t­ype>
In the above code , public function clean(­$ob­ject) in visitor class is called after public function afterC­lea­n(V­isitor $subject, $logRe­sou­rce­Model) which is in Log class.
Example for Virtual Types
<vi­rtu­alType name="o­urV­irt­ual­Typ­eNa­me" type="P­uls­est­orm­\Tu­tor­ial­Vir­tua­lTy­pe­\Mod­el­\Arg­ume­nt1­"> </v­irt­ual­Typ­e>
Creating a virtual type is sort of like creating a sub-class for an existing class. With virtual types, the only behavior you can change in your virtual sub-class is which depend­encies are injected.

Design Patterns In Magento

Model View Controller Pattern (MVC)
Design pattern where business, presen­tation and coupling logic are separated
Front Controller Pattern
Makes sure that there is one and only one point of entry. All requests are invest­igated, routed to the designated controller and then processed accord­ingly to the specif­ication
Factory Pattern
Respon­sible of factor­izing (insta­nti­ating) classes.
Singleton Pattern
Checks the whether this class has already been instan­tiated before, this results in a shared instance.
Registry Pattern
Internal registry: a global scoped container for storing data
Prototype Pattern
It defines that instances of classes can retrieve a specific other class instance depending on its parent class (the prototype)
Object Pool Pattern
A box with objects so that they do not have to be allocated and destroyed over and over again.
Iterator Pattern
The iterator pattern defines that there is a shared way to iterate over a container with objects.
Lazy Loading Pattern
Lazy loading ensures that loading data is delayed until the point when it is actually needed.
Service Locator Pattern
The service locator pattern abstracts away the retrieval of a certain service. This allows for changing the service without breaking anything.
Module Pattern
An implem­ent­ation of the module pattern would make sure that each element can be removed or swapped.
Observer Pattern
By defining observers (or listen­ers), extra code can be hooked which will be called upon as the observed event fires.