Forem: David Lambauer

Navigating Magento 2 Architecture: Discovering Plugin Architecture for Newcomers

David Lambauer — Mon, 17 Jul 2023 18:15:13 +0000

Hello again, and welcome back to our series on Magento 2 Architecture for newcomers! We're glad to see you return for the second part of our journey, a clear indicator of your dedication to understanding and mastering this powerful platform. In our first post, we delved into the fascinating world of Magento 2's Observer Architecture. We explored its unique functionality and got our hands dirty with practical examples to bolster our knowledge.

Today, we will be unraveling the intricacies of Magento 2's Plugin Architecture. Our aim is to ensure you not only understand the concept theoretically but also gain the practical skills necessary to apply them efficiently. So buckle up, as we gear up for another exciting ride through the world of Magento!

The Role of Plugins in Magento 2

In Magento 2, plugins, also referred to as Interceptors, play a critical role in extending the functionality of existing public methods within a class. They provide a mechanism that allows us to alter or extend the behavior of public methods without modifying the actual class.

The charm of plugins lies in their ability to interact with a method at three different points: before, after, and around. This allows developers to modify the input or output data or even change the flow of processing.

Registering a Plugin

To leverage the power of plugins, we need to register them first. This is done in the di.xml file of your module. Here's a basic example:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Framework\App\Action\Action">
        <plugin name="vendor_module_slack_notifier" type="Vendor\Module\Plugin\SlackNotifier" sortOrder="10"/>
    </type>
</config>

In this example, we've registered a plugin named vendor_module_slack_notifier for the class Magento\Framework\App\Action\Action. The plugin's class is Vendor\Module\Plugin\SlackNotifier.

Writing a Plugin

Now, let's get down to the nitty-gritty of writing our plugin. Remember our goal here is to send a Slack message at a clever place. A good idea could be to notify a Slack channel whenever a new order is placed on the website. In this case, let's consider we are writing a plugin for the placeOrder method in the Magento\Sales\Model\Service\OrderService class.

namespace Vendor\Module\Plugin;

class SlackNotifier
{
    protected $slack;

    public function __construct(
        \Vendor\Module\Model\Slack $slack
    ) {
        $this->slack = $slack;
    }

    public function afterPlaceOrder(
        \Magento\Sales\Model\Service\OrderService $subject,
        $result
    ) {
        $message = "New order placed with ID: " . $result;
        $this->slack->sendMessage($message);
        return $result;
    }
}

In this plugin, we are using the after plugin to send a Slack message after an order has been placed.

Unit Testing a Plugin

After we've written our plugin, it's important to test it to ensure it behaves as expected. Here's how you can use PHPUnit to test your plugin.

namespace Vendor\Module\Test\Unit\Plugin;

class SlackNotifierTest extends \PHPUnit\Framework\TestCase
{
    protected $slackNotifier;

    protected function setUp(): void
    {
        $this->slackNotifier = $this->getMockBuilder(\Vendor\Module\Plugin\SlackNotifier::class)
                                    ->disableOriginalConstructor()
                                    ->getMock();
    }

    public function testAfterPlaceOrder()
    {
        $orderServiceMock = $this->createMock(\Magento\Sales\Model\Service\OrderService::class);
        $result = "100001";
        $this->slackNotifier->expects($this->once())
                            ->method('afterPlaceOrder')
                            ->with($orderServiceMock, $result);

        $this->slackNotifier->afterPlaceOrder($orderServiceMock, $result);
    }
}

Observers vs Plugins

While observers and plugins might seem similar, they serve different purposes and their usage depends on your requirements. Plugins are great for modifying the behavior of existing public methods. However, if you're interested in reacting to specific events in the application, observers would be a more suitable choice.

The observer pattern can be seen as a more global approach, as it enables a certain type of code (observers) to react to system-wide events without coupling the observers to the code that emits those events. Plugins, on the other hand, are more targeted, allowing us to interact with a method at specific points in its execution.

