Rite Aid Looks to a Digital Future

A Digital Transformation

Six years ago Rite Aid barely had a digital operation. The brand didn’t have an online store, which meant it had to service online shoppers via Amazon. A year later it adopted Magento and created its first owned and operated ecommerce site, but with an ecommerce team of just three people growth was constrained.

One of those people was Joe Tertel. He began by serving as Rite Aid’s Manager of Ecommerce Marketing and he was tasked with driving traffic to the Rite Aid online store.

Driving traffic meant actively managing the company’s email, search, social media, display and affiliate campaigns and he did the best he could given a distinct lack of sophisticated tools. Still, the higher-ups took note of the stellar results of his email campaigns and in short order assigned him responsibility for all email initiatives across Rite Aid.

Today he is the Director of Digital Marketing. His responsibilities now include driving online sales, in-store foot traffic and sales, loyalty membership and usage, as well as finding new pharmacy customers. He oversees all digital channels now, including programmatic and OTT.

Joe’s rise in rank and responsibility coincided with Rite Aid’s decision to embark on a digital transformation. That transformation started at the c-suite, most of whom have been with Rite Aid for less than two years, and all of whom have digital on their resumes.

Over the past few years the ecommerce team has grown substantially in both headcount and scope. Joe’s team, which is part of the overall marketing group, now included separate managers for social media, search and performance, digital content, and overall email and campaign management. The broader ecommerce team included an operations manager, merchandising manager, catalog managers and an in-house analyst.

To support a robust digital operation, Rite Aid migrated to the Adobe Stack, and literally bought all of its products. “If we didn’t have the buy-in from the top we wouldn’t have been able to grow or get the infrastructure, all the Adobe and mar-tech that we have now.  Nor would we have been able to build out the ecommerce team,” Joe explained. “Buy-in at the highest levels is essential for a successful digital transformation.”

Marketing Capabilities Then and Now

Prior to their Adobe tech stack, Rite Aid had very little targeting capability. Joe and his team had to rely on the capabilities offered by Google, Facebook and Rite Aid’s media partners. Any kind of one-to-one personalization required Joe to upload customer lists to these platforms, which presented its own set of problems. “We had to request our CRM team and analytics team to create the lists for us, and that wasn’t an easy thing to do. They wanted to know why we were asking for these lists and what we planned to do with them. It was time consuming to explain it all. The process was long and limiting.”

The team was also limited as to how to measure the ROI of its initiatives, relying mostly on the number of clicks on its store locator link. There was no meaningful way to assess the business outcomes of ads seen in search or social media, for instance. “It was an okay proxy, but really, most people know their local store,” Joe explains.

Another significant challenge: Rite Aid could only target its existing customers. The company had no way to identify, reach and engage wholly new prospects to the brand, which meant it couldn’t build its upper funnel.

Now with the Adobe stack, Joe and his team can create segments of customers to target based on a wide variety of attributes without any assistance from the CRM team. They can target people who’ve taken specific actions on the website, such as visitors who’ve purchased or browsed specific items or categories of items online. They can also create segments of customers who have browsed online but purchased in store, as well as people who have never visited the website and have only purchased in-store.

These targeting capabilities enable the team to understand the customer journey, and to launch remarketing campaigns based on specific user behavior, such as cart abandonment, or campaigns for lapsed customers.

Conquesting

With Adobe Audience Manager and Adobe Advertising Cloud, Rite Aid is able to launch sophisticated new customer acquisition campaigns. The Audience Manager includes a data marketplace where Joe can purchase third-party data from over 500 data sellers. The Advertising Cloud is an end-to-end media buying platform that allows the team reach and engage those audiences.

For instance, Joe recently launched a campaign targeting competitors’ customers whose local stores were closing in order to inform them that Rite Aid would always be their neighborhood pharmacy. “We were able to buy against competitors’ customers from within Adobe,” Joe said.

The team can also build lookalike models for all of their customer segments and use it to target non-Rite Aid customers (e.g. beauty buyers who are a competitors’ customers). With plenty of third-party data now available to them, Joe and his team can create myriad customer segments and tailor their communications to each. “Our creative team is creating a lot more assets now, each talking directly to the individual,” he said.

Turbo-Charged Loyalty Program

One of the most dramatic changes is the way Adobe has transformed Rite Aid’s loyalty program, called wellness+. The entire Adobe stack is centered around the wellness+ numbers, giving Rite Aid a 360-degree view of their customers.

