Forem: Vladyslav Podorozhnyi 🇺🇦 🌻

Should you upgrade your Magento store at all? Developer view

Vladyslav Podorozhnyi 🇺🇦 🌻 — Fri, 27 Oct 2023 15:45:13 +0000

Hello everyone. 👋

This article will be a bit less technical and more about the value of the upgrade for store owners. However, all of my thoughts would be described from the view of the developer that design, implement, and maintain such stores - so expect at least some level of technical expertise and judgments here.

Obviously, we would speak in contexts of Magento 2 / Adobe Commerce / Mage-OS - but I believe that findings and ideas described here would be useful for Shopware too, as well as for any other e-commerce system.

So - lets move on and have a small walkthrough of this topic. 🚶‍♀️🚶‍♂️

What does any upgrade bring us:

new features
new possibilities for developers
bugfixes
security fixes
agility - possibility to upgrade faster to all future New versions

Let’s check each point and ask next questions:

What value does it bring to the project?
Price?
Do we need this value?

New features

What value does it bring to the project?

New business possibilities for store owners. Or improved UX in case it is an upgrade of Hyvä.

Or improved code execution performance ( yes - I think it is a feature 😄 ).

Price?

Is it free? - YES. Then we need it! [ actually, it is not free - see my explanation below ]

That is what the client says 😄. For him, it looks like a FREE fancy addition to all the hard work that is going to be done.

Not all features from the upgrade can be easily adapted if we take into account all customization project already has - the minimum you should consider is styling, maximum - is rebuilding business logic from top to bottom.

Do we need this value?

If the store owner needs a new feature - the store owner would ask for it explicitly. 😄

Answer: more NO than yes. At least in scope of the upgrade.

New Possibilities for Developers

What value does it bring to the project?

We have some variations here, but here is a compilation of the benefits it gives us:

build code faster
Make code less shaky & buggy

Price?

Is it free? - YES. Then we need it!

That is what the developer says 😄 (déjà vu). And again - it looks free, but there could be a clown that eats you alive. 🤡

Do we need this value?

Answer: It depends - but more NO than yes. Unless it is a painless upgrade from php 5 to php 7 - then totally yes, yep? 😄
Don't get me wrong - I love new technologies and new versions of old ones, and I wish to work on the edge of tech! However, is it worth it here and now? 🤷

I would plan tech stack upgrade not as an additional point to the system/extension upgrade - but as quite a big chunk of work. So plan carefully and do not think it will be magically transferred without any effort.

Bugfixes

What value does it bring to the project?

less bugs 😅

Price?

Is it a pain in the ass? - sure.

Is it more expensive than just fixing it by yourself? - usually, no.

Do we need this value?

Answer: Yes in 99% of the cases. Other 1% - Developer decides.

Upgrade is a tool to achieve a goal - in this case to fix the bug/bugs. But monkeypatch is also a tool 🙉.

Choose wisely!

Security Fixes

What value does it bring to the project?

Shop won’t be spammed / hacked / Arbitrary code execution won't happen.

e.g. - no disappointed buyers attack you 😸

Price?

Well - security is priceless 😎

However, sometimes it is cheaper to just transfer security fix changes - if you know what and where to transfer, which is not usually the case.
Let’s say it this way - I would not risk the security of my client to save another couple of hours on an upgrade.

Do we need this value?

Yes - we need it. Always.

Answer: Yes.

Agility - you can upgrade faster to all future NEW versions

What value does it bring to the project?

Constant upgrades -> minimise time spent on one particular upgrade.

e.g. - clean your home once a week and it takes you half an hour, do it once a year - you would cry for help and won’t finish in a days 🙉

Price?

Do upgrades constantly - usually, once a quarter you have a patch upgrade, and some small p1, p2, p… versions during the quarter. Also, once 1,5 years, you do the bigger upgrade (Minor by semantic ver and somewhat Major based on Magento lifecycle ).
In return, you will get a healthy webshop with a high level of agility to get new versions. Recent security patches once again reminded us how important it is to be on the edge (see APSB23-50 ).