With the knowledge you've gained from this post and the previous one, you are now well-equipped to start implementing these concepts into your projects. Next in this series, we will dive deeper into the world of Magento 2 architecture. Stay tuned and happy coding!

Kickstarting Magento 2 Architecture Journey: Mastering Observer Architecture for Newcomers

David Lambauer — Mon, 19 Jun 2023 21:36:09 +0000

Hello and welcome to the first post in our blog series dedicated to the architectural nuances of Magento 2. Aimed specifically at those taking their initial steps into the Magento ecosystem, this series will illuminate key architectural elements and concepts of the platform. Our inaugural topic is a vital part of Magento's Event-Driven Architecture - the Observer Pattern.

Magento 2 Observer Architecture: An Overview

The Observer Architecture, an event-driven design pattern in Magento, paves the way for effective communication between various sections of code. It adopts the principle of 'Loose Coupling,' promoting interactions without rigid dependencies. Essentially, it lets you extend and customize Magento's functionality without modifying the core system files significantly.

Various events, such as adding a product to the cart or placing an order, initiate specific sequences of actions within Magento 2. The Dispatcher identifies these events and calls the corresponding observers - class methods assigned to carry out actions related to the event.

Identifying Event Names

Magento 2 has predefined event names for numerous actions. To identify the correct event name, you need to understand the functionality you wish to extend or modify. Often, you can find these event names within Magento's core code files, specifically inside the dispatch function calls. A pro tip: For a more comprehensive list, refer to the Magento 2 Event Cheat Sheet available online.

Registering an Observer with `events.xml`

To declare an observer in Magento 2, you will utilize the events.xml file. You'll need to specify the event name you're observing and the class that will handle it. Here's a quick walkthrough on registering an observer:

Create an events.xml file in the etc directory of your module.

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Event/etc/events.xsd">
    <event name="checkout_cart_product_add_after">
        <observer name="slack_message_observer" instance="Vendor\Module\Observer\SlackMessageObserver" />
    </event>
</config>

Crafting an Observer: Sending a Slack Message on Cart Addition

Let's put this into practice by creating an observer that sends a Slack message whenever a product is added to the cart.

First, define your Observer class, SlackMessageObserver.php, within your module's Observer directory.

namespace Vendor\Module\Observer;

use Magento\Framework\Event\ObserverInterface;
use Vendor\Module\Model\SlackMessageSender;

class SlackMessageObserver implements ObserverInterface
{
    private SlackMessageSender $slackMessageSender;

    public function __construct(SlackMessageSender $slackMessageSender)
    {
        $this->slackMessageSender = $slackMessageSender;
    }

public function execute(\Magento\Framework\Event\Observer $observer)
{
    $product = $observer->getDataUsingMethod('product');

    if ($product) {
        $message = 'A product has been added to the cart: ' . $product->getName();
        $this->slackMessageSender->send($message);
    }
}
}

In this code, we've implemented the execute method, which gets invoked when the checkout_cart_product_add_after event is dispatched. The execute method gathers the product data and sends a message to a Slack channel using the SlackMessageSender service.

Testing Your Observer

Testing in Magento 2 typically involves two levels - Unit Testing and Integration Testing.

Unit Testing aims at the smallest testable parts of an application, in isolation. In our observer's case, we can create a mock of SlackMessageSender and confirm if the send method is called with the expected argument.

Integration Testing, conversely, examines the interaction between different application components. It could involve testing the entire process, from adding a product to the cart to sending the Slack message. Here's how an integration test for our observer might look:

namespace Vendor\Module\Observer\Test\Integration;

use Magento\TestFramework\Helper\Bootstrap;
use Magento\Framework\Event\ManagerInterface as EventManager;
use Magento\Catalog\Api\ProductRepositoryInterface;
use Magento\Checkout\Model\Cart;
use Vendor\Module\Observer\SlackMessageObserver;
use Vendor\Module\Model\SlackMessageSender;

class SlackMessageObserverTest extends \PHPUnit\Framework\TestCase
{
    private $objectManager;
    private $cart;
    private $slackMessageSenderMock;