The Adobe Campaign product associates all email addresses to the recipient’s wellness+ number, and the Experience Manager associates it with the cookie IDs.

The result is a deep understanding of how individual customers engage with the brand, along with what they buy, both online and in-store. This insight is used to optimize communications, promotions and marketing strategy. It’s the stuff that every retailer has dreamed of, enabling them to be the proprietor who knows the needs, tastes and brand preferences of every customer who walks through his store. Only in the case of Rite Aid, that’s almost 2,500 outlets plus the millions of people who visit its site and use its app.

2020 Adobe Experience Maker Awards

Something Digital is proud to have played a role in Rite Aid’s success. In collaboration with Adobe, who designed the site, and Rite Aid we were able to help them achieve their digital ambition and to evolve alongside the changing market.

It’s no surprise that when Adobe announced its 2020 Adobe Experience Maker Awards that Rite Aid and Something Digital were named as one of its three finalists in the Mastermind category. You can read more about that here.

Something Digital and Rite Aid Finalists in the 2020 Adobe Experience Maker Awards

We at Something Digital spend our days creating the best possible e-commerce experience for our clients. We listen carefully to our clients’ needs, ask the right questions, and even apply our personal experience as consumers when designing a solution.

While we’re proud of our accomplishments, it’s still humbling when our work is acknowledged by industry leaders. That’s exactly what happened when Adobe announced its 2020 Adobe Experience Maker Awards and named Something Digital as one of its three finalists in the Mastermind category.

The Mastermind category, according to Adobe, “recognizes the company that has delivered a unified commerce experience across multiple B2C and B2B channels.” The work that impressed the judges was the site we built for Rite Aid.

Something Digital had significant experience to bring to the engagement due to our numerous clients in the health, wellness and beauty sectors. We understand the challenges of selling products that are deeply personal to the consumer and require long consideration times.

We began the Rite Aid engagement by helping them to migrate their site from Magento 1 to Magento 2. Once that important work was completed we concentrated on creating a more unified customer experience. Together we:

  • Teamed up with Adobe to deliver a more seamless flow between content and commerce.
  • Helped Rite Aid showcase its vast assortment of categories with custom Page Builder content blocks, allowing the brand to update content frequently, e.g. highlight antihistamines on the homepage at the peak of allergy season, along with highly relevant content on individual product pages.
  • Expanded checkout options by allowing customers to check out right from the marketing pages, as well as from the shopping pages.
  • Securely integrated the loyalty program into the site so customers have one login for both shopping and the loyalty program.
  • Migrated the custom features that Rite Aid wanted from its Magento 1 integration — Apple Pay, Load2Card, BonusCash, KidCents — to the Magento 2 platform. Something Digital recreated all those features so that customers and Rite Aid can continue business as usual.
  • Deployed on Magento’s Commerce Cloud for optimal performance, infrastructure, scaling, and monitoring. SD teams with Adobe’s Magento Cloud team to deliver a valued managed service layer that maintains these products and services at scale in a manner that continues to grow with the client.

 

Need a mastermind to help your brand create an outstanding customer experience for your site? Something Digital’s teams of best-in-class User Experience Designers, Developers and Quality Assurance Engineers are here to help.

Additional Something Digital Health & Beauty Resources:

 

Coming soon: The Something Digital Health, Wellness and Beauty eBook.

SCREAM! Magento 1 End of Life Part 4

Over the past four weeks we’ve had a lot of fun gleaning lessons in various horror flicks for how best to face Magento 1’s end of life. In this post, my goal is to show you that if you’re a merchant who’s still afraid to migrate from Magento 1 — and angry at the beastly Magento for putting you through this torture — one way or another you’re capable of rising to the occasion. You got this. How do I know? Because I know your adversary isn’t some supernatural phenomenon with untold powers. Behind the mask of your demon is a bunch of human coders doing the best they can.

Let’s look at this in context of the 1996 movie, Scream. The Scream franchise is notable because it redefined the horror genre by essentially poking fun at it. The movies are self-referential, often hilariously so, like when someone asks in the first movie if the group should split up, a friend warns it’s what friends always do in horror movies, and it never ends well.

Scream opens with Casey Becker, played by Drew Barrymore, receiving a phone call from a mystery man who wants to know what her favorite scary movie is. The conversation quickly turns dark, and after numerous threats on her life the caller informs her that he’s holding her boyfriend hostage. He tells her he will murder him if she doesn’t answer questions about horror films correctly. Eventually both she and her boyfriend are killed.