Do we need this value?

I afraid so.

Answer: Yes.

Sum Up

We need upgrades. As a minimum for security and agility needs. But also to keep the shop healthy and without technical debt.

It also gets in use for other points from our list and can be useful or harmful for different points.

Upgrade, as an ability, needs to be used mindfully but not blindly 🙈 Build correct expectations from your upgrade, estimate, and plan your work accordingly.
Last but not least - explain why upgrades are needed and what is going to be delivered with this specific release.

Hope my a bit structured thought flow will gonna help you to understand upgrades, what we need to take out of them, and how to communicate it right.

Chao Kako ☕

Cron Jobs in Magento 2: How to Adjust Schedules and Cron Groups Seamlessly

Vladyslav Podorozhnyi 🇺🇦 🌻 — Fri, 22 Sep 2023 18:53:56 +0000

Introduction

Hello!

In today's article, I'll cover a topic that's not too tricky, but can be a bit annoying without some useful tips. Specifically, we'll dive into Magento 2 ( Mage-OS / Adobe Commerce ) to discuss cron jobs, their configurations, and the process of rescheduling them and altering their execution group.

You might wonder, why bother changing the schedule or group of a cron job? Let's find out.

Why Adjust the Cron Schedule?

Occasionally, a cron job might execute too frequently, leading to server load issues or even deadlocks. On the other hand, if it doesn't run often enough, you could be left waiting for emails that take an hour to send. This scenario becomes particularly tricky when these cron jobs are associated with third-party extensions.

Let's imagine we are using 3rd party Feed and Mailing extensions, and we are not OK with their cron jobs schedule.

How can you modify the execution patterns of these cron jobs without tampering with the third-party code directly? By implementing changes in your own codebase – your module. Let's explore this next.

Rescheduling Cron Jobs

Let's have a look at the cron job of the Feed extension feed_generation.

Here is its definition:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Cron:etc/crontab.xsd">
    <group id="default">
      ...
        <job name="feed_generation" instance="\Feed\Cron\FeedGenerator" method="execute">
            <schedule>* * * * *</schedule>
        </job>
      ...
    </group>
</config>

Executing every minute, this job can impose a significant server load. We certainly don't need a new feed every 60 seconds!

To modify its frequency, we'll craft a module, Devto_ChangeFeedSchedule, and incorporate an etc/config.xml file within.

So, the structure would look like this:

Devto_ChangeFeedSchedule/
│
├── etc/
│   ├── config.xml      # our config file
│   └── module.xml      
│
├── registration.php    
│
└── composer.json

The etc/config.xml should contain:

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Store:etc/config.xsd">
    <default>
        <crontab>
            <default> <!-- cron group -->
                <jobs>
                    <feed_generation> <!-- job name -->
                        <schedule>
                            <cron_expr>0 * * * *</cron_expr> <!-- new cron execution schedule -->
                        </schedule>
                    </feed_generation>
                </jobs>
            </default>
        </crontab>
    </default>
</config>

And last but not least - add sequence into etc/module.xml to declare dependency over Feed module and configs apply order:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
    <module name="Devto_ChangeFeedSchedule" >
        <sequence>
            <!-- makes Devto_ChangeFeedSchedule configs be applied after Feed extension configs -->
            <module name="Vendor_FeedExtesnion"/>
        </sequence>
    </module>
</config>

Once the module Devto_ChangeFeedSchedule is activated and the cache cleared, your new job schedule will take effect - run every hour but not a minute.

But what about cron groups? Let's delve into that next.

The Need to Change Cron Group

Imagine we're still working with the Feed and Mailing third-party extensions. These extensions utilize distinct cron groups, each operating as an isolated process. Thanks to this, cron groups can run concurrently/parallely, using individual processes.

