Unsolved Mysteries In Magento2Unsolved Mysteries In Magento2

Even after years of development, the quest to find a solution with Magento 2 is un-ending. The difficulties I face in every implementation are real and common pain points. The objective is not to just brag about problems, but to solve them and ask for feedback.

Though I still have faith in the Magento Community, still a lot of improvements are needed in the core for a better developer experience. Let's check out a few I faced (and fixed) in Magento 2!

  1. Observing add to cart/qty update

    • Why do we need this?

      • We don't want to use magento/inventory (i.e. MSI) for stock management in multiple locations (though we have multiple warehouses) due to its performance, bugs and features (different than needed in our inventory system).
      • We don't want to use magento/catalog-inventory for the same reason (unfulfilled requirements) and its deprecated in favor of magento/inventory .
      • We needed the inventory as a service, decoupled from Magento 2.
      • We needed to add validation to restricted minimum add to cart and maximum add to cart quantity.
      • We needed to apply promotions/linked services (like gift items, warranty service item, etc) with the main product add to the cart.
    • How did we solve it?

  2. Observing order status/state change

    • Why do we need this?

      • You might have heard about the common Magento 2 certification question, i.e. How do you sync/push orders to 3rd party ERP ? (we needed it) but the Magento 2 order workflow provides no consistent way to observe order status/state change.
      • We need to run after the order promotions, like providing coupons to the customer on successful order delivery.
      • We need to auto fulfil orders for few cases.
    • How did we solve it?

      • Using sales_order_save_after event and match the orig_data with current data but its not reliable. In zero-subtotal order, the sales_order_save_after original status will be null and the current status will be processing but in other cases, it will be new/pending for newly placed orders.
      • Using after plugins can be added on the followings, but its do not cover all cases for example: pending -> processing. or any custom status that is being added from admin.

        • \Magento\Sales\Api\OrderManagementInterface::cancel($id)
        • \Magento\Sales\Api\OrderManagementInterface::hold($id)
        • \Magento\Sales\Api\OrderManagementInterface::unHold($id)
        • \Magento\Sales\Api\OrderManagementInterface::place($id)
  3. Add multiple products in addition to the cart

    • Why do we need this?

      • Bulk order or bulk wishlist to cart action requires multiple products add to cart APIs but Magento 2 is not designed to add multiple products together in the cart.
    • How did we solve it?

      • Using the around plugin on add to cart.
  4. Consumers and their inconsistency with Repositories

    • Why do we need this?

      • We needed to optimise the checkout flow and decouple few operations on place order and process them asynchronously but don't use the repository in queue consumers.
    • How did we solve it?

      • Using OrderRepositoryInterfaceFactory object instead OrderRepositoryInterface in the __construct. Not the best solution, but was a quick fix.
  5. APIs that don't support token refresh/revoke

    • Yes, we preferred REST APIs over graphql, due to stability and security reasons but it misses some basic APIs, like customer logout via API or refreshing the customer token with the refresh token.
    • How did we solve it?

  6. Core bugs that need test cases

    • There were small bugs, like few admin customer form fields were not getting saved on submit, we raise PRs to the core, but was very difficult to merge them as a small change in di.xml would require test cases to be added.
  7. Bundled modules that are bloatware

    • Why do we need this?

      • I don't think I need to explain this, there are around 157 modules that we generally disable in a project. Also, used replace a few times in composer.json to totally remove them from the project (but make sure you know that Magento Commerce do not provide support if you want to remove i.e replace any bundled module).
      • We don't use magento/inventory, magento/graph-ql, shipping module like dhl, fedex, payment method modules, 3rd party modules, etc so why keep them in the database and in vendor with all dependencies.
    • How did we solve it?

      • Jisse Reitsma from Yireo has already provided a great package to remove optional modules. Take reference from the following composer.json file and remove not needed module from the project.

            "name": "yireo/magento2-replace-all",
            "description": "Remove various packages from Magento",
            "require": {
                "magento/product-community-edition": "2.4.*"
            "replace": {
                "amzn/amazon-pay-and-login-magento-2-module": "*",
                "amzn/amazon-pay-and-login-with-amazon-core-module": "*",
                "amzn/amazon-pay-module": "*",
                "amzn/amazon-pay-sdk-php": "*",
                "amzn/login-with-amazon-module": "*",
                "astock/stock-api-libphp": "*",
                "braintree/braintree": "*",
                "braintree/braintree_php": "*",
                "dotmailer/dotmailer-magento2-extension": "*",
                "dotmailer/dotmailer-magento2-extension-b2b": "*",
                "dotmailer/dotmailer-magento2-extension-chat": "*",
                "dotmailer/dotmailer-magento2-extension-enterprise": "*",
                "dotmailer/dotmailer-magento2-extension-enterprise-package": "*",
                "dotmailer/dotmailer-magento2-extension-package": "*",
                "dotmailer/dotmailer-magento2-extension-sms": "*",
                "klarna/m2-payments": "*",
                "klarna/module-core": "*",
                "klarna/module-kp": "*",
                "klarna/module-kp-graph-ql": "*",
                "klarna/module-onsitemessaging": "*",
                "klarna/module-ordermanagement": "*",

  8. TCO that is very high

    • Magento 2 offers a million of features, but the large-scale system uses none, besides the framework. I must say that there is no other platform such as Magento 2 which offers such great features out of the box at a very less price or free (open source). SFCC, Hybris, etc are no way near to Magento2 in terms of features.
    • Large stores don't prefer monolith or say can't use monolith due to certain factors. Inventory is managed from WMS, CMS is mostly not Magento OTB, CRM is external, and a PIM is external. Storefront is PWA/Headless/Hyva or anything but the default Luma. So what they use is APIs and most parts of the back office admin.