What’s unique about the Scream franchise is that in the end, there aren’t any supernatural monsters. Once the killers are unmasked they turn out to be humans, and in the case of Scream, friends of the victims. They have no extraordinary powers or superhuman advantages.

A lot of people have tried to demonize Magento for killing off Magento 1. They’re painting the platform’s end of life as a super scary thing, but let’s stay with reality here. As with Scream, there are no supernatural forces at work, no monster corporations coming after Magento 1 merchants to inflict gratuitous harm on them. At the end of the day, it’s just a group of executives, product managers, developers, sales personnel doing what they can to make the best possible decisions given the circumstances. Their weapons? Data, insights, human factors, competing priorities of security, functionality, installed customer bases.

To be sure, many within Magento have their motives. The sales organization absolutely sees the slaughter of Magento 1 as an opportunity to upsell merchants to Magento 2 or Magento Cloud. Just log on to the backend of Magento 1 and you’ll see a popup that warns of the platform’s approaching demise, and instructing admins to contact Magento Sales for more information. Maybe they are trying to scare people into an upgrade, or maybe they’re simply reminding merchants that no platform, especially open source ones, can last forever. Death eventually comes to everything.

Now, I don’t doubt that some people within Adobe/Magento see this is an opportunity to thin the herd a bit. There are plenty of merchants on its customer rolls who would benefit from a far less feature-rich platform. In fact, such merchants tend to be vocal complainers in public forums when they’re overwhelmed or frustrated, and one can see how that would cause Magento’s customer care team untold aggravation. But here’s the thing: these merchants should consider the EoL of Magento 1 as the perfect opportunity to right-size their tech stacks (if you fit that description but aren’t sure how to go about rightsizing your ecommerce platform, check out our Bullseye blog post series).

The more you get into the Scream franchise, the more self-referential it becomes. For instance, the second movie in the series opens with Windsor College seniors Maureen Evans and Phil Stevens going to a sneak preview of a horror flick called Stab. It’s plot? Basically it’s the stuff that happened to Casey and her friends in Scream. The entire franchise dives deeper and deeper down this rabbit hole of self-reference.

And isn’t that just like all tech ecosystems, Magento included? What is a tech community if not a tightly knit, vocal group of people with a shared history and understanding of how their world works. We talk with each other in an esoteric vernacular and language that only we understand. Our taxonomy is oh so very meta, and that can lead to frustration and feeling victimized when someone comes along and upends our world. But as it turns out, our perceived enemies — the powers that be who make painful decisions like killing off outdated platforms — have their own stuff going on. We don’t see the angst of all those decisions Magento must make regarding coding structure, development techniques, partner-integration bundles and so on.

In the past, it was easier to wallow in the self-pity of upgrades because the user community didn’t really have a lot of insight into how and why Magento developers made decisions. But that’s changed. The company has allowed some daylight into that process and in so doing, proves that Magento is a bunch of (really smart) people doing the best the can.

So are you still quaking in your boots at the thought of migrating? Do you still need a hero? Consider Sidney in the movie Scream. She has two killers after her, but she keeps her wits about her and ultimately prevails. We all have the ability to prevail even when things look bleak, even merchants who are clinging on to Magento 1 for dear life. As I said in the beginning, you got this. You have what it takes to stand up to this scary moment and migrate to a safe place. Ready?

Contact SD today to get started!

“It Follows”: Magento End of Life Horrors Part 3

This is the four-part horror series we hope will convince you to act. In part one we talked about the impossibility of escaping the pain of migrating off of Magento 1. In part two we showed the horrors that await ecommerce stores that foolishly believe they can skirt the death. This time around, we tackle the curse currently infecting the Magento 1 community. Don’t be lulled into thinking you can escape it because you can’t. It follows.

Hands down one of the most terrifying horror films I’ve seen is “It Follows,” by David Robert Mitchell. I’m not alone, numerous pundits and critics have said it scared the bejeebers out of them more than any other flick in recent history.

It’s a story about a 19-year old girl who hooks up with a handsome high school jock, but later learns the affair makes her part of a chain letter-like curse where she’s pursued by a “nebulous, shape-shifting” and utterly terrifying presence. The only way she can rid herself of it is to knowingly pass it on to a trusting and hapless person.

So how does it tie into Magento 1 EOL?