Now, suppose these two cron jobs conflict, resulting in data inconsistencies in the Feed and Emails. Worse yet, deadlocks can crop up. You might ask, "Why the deadlocks?"

Well, imagine these extensions read & write the same table, say sales_order_item. When they run simultaneously, the stage is set for potential deadlocks. 🤷‍♂️

If only these jobs were executed sequentially! By relocating them to a shared group, you can ensure they no longer run in parallel.

Altering the Cron Job's Group

A straightforward (though not perfect) solution would be to transfer the Mailing extension's cron job to the default group, where the Feed extension's job resides. Here's the Mailing cron job definition:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Cron:etc/crontab.xsd">
    <group id="mailing_extension"> <!-- mailing cron group -->
      ...
        <job name="send_mails_from_mailing_extension" instance="\Mailing\Cron\SendMailsCron" method="execute">
            <schedule>*/20 * * * *</schedule>
        </job>
      ...
    </group>
</config>

However, a small, non-intuitive trick is essential here: Simply changing the group by redefining crontab.xml won't work. Instead, you need to craft a new cron job while deactivating the old one. This step is necessary since crontab.xml configurations (especially groups) can't be overridden, only augmented.

For instance, merely defining the send_mails_from_mailing_extension cron job in the default group would make it run in both the default and mailing_extension groups.

To disable send_mails_from_mailing_extension, an easy trick is to schedule it for February 30th—a date that doesn't exist!

nerd fact 🤓: actually February 30 happened in Sweden in 1712

Following our earlier approach, we'd add the following content to the etc/config.xml in our module, Devto_ChangeMailingJobGroup:

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Store:etc/config.xsd">
    <default>
        <crontab>
            <default>
                <jobs>
                    <!-- Disable cron execution by scheduling it to Feb 30th. -->
                    <send_mails_from_mailing_extension>
                        <schedule>
                            <cron_expr>0 0 30 2 *</cron_expr>
                        </schedule>
                    </send_mails_from_mailing_extension>
                </jobs>
            </default>
        </crontab>
    </default>
</config>

Next, define a NEW cron job in the default group:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Cron:etc/crontab.xsd">
    <group id="default"> <!-- default cron group -->
      ...
        <!-- added devto prefix to cron name -->
        <job name="devto_send_mails_from_mailing_extension" instance="\Mailing\Cron\SendMailsCron" method="execute">
            <schedule>*/20 * * * *</schedule>
        </job>
      ...
    </group>
</config>

And do not forget to add Mailing module sequence into etc/module.xml:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
    <module name="Devto_ChangeMailingJobGroup" >
        <sequence>
            <!-- makes Devto_ChangeMailingJobGroup configs be applied after Mailing extension configs -->
            <module name="Vendor_MailingExtesnion"/>
        </sequence>
    </module>
</config>

After all changes, the module structure should look like this:

Devto_ChangeMailingJobGroup/
│
├── etc/
│   ├── config.xml      # our config file
|   ├── crontab.xml     # our crontab definition file  
│   └── module.xml      
│
├── registration.php    
│
└── composer.json

Once Devto_ChangeMailingJobGroup is active and the cache refreshed, the send_mails_from_mailing_extension job will be disabled. Meanwhile, its counterpart, devto_send_mails_from_mailing_extension, will operate in the default cron group alongside the Feed cron job.

A Word of Caution on the Default Group

It's vital to recognize that Magento's native cron jobs already densely populate the default cron group. Overloading it might cause "traffic jams" if:

Jobs have lengthy runtimes: If your tasks take too long to finish, they could end up waiting in line, slowing things down.
Overfrequent Scheduling: Setting jobs to run too often can result in backlogs and potential overlaps.
Overpopulation: Filling the group with too many tasks, even if they are quick, might overwhelm the system.

