Understanding the 5 Most Common Pain Points of Magento

There are many reasons why Magento is one of the leading ecommerce platforms in the world. For starters, it comes with robust, out-of-the-box functionality. It has nearly infinite flexibility, and retailers can do anything with it. Further, the platform gives merchants great room for business evolution and creative expansion.

But, on the flip side, the platform’s vast options can be overwhelming. Once you’re using Magento daily, you may well experience some of its sources of frustration.

With this in mind, we want retailers to know that you are not alone. As developers, we’ve experienced these challenges, too, and today we’re going to share about the five most common pain points of Magento. It’s our goal to help you solve Magento’s puzzles, so you can get back to using this super-charged platform to grow your retail business.

Magento Pain Point #1: My Product Isn’t Showing Up

Perhaps the most common frustration is when a retailer logs new inventory into their site, but the products do not show up on the frontend. There are many reasons why this happens.

For example, take over-selling (the ability to determine whether or not your store can continue to show a product once it goes out of stock). There’s a Magento admin option for this, and you can set either at the global level or at the product level. Often times the person in charge of setting this doesn’t know it exists. Or if they do, they fail to remember how they set it. Such a simple setting may seem insignificant at the time, but it can cause a big headache down the road.

And it’s not just the global versus individual product setting. The issue is sometimes per store view and per website. There are layers of configuration. Sometimes it turns out that someone, at some point in time, accidentally set a store-view setting for a specific product. If you don’t know to look for that setting, you would never know why the product isn’t showing up.

Therefore if you have entered products that are not displaying on your site, you can troubleshoot by reviewing all the product settings. This should include global site settings, as well as individual product and inventory level settings.

Pain Point #2: Retailers Have to Speak Magento-Specific Terminology

Ecommerce is ever-changing, and new words and concepts come up all the time. But Magento has a language almost of its own. For example, consider the difference between these three terms:

Status: a product is either enabled or disabled. A disabled product will not show up in the store, but an enabled might. But only if the next two things are set correctly.

Visibility: in Magento, you have matrix products. That means that a product can be one of three things: 1) visible and cataloged 2) visible in the catalog and the search or 3) not visible individually. All of these things control whether or not the product is able to be viewed and selected for add-to-cart in the case of children products (variants), by shoppers.

Inventory availability: This setting is marked in different ways. So, for example, you may have a product with three remaining pieces in the inventory. But if you’ve set a threshold elsewhere that says to take the product out of stock once it gets below 5 pieces, then the platform will hide the remaining 3 items.

Often retailers don’t realize they have conflicting information in their settings. The system is doing exactly as it’s being told, and the site administrator may not know where to tell it to do differently. Be sure your development team is familiar with Magento’s proprietary terminology and begins to build a lexicon of terms.

Pain Point #3: Indexing and Cache

Magento does two things that are performance related: indexing and cache. Magento indexing is a database-specific process, and it helps the performance of your site. If indexes aren’t running or aren’t configured properly, items will not show up in your store. Or items that are not supposed to be visible will show up. Or, if some indexes are running, but not all of them, prices could, for example, differ on the category page from the product page.

Remember: indexing is a data-specific optimization that requires constant updating. If the updating falls out of sync, products and other information may appear where they should not be.

Part two of this challenge is caching. Magento has onboard, full-page caching. It also integrates with Varnish, and it does a lot of really useful caching things. It also caches its configuration. This means that if you add a module or change something, and you don’t refresh it, Magento may not know anything has changed. So, if you’ve made a content change, and nothing is showing up, the best next step is to manually refresh.

Most retailers have a sense about cache and how it speeds things up. Yet, at the same time, an outdated cache, or a bad index, or a set of configuration options could cause both product consistency and visibility issues, as well as unexpected issues in the presentation layer.

The difference between indexing and cache is not straightforward, but loosely speaking, it’s like this: Indexing is the data-based strategy for making the retrieval of information faster. But the data that you get has to be up to date. When the indexes are out of date, you’re getting old data. (Note: this is a very basic explanation.)

Whereas cache really has to do with how the application stores information for future use after it’s already been retrieved once. So cache is less about the database, and more about the efficiency of the application itself. Serving cached data allows the application to run more efficiently because it’s not asking the server the same questions over and over again when the answers aren’t changing.

Pain Point #4: Development and Deployment Workflows Must Be Rigorously Followed

Another common pain point with Magento is that it is absolutely critical to establish a really solid development workflow with good testing. It’s also crucial that all collaborators follow the workflow. Magento in production mode is a built tool. That means that, if you’re running in production mode and want to make changes, you shouldn’t, and often cannot simply modify a file. You should put the site into maintenance mode or otherwise restrict access, push code, rebuild the application, and then take it out of maintenance mode.

To minimize risk, it is critical to test thoroughly in a staging environment whose architecture is as close to your production environment as possible. It is also important that you have a procedure in place to efficiently roll back changes, should they produce unexpected results in production.

Development workflow and deployment workflow matter greatly. Version control also matters a lot because this is a complex system. Developers and administrators are rarely just changing a single file in Magento. Even seemingly simple changes can require layers of modification.

Pain Point #5: Deciding How to Set Up Magento Infrastructure

The topic of workflows leads nicely into the discussion of Magento infrastructure because the infrastructure has to be in place to support the workflows. Magento has a couple of different options for infrastructure. A retailer can either self-host, which means they will be responsible for the site’s uptime, scalability, deployment protocols, etc. They will also be in charge of maintaining the application and ensuring its availability through both high and low traffic.

When we talk about infrastructure, there’s a sub-challenge to make note of: Magento can exceed its resources. When this happens, it slows a site’s performance. Or a site can come down altogether if it has a lot of unexpected traffic or another unusual event.

It’s very important to either have someone on staff who can maintain that infrastructure or contract with someone who can. The latest version of Magento, Magento 2, is better about this than the older versions. But again, anytime a retailer has a large application that uses a lot of resources, a high-volume of traffic will slow the site down.

The alternative to Magento self-hosting is the Magento Enterprise Cloud. This is Magento’s own proprietary setup and structure, integration, and production environment. It’s scalable, plus Magento maintains it and offers retailer support. Magento is continually working on the Enterprise Cloud, and the architecture itself is very stable.

With all this being said – and it’s good to know the challenges before embarking on a new platform – Magento is worth working through these pain points. For instance, Magento 2.2 and higher has built-in robust B2B capabilities. Also, Magento is extensible in any way a retailer can imagine. Whereas another platform might limit a product to 100 variants, Magento does not come with hard limits. Think of Magento with this phrase in mind: with great power comes great responsibility.

But bear in mind there is a caveat when we say no hard limits. If a retailer wants to do something that will be detrimental to the overall health of a site, we will not implement that change. In every ecommerce project, the goal is always optimal site performance and speed.