Magento 1 users have been prolonging the platform’s end of life. Magento 2 was released to the market on November 17, 2015, so for nearly four years everyone has known Magento 1 would meet its demise. But something eerie started happening when Magento extended the death of Magento 1 until June 2020: people began to say that there’s no need to get off of Magento 1 at all. Ever.

“Don’t listen to Magento or Adobe,” the evil-doers whisper. “It’s open source, there’s no legal requirement for you to migrate.” “Just because Magento will drop support doesn’t mean something bad will happen.”

This is an insidious, infectious idea. It’s rooted in the belief that one can absolve oneself of responsibility in dealing with this curse by getting others to buy into it. If more and more people agree that they can just stay on Magento 1, the thinking goes, all will be well.

Don’t fall for this thinking — it’s dangerous. We’ve seen this over and over with software, most recently with PHP 5, which experienced its end of life in October 2018. PHP is the backbone of almost every popular content management system today, including Magento. As PHP 5 is no longer supported, users who didn’t upgrade to PHP 7 faced some series risks, including being hacked, as PHP 5 was recently.

Like Magento 1 users today, PHP 5 users listened to the siren song of people telling them they could skip the hard work of migrating, that monster isn’t coming for you.

Only it is. In “It Follows,” relief from the curse is only temporary, because it is a chain, and once it reaches the end, it starts working its way back down. Future proofing against the curse isn’t an option.

There is no future proofing with Magento 1

If you infect yourself with the curse — if you listen to the people who say you can stay on Magento 1 forever — then you must realize you can’t future-proof your ecommerce store, the business you’ve spent so many waking hours nurturing and growing. The business you hope will fund your kid’s college education and your retirement.

The thing is, you can’t choose an ecommerce platform and expect it to last forever. All platforms must be maintained and upgraded when necessary. The world of ecommerce is fast paced. Customers adopt new ways of engaging with online merchants; fraudsters find new wormholes into platforms. As an ecommerce manager, you need to protect yourself as well as your customers — potentially your unsuspecting victims — from this malice.

Contact us with any questions and for your Magento 1 migration!

Something Digital - magento

New Open Source Tool for Magento

We’re pleased to announce a new open source tool for Magento to add to your security toolbelt: SomethingDigital_InvalidateAdminPasswords.

Here’s the use case: your Magento website has experienced a breach and you want to reset all admin credentials.

I had previously blogged a quick tip for how to do this here, but this module offers a much better experience:

  • Invalidation is handled via a bin/magento command. No raw SQL queries needed 😅
  • It sends an email to all admin users instructing them to reset their password (process documented in blog post had no way of notifying users).
    • The email can be customized from the Magento admin panel.
  • Invalidates two-factor authentication user configuration (assuming 2FA is via msp/twofactorauth).
  • Functionality is covered by integration tests and hooked up to Travis CI.

 

It’s important to note that the module currently does not kick out any users with active admin sessions. However, there is documentation in the README explaining what can be done to achieve that.

You never know when you might need this feature and don’t want to be scrambling to have it when it’s already too late, so install this module now!

Hope you enjoy it!

Is Magento 1 your Final Destination?

In part one of this series, we talked about how you can’t escape the pain of migrating off of Magento 1. This next post is for those clever retailers who think that by sticking with Magento 1 they can somehow skirt the death of a platform. [Spoiler alert:] You can’t.

To illustrate this, we turn to the Final Destination franchise, which warns there’s no escaping death, no matter how clever you are.

The movie opens with Alex Browning, (Devon Sawa) about to fly off to Paris with his friends on a class trip.

But just before take-off, Alex has a premonition that the plane will explode in mid-air, killing everyone on board. He panics, a fight breaks out, and Alex, along with his friends are kicked off the plane. Within moments of takeoff the plane really does explode, prompting Alex and his friends to celebrate their good luck in narrowly escaping death.

Little did they know that death would chase them until it eventually wins. Alex watches as his friends are picked off one by one, until he finally meets his end.

It’s a plot device that runs through all five movies: A group of characters are supposed to die but by some stroke of luck, live to see another day. Death, meanwhile, is quite displeased when things don’t go as planned. What makes the movies fun are all the head fakes. As a moviegoer you’re lulled into thinking one character or another will make it, and then wham! It’s curtains, and we never saw it coming.