So, while the default group is convenient, treat it like a city's main highway during rush hour. It can handle a lot, but there's a limit before things get clogged. If you have too many heavy tasks or they're scheduled too frequently, you'll likely end up with delays.

In short, be mindful of the workload you're placing on the default group and consider creating your own cron groups to avoid conflict of processes.

Conclusion

And that's the lowdown on Magento's cron jobs, how to shuffle their schedules, and adjust their groups without diving into third-party code directly. With the knowledge you've gathered here, tweaking those pesky cron jobs should be much easier 😊

Thank you for reading!

Adobe Commerce CLI commands - or how to create a problem out of nothing

Vladyslav Podorozhnyi 🇺🇦 🌻 — Tue, 15 Aug 2023 19:45:38 +0000

Intro
The Underlying Problem & Its Roots
The Classic "Chicken or the Egg" Dilemma
The Pitfall of CLI Command Constructors
Strategies to Prevent These Errors
Simplify with Automated Proxy Injection
Summary

Intro

Hello everyone,

In this article, I'll provide practical examples showcasing how unexpected challenges can arise in Magento 2 & Adobe Commerce projects while building and/or using custom CLI commands from 3rd parties. This becomes especially significant while working having CI/CD and performing project setups and test execution in pipelines.

Introducing the main "hero" of our article: ISSUE: magento setup command is throwing magento.flag does't exist.. We'll take a deeper look into this issue, understanding its roots and finding ways to address it.

Disclaimer: Just a quick heads-up on naming - both Adobe Commerce and Magento 2 are covered in this article. After all, Adobe Commerce is Magento. Long Live Magento! 😁

The Underlying Problem & Its Roots

While working on various Magento 2 projects, I frequently encountered snags when performing a clean setup of a project using a freshly created database. This usually happens during integration or functional test setups in pipelines & local environments. Still, this issue isn't exclusive to that scenario and can pop up during upgrades, migrations, or deployments.

The culprits? Here are two pesky errors you might recognize:



The default website isn't defined. Set the website and try again.

For Commerce editions, there's also:



SQLSTATE[42S02]: Base table or view not found: 1146 Table
 'magento2.flag' doesn't exist, query was: 
SELECT flag.* FROM flag WHERE (flag.flag_code='staging')

When you see these during the php bin/magento setup:install command execution, they offer little insight into the real issue. After a few hair-pulling hours of research, you'd discover these errors stem from the premature invocation of the DB resource, triggering the initialization of config and state entities from the Magento DB.

But here's the conundrum: You can't fetch data from the DB at this point because there aren't any tables present yet. They only appear and populate during the installation process, not beforehand. ¯_(ツ)_/¯

The Classic "Chicken or the Egg" Dilemma

So, we're caught in a circular problem: trying to install the system but getting stopped because it's not installed. Confusing, right? 🤪

This happens because someone, somewhere, is prematurely calling the DB connection resource. It is obvious, and I hope you would be as grateful as Sam Eliot is for this revelation insight.

This "someone" should be inside bin/magento and called before actual command execution. Usually, CLI command constructors are guilty here. Let me explain why.

The Pitfall of CLI Command Constructors

For clarity, take a look at this code:



class DoSmthing
{
    private ?string $dummyConfigValue;

    public function __construct(ScopeConfigInterface $storeManager)
    {
        $this->dummyConfigValue = $storeManager->getValue('some/dummy/path', ScopeInterface::SCOPE_STORE);
    }

    public function getValue(): ?string
    {
        return $this->dummyConfigValue;
    }
}

class DummyCommand extends Command
{
    ...
    public function __construct(DoSmthing $model, string $name = null)
    {
        $this->model = $model;
        parent::__construct($name);
    }
    ...
}

The root of the problem lies in the constructors of both the command and model classes.

In the DoSmthing class, the system attempts to retrieve a config value. This action calls the store, store_website, and core_config_data tables when creating the DummyCommand object.

