Hey Reader,

Thank you to everyone who provided me with some feedback on the first issue of M Bytes! The feedback was so overwhelmingly positive, and I'm excited about this new approach.

There are a couple updates you should know about before we get into the lessons this week though.

The first is PCI DSS 4.0, which is a new security standard that was released back in June and applies to all eCommerce sites (and your Magento builds are probably not following it). Storefronts can quickly get up to speed with the security requirements by installing the magento2-pci-4-compatibility module by Aligent.

Also, my live Xdebug workshop at MMFL is coming up in a few weeks (feel free to register if you plan on attending the conference!), and I decided to update my docker-magento setup with a new, more powerful bin/xdebug script. You can run bin/update to update your stack to version 49.0.0 (just be sure to back things up beforehand).

I really hope you enjoy the free video lessons coming your way. Even though I have a huge list of lessons I'm working on, I'd also love to hear what you'd like to learn more about — so please reply to this email and let me know.

​

Use getData() vs. magic getters in Magento 2

Let’s talk about getting data from Magento objects. You’ve got two options: magic getters, or the getData() method.

Magic getters might look cleaner at first glance. But they can cause some real headaches due to their behind-the-scenes string conversion magic.

Here’s what actually happens with a magic getter: Magento strips off the “get” prefix, converts your camelCase to snake_case, then looks up that converted key. That’s a lot of hidden complexity!

Also consider this scenario: you define “customViewModel” in your layout XML, then try to access it with getCustomViewModel(). Surprise — you get null back!

This happens because the magic getter converted your camelCase to custom_view_model.

getData() doesn’t play these games. It uses exactly what you give it, making it more predictable and easier to debug.

Sure, it might need a few extra keystrokes, but it'll save you from those frustrating debugging sessions down the road.

​

Write a Dockerfile for a custom Docker image

Let’s break down how to write a Dockerfile — it’s simpler than you might think.

A Dockerfile is just a set of instructions that tell Docker how to build your image. Think of it like a recipe card. Each line represents a specific step in creating your containerized environment.

The first instruction is always FROM, which specifies your base image. For example, “FROM python:3.13.1” tells Docker to start with the official Python image.

You can then use RUN commands to execute shell commands inside your image. Need to install dependencies? RUN is how you do it.

WORKDIR sets up where your app will live in the container. The convention is to use “/app” as your working directory.

COPY moves files from your local machine into the container. It’s straightforward: just specify the source and destination paths.

The final piece is usually CMD, which tells Docker what to run when the container starts. Always use the exec form with square brackets here — it’s more efficient and handles shutdown signals better.

Each instruction creates a new layer in your image. These layers build upon each other to create your final container environment.

​

How DNS converts domain names to IP addresses

Ever wonder what happens when you type “google.com” into your browser? Your computer needs to convert that human-friendly domain name into a computer-friendly IP address.

It starts by checking its own DNS cache. If you’ve visited Google recently, it already knows where to find it.

No luck in the cache? Time to ask one of the internet’s 13 root nameservers. These are like the internet’s primary phone book.

The root server points you to the .com nameservers. These keep track of every single .com domain out there.

Finally, you reach Google’s own nameservers. These are the authority on everything Google, and they’ll give you the actual IP address you need.

The whole process happens in milliseconds, with results getting cached at each step. You can even watch this journey yourself using the “dig +trace” command in terminal.

Each DNS server also maintains its own cache, which makes future requests faster and keeps the whole system running smoothly.

​

​

These atomic lessons are just one way I teach Magento.

University members get access to my complete selection of courses, covering everything from the basics of Magento controllers, models and views, to the intricacies of checkout customizations and admin grid creation.

​

​

​