So how does this relate to migrating off of Magento 1? As we mentioned in part 1 of this series, Magento has moved the end of life (EOL) for Magento 1 a few times. First it was to die in November of 2018, then death got pushed back to June 2020. Retailers who haven’t migrated off of Magento 1 are lulled into believing they have a new lease on life. But do they?

Magento 1 Head Fakes

When Magento 2 was released, the company made it very clear that there would be end of life dates for all point releases, and it meant what it said. For instance, the end of life for 2.0 came in August 2018. Users could expect no more security patches, quality fixes, or documentation updates for 2.0 release. It was upgrade to 2.1 or die.

The same thing happened this past September when Magento released 2.3.

Meanwhile, Magento 1 users have been getting security patches from Magento and can count on them until June 2020. If you’re such a user, did you cheat death? Were you somehow wise or lucky to stay on Magento 1 while users of 2.0 and 2.1 were picked off

You may have been spared the burdens of the 2.0-point releases, but the piper still needs to be paid. Migration is still your fate, whether that’s to Magento 2.0, Shopify or some other platform.

If you’re still on Magento 1 it means you’ve been stuck in time since 2015. Magento as a platform has matured in direct response to ecommerce maturation. For instance, it has Page Builder, B2B features, and supports Amazon Channel selling.

Don’t let 2015 be your final destination.

Don’t Prolong the Horror of Your Magento 1 End of Life

Four years ago, next month Magento announced the demise of Magento 1.0. Many retailers took what was said to heart and made plans to either upgrade to Magento 2.0 or another platform. Some opted to put it off for reasons only they can explain. But whatever the reason, it’s time to act.

This four-part blog series dwells on the gruesome horrors that await retailers who fail to make plans. Since it’s October, we’ve tapped into the horror movie cannon to extract some lessons to drive home our message: June 2020 is coming, run to the safety of a supported ecommerce platform.

We’ll start with the movie Saw. Fans of the horror franchise will remember a central trope of the films: you can put off pain, but you can’t escape it. And, your attempts to avoid it will result in unimaginable horrors — along with profound regret for not doing what you knew you had to do all along.

Saw opens with Adam, (Leigh Whannell) and Dr. Lawrence Gorden, (Cary Elwas) waking up chained and locked in a bathroom, a dead body between them. Adam is told to escape; Lawrence is told to murder Adam by 6:00 or his family will be murdered, and he’ll be left to die. They find some hacksaws in the toilet, but quickly realize that they’re meant for limbs, not the chains that bind them to the room. That’s when they’re hit with the gruesome choice before them: hack off their own limbs or die.

There’s an obvious parallel here to online retailers who are still running their businesses on Magento 1. Magento 2.0 was released on November 17, 2015, and Magento told retailers using Magento Commerce 1 (formerly known as Enterprise Edition) and Magento Open Source 1 (formerly known as Community Edition) that they had three years to migrate. Moreover, as of November 2018, retailers could expect no new features or functionality developments, just absolutely necessary security patches. In other words, Magento 1’s end of life was set for November, 2018. We were all warned.

And yet the platform didn’t die when originally promised. Last September Magento offered Magento 1 retailers another reprieve when it extending the cutoff date (pun intended) until June 2020. That led many retailers to hang on to their Magento 1 ecommerce stores, effectively covering their eyes and plugging up their ears to the abject terror of migrating to a new platform.

Three years is ample time to migrate. Many retailers have put off the inevitable, just as Dr. Gordon does in Saw, until they have no choice but to act. You might be hoping for some other outcome — perhaps another extension by Magento? — but it isn’t coming. You need to face that pain.

Yeah, I said it. I equated migrating off of Magento 1 to cutting off one’s own limbs. Of course, Magento provides tools to migrate your catalog and customer base to Magento 2, but all of those plug-ins’ retailers rely on to run their businesses? These are like the five digits Dr. Gordon can’t imagine living without.

We know that once Dr. Gordon lobs off his foot he’ll need to get a prosthesis so he can carry on with his life, just as you know you’ll need to find a prosthetic solution for those plug-ins that won’t work in Magento 2 (or Shopify, if that’s the route you’ll take). That’ll be painful, it will take some getting used to. It will take some trial and error to find the perfect fit. But there’s no getting around your fate.

Here’s the thing: You’ve been warned. Magento’s constant reminders are like the voice of Jigsaw telling Dr. Gordon in the bathroom that his fate is in his own hands; he can escape the horror at any time rather than prolong through procrastination. In the last scene he finally takes the saw to his ankle. It’s a terrible price, but the reward is the safety of his family.