And guess what happens when this code runs before the tables are ready? Yep, errors appear!

Lets repeat one more time:

We execute php bin/magento setup:install ;
bin/magento application creates all instances of CLI commands;
DummyCommand instance depends on the DoSmthing model. So DoSmthing should be created before DummyCommand object creation;
Application performs creation of DoSmthing model and executes DoSmthing::__construct method;
DoSmthing::__construct method calls to the config manager;
Config manager calls to a chain of tables that are not created yet;
ERROR

Strategies to Prevent These Errors

Remember this golden rule: Every CLI command class initializes every time you invoke php bin/magento. So, here's how to save yourself future headaches:

Rule 1 - Be Wise

It is not the most wise solution to call for potential resource consuming operations like DB/API calls in __construct methods of CLI command classes. Those operations will be constantly executed even once you'd have a wish to get only a list of available commands.

Rule 2 - Be Ready

Steer clear of resources in __construct that might NOT be available during runtime, especially since Magento tables aren't present during setup:install.

Rule 3 - Fix The Problem

If you're not in control of the troublesome code, inject a Proxy using di configs.

We can easily solve our problem from the example with DummyCommand by just adding those lines in di.xml:



    <type name="AbcTest\DummyConsoleCommand\Console\Command\DummyCommand">
        <arguments>
            <argument name="model" xsi:type="object">\AbcTest\DummyConsoleCommand\Model\DoSmthing\Proxy</argument>
        </arguments>
    </type>

Proxy is a well-known pattern, and in Magento, it is widely used to avoid unneeded code execution before we actually request it. In our example - DoSmthing class object will not be instantiated until we do call for any method of this class.

No config retrieving while CLI class object creation - No error.

More details about proxy here: Proxies .

Simplify with Automated Proxy Injection

For those with a small number of extensions on their project, pinpointing the rogue CLI commands isn't too challenging. However, for more extensive, legacy projects or ones brimming with third-party extensions, identifying the culprits becomes an ordeal.

To save time, we've crafted a solution to automate the proxy injection process. Introducing: run-as-root/magento-cli-auto-proxy.

This package injects Proxy into all __construct arguments of CLI commands, eligible for proxying. The result? No errors related to early resource access and, as a side affect, faster execution of php bin/magento and php bin/magento setup:install.

Check out the README for more details. We always appreciate feedback and contributions!

Summary

Let's sum it up:

Unthoughtfully created CLI commands can unexpectedly lead to problems, even if they appear harmless at first.
The core of the problem often arises from premature database calls, leading to a classic "chicken or the egg" scenario where system installation gets stalled.
One significant pitfall identified is the CLI command constructors and their potential to wreak havoc when invoked at the wrong time.
To combat these challenges, we laid out three guiding principles:
1. Be Wise by avoiding resource-intensive calls in constructors.
2. Be Ready by steering clear of resources that might not be available.
3. Fix The Problem by utilizing proxies for problematic third-party code.
To streamline and automate the solution, we introduced the package run-as-root/magento-cli-auto-proxy which aims to automate proxy injections, offering a more efficient and error-free Magento experience.

Thank you for diving deep into this article. I welcome all your questions and appreciate any feedback you might have.
Happy coding and... Long Live Magento! 😁

Extension Attributes in Adobe Commerce: Achieving Clean and Decoupled Code

Vladyslav Podorozhnyi 🇺🇦 🌻 — Thu, 13 Jul 2023 20:21:44 +0000

Introduction
Chapter 1: Understanding the Adobe Commerce Service Layer
Chapter 2: Exploring the Idea of Extension Attributes
Chapter 3: Extension Attributes and Service Contracts
Chapter 4: Saving Data for Extension Attributes
Chapter 5: Key Takeaways

Introduction

