The bootstrapping process of Magento’s checkout

When a customer initiates a checkout process, they are directed to the /checkout URL. This requires a route to handle checkout requests. Within the Magento Checkout module, this can be found in the etc/frontend/routes directory.

The “standard” router handles regular requests and looks for matches of the frontName, which in this case is “checkout”. Magento identifies that the Magento Checkout module is responsible for handling these requests and searches for a controller to manage this request.

The Index Controller

The request is mapped to /checkout/index/index, leading Magento to search for a controller at Index/Index. This controller class extends the Onepage class, providing it with additional functionality. It’s worth noting that the checkout process is almost entirely rendered from XML and UI components.

Understanding how layout XML works, the /checkout URL also references a layout XML file named checkout_index_index. This file is responsible for rendering the entire checkout process, referred to as “Onepage” by Magento.

Onepage vs. One Step Checkout

It is important not to confuse “Onepage” with third-party modules called “One Step Checkout”, as they are entirely different. The term “onepage” refers to the fact that the page is loaded only once and rendered almost entirely with JavaScript and Ajax, without additional page loads.

Main Layout Block

The main layout block renders the onepage.phtml template file. This is a .phtml file, not a Knockout HTML file. The file calls various PHP methods, primarily to pass the JavaScript layout to Magento UI’s js/core/app. This is managed by the call to $block->getJsLayout(), which initiates the entire JavaScript process. The file also assigns a value to window.checkoutConfig.

Window.CheckoutConfig

We will dive deeper into window.checkoutConfig later in this course, but it is helpful to know where it is defined and where the configuration is pulled in.

The Onepage Class

Returning to the XML file, the Onepage class is the block class related to the template file we had open earlier. By searching for jsLayout, we find that it is not defined within this file. Instead, jsLayout is entirely defined within the XML argument node.

UI Components

The XML tree goes extremely deep in the Magento checkout process. By navigating to components, checkout, and children, we can collapse all child nodes under the “children” node. This leaves errors, authentication, progressBar, and so on. Each of these child nodes has either a component or a template assigned to them.

Component and Template Relationship

If a child node has a component, the template is usually defined within that UI Component and is always matched to a defaults.template property. This refers to the same module that it is located in (Magento checkout), and the slash is relative to the view/frontend/web/template directory within this module.

For example, the authentication.html file is the Knockout HTML file that correlates back to its corresponding UI Component. This relationship can be a bit confusing, but just remember that it’s all about UI components.