At Something Digital, we totally feel your pain, but it’s yours and you need to face it. The consequences of staying on Magento 1 after its end of life will be gruesome for you and a real horror show for your customers. You need to migrate in order to save your business.

Stay tuned for parts 2-4 in the coming weeks and if you have questions about your Magento 1 migration let us know.

Something Digital Helps Magento Move into the Future

The Web has always been a cooperative endeavor, with the best minds coming together to create better experiences for the general user population. It’s an approach adopted by Magento through its Magento Contributors initiative, which acknowledges that the people who work with e-tailers day in and day out have critical insight into market needs, and that their collective insight can help propel the platform forward.

As Magento says about its community of contributors, “Your contributions are the foundation of the Magento open source platform. Contributions include source code patches — either bug fixes or new functionality — delivered by individual and partner developers across our Community.”

Something Digital’s Contributions to Magento

Something Digital has been impressively active in the contributions community, and recently Magento invited one of our developers, Patrick McLain, to join its Community Maintainer team. Patrick maintains a handful of open-source modules for Magento 2, and can often be found looking for interesting questions on Magento StackExchange.

Led by Patrick, Something Digital has made substantial contributions to Magento, including 40 submissions, 39 of which have been incorporated into Magento’s core code. His contributions have ranged from code modifications and bug fixes to new features that will enable progressive web applications (PWA) to support mobile phone shoppers.

Some highlights:

  • Libsodium encryption. A key contribution allows for implementation of the Libsodium encryption library. The encryption library previously used by Magento, mcrypt, had been deprecated for quite some time, so Patrick worked to bring Magento’s encryption library up to date. Thanks to Patrick and Something Digital, all encrypted values stored inside the database and used by the platform are now more secure.
  • GraphQL projects. Most of our contributions concern the GraphQL project, which is a query language originally developed by Facebook for its mobile applications, and competes with REST API. Facebook turned GraphicQL into an open source protocol, which in turn, enabled Something Digital to contribute to power the future of Magento’s front end in bringing about PWA.
  • Mobile Checkout. Within GraphQL Patrick made numerous contributions toward the checkout implementation, thereby allowing users to progress from viewing a product to putting it in their cart, setting shipping and billing addresses, payment information. His contributions span the checkout to order creation processes.
  • Payment Methods Architecture. Something Digital developed the architecture for online payment methods, i.e., how code will be structured for anyone implementing a payment method inside of Magento. And once it’s exposed to PWAs through GraphQL, will follow the architecture that Something Digital developed.

 

“It’s no surprise that Something Digital’s developers like Patrick are prolific contributors to Magento’s core platform. We’ve helped retailers thrive in the global ecosystem for 20 years, and have firsthand knowledge of what they need from their platform in order to serve their customers well and grow their businesses,” explained Greg Steinberg, Principal and Co-Founder of Something Digital. “The fact that the bulk of our contributions are now part of Magento core code speaks to the expertise of our development team.”

Something Digital Clients get an Inside Track

One of the reasons why Something Digital leadership is keen to allow its developers to participate in the Magento Contributors Community is that such participation has a direct benefit to our customers.

As Patrick explains, “For all new features that we help build, even before it’s released to the general public, before it’s available for anybody to use, Something Digital developers are already subject matter experts, because we wrote it. We understand the internal workings of it, the best practices for developing features on it, because we were there the whole way through the development cycle.”

If you want to learn more about our Magento contributions, who we are, and what we do, let us know!

Something Digital - magento

MySQL Best Practices for Upgrading to Magento 2.3

If you’re a member of the Magento community, you’ve probably heard that Magento has declared end of life for 2.1.x support to be June 2019 (that’s now!). As Magento 2.1 approaches end of life, we at SD have started the processing of upgrading a number of our clients from 2.1 to 2.3, the latest major version of Magento 2.

Because of the number of core data changes that come along with the upgrade from 2.1 to 2.2 alone (i.e. the move from serialized strings to JSON), we ran into a few issues during the initial process of deploying a 2.3 instance to a staging environment. The most challenging issue came in the form of a MySQL error during the setup:upgrade process. If you’re unfamiliar with this particular Magento command, it’s used to perform changes to the database that the application code will require. Essentially, modules can be created to make changes to preexisting database tables, or even create new ones for their own use. Because of the conversion of serialized data to JSON in many of Magento’s core tables, including customer and sales data, this process can take a very, very long time to execute depending on the amount of data in your database.