Welcome to our blog post, where we delve into the practical realm of Extension Attributes in Adobe Commerce (formerly Magento). If you've been working with Magento 2 for a while, you've probably encountered Extension Attributes and harnessed their capabilities. However, it's surprising how often developers overlook the valuable benefits that Extension Attributes offer, especially when compared to outdated methods of entity extension.

In this article, we aim to shed light on the advantages of Extension Attributes and how they can enhance your development projects. We'll explore their integration with the Service Layer, providing you with insights on how to write clean, modular code that avoids unnecessary dependencies on other layers or extensions.

Whether you're an experienced Adobe Commerce developer seeking to broaden your understanding or a newcomer eager to learn more, this article guides you to a bit deeper understanding of Extension Attributes' place & role in Adobe Commerce.

Join us in exploring Extension Attributes. Let's dive in and discover the practical benefits they bring to your development workflow. Let's get started!

Chapter 1: Understanding the Adobe Commerce Service Layer

As you may know already, Adobe Commerce has four Architecture layers:

Presentation layer - point of user interaction with Adobe Commerce.
Service layer - it is a "glue" between layers and a set of APIs used by modules and external systems to communicate with each other. Service contracts are in use here.
Domain layer - contains the business logic of the module.
Persistence layer - resource level, knows about DB and other storages.

See more details here: Architectural layers overview

The service layer is vital for understanding extension attributes, especially the principle of "service contracts" that is used as a system pillar in Adobe Commerce. If you do not know about "service contracts," - read this article Service contracts and keep in mind that this is an agreement between parts of the system on the functionality list available for each party and how these functionalities could be triggered. REST API and API folder in modules are two bright examples of service contract implementation.

The service layer allows to build long term, strictly defined relations between services, both internal and external.

While developing your extension and needing to change/extend one or another functionality of the system - you would need to rely on the Service layer, not any other. Only the Service layer would be able to provide you with a warranty to be changed in the nearest perspective - so there are no troubles with upgrades all the time, as the API definition is
not changed often. I'm not even mentioning the benefits of explicit entry point definition, its parameters, and predictable output.

Chapter 2: Exploring the Idea of Extension Attributes

Imagine you're working with a fundamental entity like an order in Adobe Commerce. This entity has its dedicated table called sales_order and a considerable list of predefined properties. But what if you find yourself in need of adding another property to the order entity?

Sure, you could take the easy route and directly modify the sales_order table, implementing custom observers and models to handle the new property. However, doing so would take you into the Domain layer of another extension, which isn't good. The domain layer of other modules is the last resort for an extension, as they are changed quite often by the vendor. It means meddling with the system's inner workings - system you are out of control, risking compatibility issues during future upgrades. Open–closed principle - the system should be closed for direct changes but open for extending. In this case, modifying the entity directly would be considered changing the system controllable by the vendor Magento - not you.

So, how can we add a property to the entity using the "right" tools?

The answer lies in the power of Extension Attributes. 🙌

Extension Attributes provide a sanctioned approach for extending entities without tampering with the core system's code. Instead of directly modifying the entity table, we leverage Extension Attributes to add new properties in a clean and modular way. By utilizing this method, we ensure our modifications align with the principles of the system's architecture, reducing the risk of compatibility issues and enabling smoother upgrades in the long run.

In the following chapter, we'll explore how Extension Attributes work hand in hand with the Service Layer, enabling you to extend entities effectively and maintain a flexible and scalable codebase.

Chapter 3: Extension Attributes and Service Contracts

Extension Attributes provide a "legitimate" way to modify Service contracts while maintaining backward compatibility for both providers and consumers. Although a simplified definition, it captures the essence of Extension Attributes in Adobe Commerce.

Extension Object: Leveraging Composition over Inheritance

Adobe Commerce adopts the principle of "composition over inheritance" to achieve this flexibility within its development ecosystem. Each entity supporting Extension Attributes has a setter and getter for the Extension object. In the case of orders, it is an instance of a class that implements \Magento\Sales\Api\Data\OrderExtensionInterface.