    protected function setUp(): void
    {
        $this->objectManager = Bootstrap::getObjectManager();
        $this->cart = $this->objectManager->get(Cart::class);
        $this->slackMessageSenderMock = $this->createMock(SlackMessageSender::class);
        $this->objectManager->addSharedInstance($this->slackMessageSenderMock, SlackMessageSender::class);
        $this->objectManager->addSharedInstance($this->objectManager->create(SlackMessageObserver::class), SlackMessageObserver::class);
    }

    public function testObserverIsTriggeredOnAddToCart(): void
    {
        $productRepository = $this->objectManager->get(ProductRepositoryInterface::class);
        $product = $productRepository->get('simple'); // 'simple' should be a SKU of a product in your test database

        $this->slackMessageSenderMock
            ->expects($this->once())
            ->method('send')
            ->with($this->stringContains($product->getName()));

        $this->cart->addProduct($product, 1);
        $this->cart->save();
    }

    protected function tearDown(): void
    {
        $this->objectManager->removeSharedInstance(SlackMessageSender::class);
        $this->objectManager->removeSharedInstance(SlackMessageObserver::class);
    }
}

In addition, a basic unit test might look like this:

namespace Vendor\Module\Test\Unit;

use PHPUnit\Framework\TestCase;
use Vendor\Module\Observer\SlackMessageObserver;
use Vendor\Module\Model\SlackMessageSender;
use Magento\Catalog\Model\Product;
use Magento\Framework\Event\Observer;
use Magento\Framework\Event;

class SlackMessageObserverTest extends TestCase
{
    public function testExecute(): void
    {
        $productName = 'Test Product';

        // Mock product
        $productMock = $this->createMock(Product::class);
        $productMock->method('getName')->willReturn($productName);

        // Mock event
        $eventMock = $this->createMock(Event::class);
        $eventMock->method('getData')->with('product')->willReturn($productMock);

        // Mock observer
        $observerMock = $this->createMock(Observer::class);
        $observerMock->method('getEvent')->willReturn($eventMock);

        // Mock SlackMessageSender
        $slackMessageSenderMock = $this->createMock(SlackMessageSender::class);
        $slackMessageSenderMock->expects($this->once())
            ->method('send')
            ->with($this->stringContains($productName));

        // Instantiate the SlackMessageObserver with the mocked SlackMessageSender
        $observer = new SlackMessageObserver($slackMessageSenderMock);
        $observer->execute($observerMock);
    }
}

Testing is as critical as writing code itself. Tests ensure your modules' stability and reliability, and mitigate future issues arising from updates or changes in other parts of the system.

Best Practices

Declare the Observer in the Appropriate Scope

The first step in using Magento 2 observers effectively is to ensure you declare them in the right scope: global, frontend, or adminhtml. The scope of your observer depends on where you need it to operate. A global scope means the observer operates universally, both in the admin area and the frontend. If your observer is only needed in the backend, use the adminhtml scope. Meanwhile, if it's strictly for the user-facing part of your site, then frontend is the appropriate scope.

Make the Observer as Efficient as Possible

Efficiency is key when it comes to coding, particularly with observers in Magento 2. To increase the efficiency of your observer, streamline your code. Try to reduce unnecessary loops and calculations as these can slow down your web pages. Remember, a lean observer is a fast observer. For instance, if there's an SQL query within your observer code that's not essential or could be optimized, it might be worth revisiting.

Avoid Cyclical Event Loops

Avoiding cyclical event loops is another crucial best practice. In a cyclical event loop, an event triggers an observer which then dispatches another event, which then triggers the initial event, and so on. This can lead to significant performance issues. To prevent this, ensure that your observers are mindful of the events they're triggering and avoid creating unnecessary dependencies.

Do Not Rely on Invocation Order

Finally, when dealing with multiple observers in Magento 2, do not rely on their invocation order. The order in which observers are invoked in Magento 2 is not specified, so building dependencies based on order can lead to unpredictable results. Each observer should be designed to operate independently, regardless of when it's invoked in the sequence.

