Magento Thought Leadership

Functionality vs Performance: The reorder conundrum

This post is part of a series of posts around achieving maintainability and scalability within your Magento solution. Magento offers a great feature that allows customers to reorder products previously purchased. In a vacuum the default solution makes perfect sense. Magento reviews each previous order and the items associated with it to determine if the items are still available in the catalog. If so, Magento presents a Reorder button next to the order in the order history grid.

Logically the solution makes sense, but is a very heavyweight solution that includes loading each product, all its variations, and corresponding stock statuses into memory to perform this check. The result is for a user that has purchased many items over time, the order history page is unimaginably slow for the user (sometimes to the point of time outs) and very resource intensive to the server.

It is important then to look at the profile of your customer and ask a few questions ...

  1. Do I have loyal customers who are making frequent purchases over time?
  2. How often is my product catalog turning over, will products from a year ago ever be re-orderable?
  3. How often do my customers come back to buy the same thing so that reorder even makes sense?

Every business is different, so you need to consider the factors above before deciding how valuable reorder is for you.

If you don't have many customers reordering, then this is a moot issue and you can move on. You can probably also stick with the base functionality if you do have customers that reorder but they generally reorder the same products over and over.

If you don't have customers ordering the same products over and/or your catalog turns over seasonally, reorder probably doesn't make sense. In this case, modifying Magento to remove the Reorder check and the Reorder button makes good sense.

If you do have reorders and the same customer may buy a wide range of items, you might want to consider limiting the reorder check for order history to the first few orders (5 or 10) and then disabling reorder checks for all over orders.

Teach them to fish

As my company has undertaken the journey that is Magento 2 we find ourselves constantly researching how others in the Magento community have solved similar problems. We are grateful for so many contributors willing to spend the time and effort to write up explanations of how they chose to solve problems and share with the rest us.

We are constantly searching for the proper balance between the quick solution that meets the customer's exact request (and current budget) and the fundamentally sound solution that takes longer and maybe is more than the customer really wanted to tackle and way more then they wanted to spend. Much like in Magento 1 there are often lots of ways to accomplish a single task in Magento 2. Unlike Magento 1, a developer can carefully craft a change that is injected at just the right time in the request life cycle with limited impact to the rest of the system. Unfortunately, it is still too easy for a developer to make changes that have terrible side effects as what they believed was a small change for some specific scenario actually was a generic function that is called by lots of different processes with data in all sorts of different states.

So how do we collectively learn? .. how do we learn to customize Magento better? ... how do we impart the wisdom we learn to others? ... It is my hope that this blog can play a part in this process. So much of the intellectual property on Magento is recanting a rote implementation for a specific problem. This sort of help can be exactly what you need ... or not. What if what you need is sorta like this other developers problem but not quite ... Did the other developer approach the problem correctly? Does the solution align well with the core Magento architecture? Is the solution one that is made to last? These are harder questions ... but just as important as solving the problem at hand.

As many other Magento developers can attest to when they take over projects build by other teams, there are a LOT of bad implementations. It is difficult to tell a customer that while their system "looks" right from the front-end perspective, the underlying implementation is a disaster ... that there is significant work to be able to upgrade their Magento version due to the customizations put in place ... that core Magento features don't work because the previous team violated the core Magento framework assumptions ... that the previous team gave them a solution that was not maintainable.

We are not perfect, we make mistakes, we make bad design decisions, but we don't want to. We want every customer to have a system that is built to last with thoughtful design and core Magento architecture principles maintained. This blog is part of our effort to explain more than just the how ... but the why when executing custom Magento development.

We don't want to just give fish to eat, we want to teach people how to fish ...