Configuring Extension Attributes with XML

The behavior of the Extension object is configured through simple and straightforward XML configurations. It is in this configuration where we specify which extension attributes need to be added, define their types, and associate them with the respective entities.

For example:



// @see vendor/magento/module-sales/etc/extension_attributes.xml
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Api/etc/extension_attributes.xsd">
    <extension_attributes for="Magento\Sales\Api\Data\OrderInterface">
        <attribute code="shipping_assignments" type="Magento\Sales\Api\Data\ShippingAssignmentInterface[]" />
    </extension_attributes>
</config>

Support for Extension Attributes: The Role of ExtensibleDataInterface

How does Adobe Commerce knows that order entity supports extension attributes?

Well, \Magento\Sales\Api\Data\OrderInterface extends \Magento\Framework\Api\ExtensibleDataInterface, which informs Adobe Commerce that the order entity will have Extension Attributes. The XML configuration specifies that the property shipping_assignments is one of those Extension Attributes.

Generated Service Contracts

Now that Adobe Commerce is aware of the Extension Attributes, what comes next?

It generates \Magento\Sales\Api\Data\OrderExtensionInterface in the generated/code folder based on the collected XML configurations from extension_attributes.xml.

The generated interface looks like this:



interface OrderExtensionInterface extends \Magento\Framework\Api\ExtensionAttributesInterface
{
    /**
     * @return \Magento\Sales\Api\Data\ShippingAssignmentInterface[]|null
     */
    public function getShippingAssignments();

    /**
     * @param \Magento\Sales\Api\Data\ShippingAssignmentInterface[] $shippingAssignments
     * @return $this
     */
    public function setShippingAssignments($shippingAssignments);
...
}

Additionally, the implementation of the contract/interface, \Magento\Sales\Api\Data\OrderExtension, is also generated.

Summary

In essence, Adobe Commerce has automatically generated a new Service Contract for us based on our configurations. We can now use this contract to effortlessly set and retrieve values of Extension Attributes for the order entity, without the need to navigate through other layers apart from the Service Layer of the Magento_Sales model.

This outstanding move allows your newly added Extension Attribute to become an integral part of the Service Contracts and Service Layer. It remains independent of the implementation details of any modules, extensions, or the system itself that you do not have control over.

Congratulations on leveraging this remarkable feature of Adobe Commerce!

In the next chapter, we'll explore how to not get unwanted dependencies while further Extension Attributes implementation.

Chapter 4: Saving Data for Extension Attributes

It's not always necessary to save Extension Attribute data persistently. Sometimes, it suffices to calculate their values on the fly when needed. However, let's assume we do need to save an attribute.

Main Steps for Saving Extension Attribute Data

The Adobe Docs article, Add extension attributes to entities, provides a comprehensive guide on how to achieve this. Let's go through a quick recap. To add data to an Extension Attribute, you typically follow these steps:

Create a plugin that intercepts the save operation of the entity to retrieve the Extension Attribute data and save it at the resource level.
Create a plugin that intercepts the load operation of the entity to retrieve the Extension Attribute data and populate the entity using the Extension object.

While there can be variations, this is the main scenario, requiring at least two plugins for saving and loading operations.

Where to Save Extension Attribute Data?

Now, that's a brilliant question that leaves many stumped, but not you! 😄

One option is to save the Extension Attribute data in the same table as the entity—for example, the sales_order table for orders. However, this approach introduces a dependency on the Domain Layer of the Magento_Sales module.

And yes, you're right—it's not "legal" in our paradigm. We aim to extend the software, not modify it.

The Best Approach: Have Your Own Entity

In my opinion, the best approach is to have your own entity to save and retrieve the Extension Attribute data. It doesn't matter what persistence layer you choose—whether it's a database, session, file, API, carrier pigeons, or even Morse code written on paper.