In conclusion, using Magento 2 observers effectively involves careful scope placement, lean and efficient coding, avoidance of cyclical event loops, and independent design to prevent reliance on invocation order. Following these best practices will help you optimize your Magento 2 observer use.

Come to an end

And there we have it - the first steps into Magento 2's intriguing observer architecture. Don't worry if it seems a bit overwhelming now; with each post in this series, the fog will clear, and the road will become more navigable. Remember, all great journeys start with a single step.

As we journey together, I'd love to connect with you on other platforms as well. You can follow me on Twitter for regular insights, quick tips, and all things Magento. Or join me on Github to explore my projects, learn from the code and maybe even contribute to some open source initiatives!

Stay tuned for the next post in this series, and don't forget, the world of Magento 2 is expansive and full of opportunities for those willing to explore. As always, happy Magento coding!

Understanding Magento 2 Modules: A Comprehensive Look into Key Class Types

David Lambauer — Thu, 15 Jun 2023 18:28:46 +0000

Greetings, Magento 2 enthusiasts. The life of a developer is laden with challenges, one of the most prominent being structuring and naming modules effectively. This task, albeit complex, is crucial in creating software that is easy to read, modify, and debug. Let's embark on an exploration of five pivotal class types that are instrumental in structuring Magento 2 modules efficiently.

1. Mapper Classes

The first class on our list is the Mapper Class. Mapper classes are invaluable tools that mediate and translate between different data types and structures. They provide an efficient way to convert data from one format to another, hence increasing the interoperability of your modules.

In a Magento context, Mapper classes can be utilized to translate data from a CSV file to a more structured format like RSS or even a product DTO (Data Transfer Object). The Mapper class ensures this conversion process is streamlined and efficient, reducing code redundancy and increasing maintainability.

class CsvToRssMapper {
    public function map($csvData) {
        // Conversion logic from CSV data to RSS format
    }
}

By encapsulating the mapping logic within its domain, a Mapper class promotes single responsibility and enhances code readability.

2. Validator Classes

Validator Classes play a crucial role in maintaining the integrity and consistency of data within the application. They enforce rules and constraints to ensure the incoming data adheres to the specified format and conditions.

For example, in an e-commerce store, a ProductValidator class might scrutinize whether the product data entered by the admin meets all requirements, such as non-empty product name and valid SKU, before it gets saved into the database.

class ProductValidator {
    public function validate($productData) {
        // Validate if the productData meets the requirements
    }
}

Validator classes not only safeguard the application from invalid data but also encapsulate validation logic, keeping the code clean and organized.

3. Command Classes (CQRS)

Command classes form a critical part of the Command Query Responsibility Segregation (CQRS) pattern, which segregates operations that mutate state (Commands) from operations that return data (Queries).

In a Magento store, you might have a command like "UpdateProductStockCommand" that takes a product SKU and the new stock quantity, updating the inventory.

class UpdateProductStockCommand {
    public function execute($sku, $newQuantity) {
        // Logic to update the stock quantity of the product
    }
}

Command classes, by focusing solely on state mutation, bring clarity to your code and reduce the likelihood of side effects in data manipulation operations.

4. Query Classes (CQRS)

Complementing Command classes in the CQRS pattern are Query classes. They are solely responsible for data retrieval and do not alter the state of the application.

For instance, a Query class in Magento could be "GetProductBySkuQuery," which fetches a product's data based on its SKU without affecting the underlying data.

class GetProductBySkuQuery {
    public function execute($sku) {
        // Fetch and return the product data using SKU
    }
}

By decoupling data retrieval from data mutation, Query classes enable safer and more efficient data handling, enhancing the performance and reliability of the application.

5. Service Classes

Service classes are the workhorses of any Magento application. They encapsulate business logic and serve as a bridge between the presentation and data access layers.

In a typical e-commerce scenario, a ProductService might orchestrate the process of creating a product, which could involve validating input data, mapping it to a product entity, and saving it to the database using a repository.

class ProductService {
    public function createProduct($productData) {
        // Business logic to create a new product
    }
}