Just to take a step back for a second, I was recently fortunate enough to have the opportunity to attend on online Oracle course for MySQL Performance Tuning. At the very core of understanding how to tune your MySQL instance’s performance lies the requirement that you must establish a consistent baseline of which to work off of. Along with setting this baseline, comes the responsibility of making sure that test environments have a similar amount of data and load on them to accurately test any updates. Clearly for us, it is of the utmost importance to have near identical replication of production data in a staging environment for us to test (and benchmark) the process of converting these loads of data for these upgrades. For a number of our clients, this means making sure that we have enough anonymized customer and sales data to give us an accurate representation of how long these deployments will take, or if we’ll run into issues in a production environment.

And run into issues we did! Aside from the usual errors one would expect to run into caused by corrupted serialized data, or incompatible 3rd party modules, we ran into a rather bizarre (see: misleading) MySQL error during that setup:upgrade process on one of our Community Edition clients with a large amount of sales data. See the error below:

Warning: Error while sending QUERY packet. PID=14322 in /vendor/magento/zendframework1/library/Zend/Db/Statement/Pdo.php on line 228

And that’s all folks! No other exceptions, errors, warnings, clues. Nada. Digging into the code a little further, Magento was attempting to query the database, but when the MySQL instance unexpectedly threw an error during execution of the query, the application code wasn’t handling it. So, all we were left with was this somewhat vague error message from MySQL.

If you’re unfamiliar with this error, a quick Google search will point you in the direction of increasing the max_allowed_packets variable on your MySQL instance. Which is what we did… again and again until we maxed out the variable at 1G. So, what gives?

As it turns out, this particular staging instance’s MySQL instance had been greatly modified. Many variables were not only changed from the default, but drastically different than what was configured on production. Which might make sense right? Production experiences heavier loads than staging, duh. But if we go back to proper performance tuning and the goals we mentioned above, we should have remembered to not just replicate the data in staging, but the MySQL instance itself.

One system variable in particular had been significantly decreased in staging, and that was the wait_timeout variable. As defined in the official MySQL Documentation this variable defines “the number of seconds the server waits for activity on a non-interactive connection before closing it.”. We increased this variable as necessary, re-ran the deployment, and now everything worked– the deployment, specifically setup:upgrade, was successful. So again, what gives?

We came to understand that one of the queries – the query referenced in the error above – was actually timing out because it was waiting on another very large query to finish. We were able to replicate this behavior in a local environment when reducing this wait_timeout variable, running two competing queries at the same time, and constructing one of these to be very large and time consuming.

There is no way that we would have run into this issue prior to a production deployment had we not made an attempt at replicating the live MySQL instance and its data in a test environment. Overall, I think our team learned a valuable lesson about both the size of upgrading from 2.1 to 2.3, and the importance of data replication in a test environment.

Something Digital - magento

Securely Connecting Magento BI to Magento On-Premise 

Magento BI (“Business Intelligence”) is an analytics platform which aggregates data from various sources to create beautiful and actionable dashboards and reports. If you’d like to learn more about what Magento BI is and does check out our blog post “Magento BI and why you need it”.

In this blog post, we’ll look at what’s involved with connecting Magento BI to Magento from a technical standpoint, and how to do so in the most secure manner possible.

How Magento BI Connects to Magento

Per Magento’s official documentation, Magento BI connects to Magento through a MySQL connection. You’ll also see that an SSH tunnel is recommended for the connection. We agree with this recommendation as it ensures that the connection is encrypted and allows you to keep port 3306 completely closed from public access.

Securely Setting Up the Connection via an SSH Tunnel

When setting up the connection between Magento BI and Magento the principle of least privilege should be followed. In other words, Magento BI should be given the minimum level of access required on the Magento system to function.

Magento also provides documentation on setting up the connection via an SSH tunnel which follows this principle well. A few important things to call out:

  • A dedicated Linux user should be set up for Magento BI.
    • We recommend using a restricted shell as documented here.
  • A dedicated MySQL user should be created.
    • The user should not be given write access to the database as documented here.
    • Access should also be limited only to the required tables (e.g. the connection does not need access to the admin_user table).

 

Additionally, in an environment using master / slave replication, Magento BI should be configured to connect to the read slave, not the master.

Magento Commerce Cloud

If you are using Magento Commerce Cloud the process differs and is documented here.