It may seem like overkill, but it's the most sensible way to avoid unwanted dependencies on unmodifiable parts of the system. Your Extension Attribute implementation should not impact the core system or violate the Open-Closed principle. By cutting down all connections and dependencies on the extendable module, except for the Extension Attributes definition, you ensure the integrity of the Service Contracts and keep the system functioning as intended.

This approach allows you to maintain a clean and decoupled codebase, free from unnecessary entanglements with uncontrollable system components.

Chapter 5: Key Takeaways

As we conclude this article on Extension Attributes in Adobe Commerce, let's summarize the key takeaways:

Service Layer and Service Contracts: The Service Layer and Service Contracts serve as excellent foundations for extending functionality. They provide stability, predictability, and explicit definitions, making them ideal for seamless extension development.
Persistence, Domain, and Presentation Layers: On the other hand, the Persistence, Domain, and Presentation Layers are not suitable for direct extension. These layers can undergo changes with each release, making them less reliable for long-term extension development.
Extension Attributes and Service Contracts: Extension Attributes are an integral part of the Service Layer and Service Contracts. Leveraging Extension Attributes enables effective extension development and facilitates communication across services within Adobe Commerce.
Avoid Saving Extension Attributes Inside the Entity: It is crucial to refrain from saving Extension Attributes within the entity you are trying to extend. Doing so would introduce a dependency on the Persistence Layer of the extendable module, rendering the benefits of the Service Layer useless. Instead, opt for storing Extension Attribute data in a separate entity to maintain a clean and decoupled architecture.

By adhering to these takeaways, you can build robust and scalable extensions that align with the principles of Adobe Commerce's architecture. Remember, the Service Layer and Service Contracts offer a stable foundation, while Extension Attributes provide a flexible and effective approach to extending functionality.

Thank you for joining us in exploring Extension Attributes in Adobe Commerce. We hope you found this article informative and insightful.

Happy developing!

Forem: Vladyslav Podorozhnyi 🇺🇦 🌻

Should you upgrade your Magento store at all? Developer view

What does any upgrade bring us:

New features

What value does it bring to the project?

Price?

Do we need this value?

New Possibilities for Developers

What value does it bring to the project?

Price?

Do we need this value?

Bugfixes

What value does it bring to the project?

Price?

Do we need this value?

Security Fixes

What value does it bring to the project?

Price?

Do we need this value?

Agility - you can upgrade faster to all future NEW versions

What value does it bring to the project?

Price?

Do we need this value?

Sum Up

Cron Jobs in Magento 2: How to Adjust Schedules and Cron Groups Seamlessly

Introduction

Why Adjust the Cron Schedule?

Rescheduling Cron Jobs

The Need to Change Cron Group

Altering the Cron Job's Group

A Word of Caution on the Default Group

Conclusion

Adobe Commerce CLI commands - or how to create a problem out of nothing

Table Of Contents

Intro

The Underlying Problem & Its Roots

The Classic "Chicken or the Egg" Dilemma

The Pitfall of CLI Command Constructors

Lets repeat one more time:

Strategies to Prevent These Errors

Rule 1 - Be Wise

Rule 2 - Be Ready

Rule 3 - Fix The Problem

Simplify with Automated Proxy Injection

Summary

Extension Attributes in Adobe Commerce: Achieving Clean and Decoupled Code

Table Of Contents

Introduction

Chapter 1: Understanding the Adobe Commerce Service Layer

Chapter 2: Exploring the Idea of Extension Attributes

Chapter 3: Extension Attributes and Service Contracts

Extension Object: Leveraging Composition over Inheritance

Configuring Extension Attributes with XML

Support for Extension Attributes: The Role of ExtensibleDataInterface

Generated Service Contracts

Summary

Chapter 4: Saving Data for Extension Attributes

Main Steps for Saving Extension Attribute Data

Where to Save Extension Attribute Data?

The Best Approach: Have Your Own Entity

Chapter 5: Key Takeaways