Service classes bring structure and order to the application, encapsulating complex operations, and promoting code reusability and maintenance.

To sum up, understanding these five class types – Mapper, Validator, Command, Query, and Service – is essential to structure and name Magento 2 modules effectively. These classes, when utilized properly, can make your code more readable, maintainable, and scalable. Here's to writing cleaner and more efficient Magento 2 code!

Software Quality Metrics: No Sorcery, Just Simple Math!

David Lambauer — Tue, 13 Jun 2023 19:02:42 +0000

Greetings, PHP Padawans and Code Craftsmen!

You've arrived at the right place if you're in search of the One Ring to rule your PHP code! The magical journey we're embarking on today involves a fantastical beast with a forbidding name - Software Quality Metrics.

Dramatic gasp

Relax, they're not as scary as they sound. In fact, they're your loyal allies, ready to add a Midas touch to your code. They're as easy to measure as counting the stripes on your tabby. So let's dive in, shall we?

1. The Code Maintainability Index: Is your code a Marathon Runner or a Couch Potato?

The Code Maintainability Index is like a fitness check-up for your code. It provides a score from 0 to 100, where 100 implies your code is ready to run a marathon (with no panting), and 0... well, let's say it's in love with the couch.

Maintainability Index calculates scores using three primary ingredients:

Halstead Volume – It's like the manual of your code. If you've got more operators and operands than you can shake a stick at, your volume is high.
Cyclomatic Complexity – More on this spicy ingredient later, promise.
Lines of Code – Aka, your code's not-so-secret diary. More isn't always merrier here.

Consider this PHP snippet:

function findMedian($arr, $n) {
    sort($arr);
    if ($n % 2 != 0)
        return (double)$arr[$n / 2];
    return (double)($arr[($n - 1) / 2] + $arr[$n / 2]) / 2.0;
}

It's lean, mean, and ready for the screen. It does one thing, and does it well - finds the median of an array. The complexity and volume are low. It would score pretty high on the Maintainability Index.

2. Cyclomatic Complexity: The Tangled Web We Weave

Next up, we have the Cyclomatic Complexity metric - which, despite its ominous name, is not a new Transformer villain. Instead, it measures the complexity of your code based on the number of independent paths through it. It’s like counting the possible routes you can take in your city. The more paths there are, the more complex the city... or in our case, the code.

Check this PHP example:

function sortArray($arr) {
    $size = count($arr);
    for ($i = 0; $i < $size; $i++) {
        for ($j = 0; $j < $size; $j++) {
            if ($arr[$j] > $arr[$i]) {
                $temp = $arr[$i];
                $arr[$i] = $arr[$j];
                $arr[$j] = $temp;
            }
        }
    }
    return $arr;
}

Ouch! That's a double "for" loop sorting an array. With each "if" and "for," our Cyclomatic Complexity shoots up. It's like a city where every street corner has a dozen alleys leading off. Too many options can make the city - or your code - hard to navigate.

3. Code Duplication: Deja vu, or Copy-Paste Catastrophe?

Lastly, we have Code Duplication. Remember that cringe moment when you arrived at a party, and someone was wearing the same dress? Code doesn't like that, either. Code Duplication means how many times we've got the same or very similar blocks of code in different places.

Here's a guilty snippet:

function calculateDiscountA($price) {
    return $price - ($price * 0.1);
}

function calculateDiscountB($price) {
    return $price - ($price * 0.1);
}

Yikes! Same dress at the party! This is a classic example of unnecessary code duplication, where calculateDiscountA and calculateDiscountB are doing the same thing.

To Sum It Up

If you treat these three metrics like your trusty ol' Marauder's Map, they will reveal your PHP code's secrets, quirks, and areas for improvement. Remember, understanding these metrics isn't about nitpicking your code. It's about making it healthier, sturdier, and more flexible.

Because at the end of the day, we want our code to be like that perfect piece of software - eloquent, efficient, and easier than Sunday morning!

Happy Coding! May your bugs be minimal, and your coffee cup be always full!

Until next time,
Your Friendly Code Whisperer