DEV Community: Branden Thomas

Allow utf8mb4 Extension for Magento 2

Branden Thomas — Sat, 13 Jun 2026 04:39:03 +0000

Emoji in customer names, international characters in addresses, and modern marketing copy can break on older utf8 MySQL configurations. Magento 2 projects on legacy database charsets hit truncation errors and silent data loss. The Allow utf8mb4 extension helps teams adopt full Unicode storage without a risky manual migration guess. Four-byte characters fail quietly until a customer support case exposes corrupted names or addresses. Imports from marketplaces and ERPs increasingly include characters legacy utf8 cannot store. Social login and UGC features assume four-byte Unicode supportâ€”legacy charsets block modern UX.

Who needs this

Magento developers and merchants seeing database charset errors during imports, customer registration, or UGC features. Agencies inheriting older hosting environments that never moved past utf8 three-byte mode. International storefronts where localized copy and customer data include characters outside BMP.

Why teams adopt it

Magento 2.4.x expects modern MySQL collations, but long-lived stores often carry historical utf8 tables from earlier versions. Manual ALTER scripts on production are error-prone when foreign keys and index lengths differ per table. A purpose-built extension documents the Magento-specific touchpoints so developers do not guess which entities need attention. Emoji in reviews, chat, and marketing banners are table stakes for UXâ€”storage should not block them. Coordinate with hosting on innodb settings before cutover so rollback windows stay realistic. Customer registration QA should include emoji and accented characters before you call the migration done.

Key features

Purpose-built extension for utf8mb4 compatibility on Magento 2
Reduces emoji and four-byte character storage failures
Supports international storefronts and modern UX expectations
Safer path than ad hoc ALTER TABLE scripts on production
From a Magento agency familiar with upgrade and hosting constraints
Documents Magento entity touchpoints affected by charset migration
Helps teams pass UAT on customer names, reviews, and marketing content

Learn more

Explore the Magento 2 Allow utf8mb4 extension for setup details, compatibility notes, and licensing.

Charset issues look like application bugs but are database configuration problems. Fix the storage layer before blaming checkout or customer modules. Schedule charset work in a maintenance window with backups and row-size checks on large tables. Re-test imports and registration flows with real international samples after cutover. Charset migrations are finished only when support stops filing truncated-name tickets.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

Cart Slideout Cross-Sell Extension for Magento 2

Branden Thomas — Sat, 13 Jun 2026 04:28:02 +0000

Mini-cart experiences should do more than show line itemsâ€”they are the last merchandising moment before checkout. A cart slideout with cross-sell surfaces related products without forcing shoppers back to category pages, improving average order value on mobile and desktop. Most recommendation widgets sit below the fold on PDPs where few buyers scroll; the cart moment captures intent. Accessory revenue often hides in the gap between add-to-cart and pay. HyvÃ¤ slideout carts are the default UX patternâ€”merchandising should match that behavior.

Who needs this

Magento 2 retailers with attach-rate opportunities: accessories, consumables, warranties, and frequently-bought-together SKUs. Stores using slideout carts on HyvÃ¤ or Luma who want controlled cross-sell rules. Teams measuring AOV who need merchandising surfaces that do not require checkout rebuilds.

Why teams adopt it

Slideout carts are standard on modern Magento frontends, yet many still mirror core mini-cart functionality. Adding cross-sell in the slideout keeps shoppers in the purchase flow instead of sending them hunting for compatible accessories. Merchandisers control which relationships surface, so brand and margin rules stay intact. The extension targets a narrow UX upgrade compared to rebuilding cart templates from scratch. A/B test one high-margin accessory category first before rolling cross-sell rules across the catalog. Slideout placements outperform homepage carousels when shoppers already have items in cart.

Key features

Slideout cart UX with integrated cross-sell placements
Merchandiser-controlled related product presentation
Captures incremental revenue at high-intent cart moments
Designed for modern Magento frontends
Lightweight alternative to rebuilding the entire cart experience
Mobile-friendly placement where shoppers already review line items
Supports rule-based relationships instead of generic recommendation black boxes

Learn more

Explore the Cart Slideout Cross-Sell extension for setup details, compatibility notes, and licensing.

Cross-sell belongs where intent is highestâ€”the cartâ€”not only on PDP recommendations nobody scrolls to. Test slideout merchandising before funding another homepage carousel. Track attach rate per placement to prove incremental revenue, not just clicks. Start with hero SKUs that already have strong accessory attach in offline channels. Small attach-rate lifts at checkout scale faster than homepage merchandising experiments.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

Search and Navigation Extensions for Magento 2

Branden Thomas — Sat, 13 Jun 2026 04:27:23 +0000

Default Magento search and category navigation are fine for small catalogs; they become revenue leaks when shoppers cannot find variants, synonyms, or high-margin collections. Towering Media's search and navigation extension lane groups tools that improve discovery without replacing your entire PIM. Zero-result searches are often merchandising problems disguised as search bugs. Large catalogs outgrow default layered navigation faster than teams expect after the first major assortment expansion. B2B part-number search exposes gaps long before B2C teams notice.

Who needs this

Mid-market Magento merchants with large SKU counts, synonym-heavy catalogs, or complex category trees. Teams evaluating layered navigation upgrades alongside Search Intelligence. B2B catalogs where part numbers, aliases, and hidden categories determine whether a buyer finds stock.

Why teams adopt it

Monolithic search replacements are expensive and risky. Modular extensions let you improve layered navigation, synonyms, and merchandising rules incrementally. Search Intelligence covers AI-assisted relevance; the search-navigation category addresses structural findability gaps in category trees and filters. Agencies can standardize on a toolkit rather than pitching a rip-and-replace search platform for every RFP. Review site search logs monthlyâ€”recurring zero-result terms are your backlog for navigation and synonym work. Category managers should see the same zero-result list as search merchandisers.

Key features

Extension category focused on findability and browse paths
Complements Search Intelligence for AI-assisted relevance
Supports merchandising workflows beyond core Magento layered nav
Agency-tested patterns for B2B and B2C catalogs
Modular add-ons instead of a monolithic search replacement
Targets zero-result queries and weak category paths incrementally
Keeps PIM and ERP integrations intact while improving discovery

Learn more

Explore the Magento 2 search and navigation extensions for setup details, compatibility notes, and licensing.

Search is a sales channel. If zero-result queries show up in reports every week, navigation tooling deserves the same roadmap priority as checkout performance. Pair browse improvements with synonym governance so marketing and search teams share one vocabulary. Export search logs monthly to prioritize category and filter investments. Findability work compounds when you fix the same synonym gaps shoppers hit every week.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

Analytics Integrations for Magento 2 Extensions

Branden Thomas — Sat, 13 Jun 2026 04:16:38 +0000

Magento stores run on more than GA4: server-side tagging, marketplace pixels, and ERP-adjacent reporting all need reliable event hooks. Towering Media's analytics integrations category bundles extensions that connect storefront behavior to measurement stacks without fragile theme edits. When analytics live only in theme JavaScript, every frontend deploy risks silent event loss. Growth teams lose weeks reconciling GA4 gaps that trace back to a single template change. Server-side tagging projects fail when the storefront cannot emit stable events.

Who needs this

Growth and engineering teams on Magento 2 / Adobe Commerce who need dependable analytics wiring across checkout, catalog, and campaign landing pages. Agencies shipping multiple clients who want repeatable analytics modules instead of one-off GTM hacks. Merchants adopting server-side tagging or consent-mode workflows that require stable event contracts.

Why teams adopt it

HyvÃ¤ and headless frontends amplify the cost of theme-embedded pixels. Extension-based hooks fire from Magento layers that survive theme swaps. The analytics integrations lane groups modules tested across Luma, HyvÃ¤, and common checkout replacements so agencies do not reinvent dataLayer pushes per project. Consent and privacy requirements also favor centralized instrumentation you can audit once instead of scattered script tags. Document event schemas in your runbook so CRO tests do not fork incompatible payloads. Stakeholders trust dashboards only when purchase events survive theme releases without emergency hotfixes.

Key features

Curated analytics-focused extensions for Magento 2 merchants
Patterns that respect modern privacy and consent requirements
Reduces theme-level JavaScript drift across deployments
Useful alongside headless and HyvÃ¤ frontends when events must stay consistent
Documented extension lane from a Magento agency shipping since 2008
Supports repeatable agency delivery across multiple client storefronts
Centralizes event contracts for GA4, ads, and server-side tagging projects

Learn more

Explore the Magento 2 analytics integrations for setup details, compatibility notes, and licensing.

If your analytics break every time you deploy a frontend change, the problem is placementâ€”not the pixel itself. Extension-based instrumentation is easier to regression-test. Treat purchase and add-to-cart events as release gates, not post-launch surprises. Validate consent-mode behavior in staging before traffic campaigns go live. Instrumentation should be boring on deploy dayâ€”that is the goal.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

SEO Redirect Management for Magento 2

Branden Thomas — Sat, 13 Jun 2026 04:16:02 +0000

Catalog reorganizations, discontinued SKUs, and migration projects all create redirect debt. Spreadsheet imports and ad hoc .htaccess edits do not scale on Magento 2. A dedicated redirect management extension gives SEO and engineering teams a governed way to create, audit, and maintain 301/302 rules from admin. Redirect chains and loops silently dilute link equity after every category merge unless someone owns ongoing hygiene. Discontinued SKUs and merged brands generate redirect tickets faster than engineering can clear them without admin tooling. HyvÃ¤ and headless migrations multiply URL changesâ€”plan redirect ownership before cutover.

Who needs this

Magento merchants undergoing HyvÃ¤ migrations, category restructuring, or brand consolidation. SEO leads who need visibility into redirect chains without SSH access. Agencies running migration playbooks where marketing must ship URL changes on a schedule engineering cannot always meet.

Why teams adopt it

Server-level redirect tables work until hundreds of SKU discontinuations land the same week. Magento-native redirect UI keeps rules versioned with your deployment process and visible to non-SSH users. That matters during HyvÃ¤ replatforms when URL patterns change and legacy paths must map cleanly. Preventing orphaned URLs protects both crawl budget and paid landing pages that still point at old paths in ad platforms. Export redirect lists before major releases so rollback plans include URL equity, not just code. Paid search teams feel redirect debt first when old category URLs still receive budget.

Key features

Central admin UI for redirect creation and maintenance
Supports common Magento SEO migration workflows
Reduces reliance on server-level-only redirect tables
Helps prevent orphaned URLs after catalog cleanup
Built for teams that treat redirects as ongoing operations, not one-time launches
Improves collaboration between SEO and engineering during replatforms
Makes redirect audits part of regular merchandising releases

Learn more

Explore the SEO Redirect Management for Magento 2 for setup details, compatibility notes, and licensing.

Redirects are infrastructure. When marketing cannot ship a category move because engineering is busy, you need admin-owned redirect toolingâ€”not another CSV over the wall. Audit redirects after every major catalog release the same way you regression-test checkout. Watch for chains longer than two hops; they dilute equity and slow crawlers. A single admin-owned redirect tool beats a quarterly emergency CSV every time.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

Choose Your LLM Provider for Magento 2 Search Intelligence

Branden Thomas — Sat, 13 Jun 2026 04:05:24 +0000

AI-assisted merchandising in Magento should not lock you into one vendor's model on day one. Towering Media's Search Intelligence LLM Provider add-on lets stores choose and configure the large-language-model backend that powers selected Search Intelligence workflowsâ€”without forking your entire search stack. Model pricing, latency, and data residency policies change quarterly; hard-coding one provider into catalog tooling ages poorly. Merchants evaluating AI features should separate model contracts from the search features shoppers actually see.

Who needs this

Magento 2 merchants already using Search Intelligence Core who want flexibility across LLM providers for content, synonym, or automation tasks. Agencies standardizing on Search Intelligence but serving clients with different AI compliance requirements. Teams piloting generative merchandising who need to swap models without redeploying custom modules.

Why teams adopt it

Search Intelligence Core handles relevance, synonyms, and merchant workflows inside Magento admin. The LLM Provider add-on isolates the model endpoint configuration so operations can respond to vendor changes without touching search indexing code. That separation mirrors how mature teams treat payment gateways: business logic in Magento, credentials and routing in configuration. For agencies, one Search Intelligence baseline across clients with per-tenant model settings reduces forked custom code. Pilot on non-production catalogs first so synonym and content experiments do not affect live revenue. Operations teams should own API key rotation the same way they manage payment gateway credentials.

Key features

Configurable LLM provider selection within Search Intelligence
Keeps AI features inside Magento admin workflows merchants already use
Supports teams that need to swap models as pricing or policy changes
Pairs with the broader Search Intelligence suite for Magento 2
Agency-friendly extension model from a long-running Magento specialist
Isolates API keys and endpoints from catalog indexing code paths
Eases compliance reviews when clients restrict specific model vendors

Learn more

Explore the Search Intelligence LLM Provider add-on for setup details, compatibility notes, and licensing.

Model choice is becoming an operational decision, not a science experiment. If AI search or merchandising is on your roadmap, pick tooling that separates provider configuration from catalog logic. Document which workflows call external models so security reviews stay straightforward. Revisit provider settings when contracts renewâ€”latency and cost profiles shift quickly. Treat the LLM layer as infrastructure with its own change-control checklist.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

Product FAQ Extension for Magento 2 SEO and Conversion

Branden Thomas — Sat, 13 Jun 2026 04:04:47 +0000

Product detail pages lose sales when shoppers cannot find answers about fit, compatibility, or shippingâ€”and search engines miss long-tail questions your support team answers daily. A structured product FAQ block on PDPs improves conversion and gives merchandisers a controlled place to publish buyer questions with schema-friendly markup. FAQs also reduce bounce when shoppers would otherwise open a new tab to search your brand plus a part number. Considered-purchase buyers often abandon when specs are buried in PDFs instead of scannable Q&A.

Who needs this

Magento merchants with technical or considered-purchase catalogs: industrial parts, supplements, electronics, and configurable products where pre-purchase questions block add-to-cart. SEO teams chasing rich results for question queries and support leads measuring ticket volume per SKU both benefit from PDP-native answers.

Why teams adopt it

Blog posts and knowledge bases rarely rank for SKU-specific questions. PDP FAQs keep answers next to the buy button where hesitation happens. Admin assignment by product or attribute set lets merchandisers scale content without developer deploys for every new SKU. Schema-oriented structure gives SEO teams a lever beyond generic meta descriptions. The extension stays lightweight compared to bolting a full CMS onto catalog entities. Start with your top twenty SKUs by revenue and expand FAQ coverage as support tags reveal patterns. PDP FAQs also give sales teams approved language for chat and phone quotes.

Key features

Admin-managed FAQs assigned to individual products or attribute sets
On-page FAQ presentation designed for product detail conversion
SEO-oriented FAQ structure for common buyer questions
Reduces repetitive support tickets for the same PDP questions
Lightweight extension pattern that does not require a full CMS rebuild
Merchandiser-friendly workflows without per-SKU developer tickets
Keeps answers synchronized with catalog changes and discontinuations

Learn more

Explore the Magento 2 Product FAQ extension for setup details, compatibility notes, and licensing.

If your support inbox repeats the same product questions, those answers belong on the PDPâ€”not only in email templates. Structured FAQs help humans and search engines at once. Review top ticket drivers quarterly and promote them to published FAQs before peak season. Pair FAQ content with internal links to sizing guides or compatibility charts where relevant. Even five well-written FAQs on a hero SKU can move conversion measurably.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

USPS Add-on for Multivendor Dropship on Magento 2

Branden Thomas — Sat, 13 Jun 2026 03:54:05 +0000

Marketplace and multivendor Magento stores cannot rate USPS from a single global origin. Each vendor warehouse needs its own ship-from context, and USPS now expects OAuth-backed REST API v3 callsâ€”not legacy Web Tools XML. This USPS add-on extends Towering Media's multivendor dropship shipping stack with vendor-aware USPS rating. Legacy XML outages are no longer edge cases; they are the default risk for unmigrated integrations.

Who needs this

Multivendor Magento 2 merchants using Towering Media dropship shipping for FedEx or UPS who also need USPS from vendor origins. Agencies migrating marketplace clients off broken legacy USPS integrations will recognize the vendor-origin requirement immediately. Marketplaces where vendors ship Media Mail or Priority from their own docks cannot share one store-level USPS credential.

Why teams adopt it

USPS API v3 and OAuth client credentials are the new baseline. Dropship marketplaces that quoted from a single origin looked fine until vendors demanded accurate USPS options for lightweight SKUs. This add-on plugs into the same multivendor split-shipment model as FedEx and UPS dropship modules, so checkout sees one coherent experience while backends fan out vendor-specific rate requests. That architecture prevents the common bug where marketplace orders show $0 shipping because USPS failed silently for secondary origins. Treat vendor warehouse addresses as first-class shipping origins in QA, not optional metadata. Split-shipment checkout is unforgiving when one origin still uses deprecated USPS XML credentials.

Key features

USPS REST/OAuth rating integrated into multivendor dropship workflows
Vendor-specific origin addresses flow into USPS rate requests
Pairs with the broader multi-vendor FedEx, USPS, and UPS dropship suite
Avoids treating marketplace shipping as a single-store carrier configuration
Built for Magento 2 / Adobe Commerce checkout and admin patterns
Supports OAuth credential flows required by USPS API v3
Helps marketplaces quote lightweight vendor SKUs with accurate USPS options

Learn more

Explore the USPS add-on for multivendor dropship for setup details, compatibility notes, and licensing.

When only the main warehouse shows USPS but vendor lines do not, the fix is usually origin-aware carrier logicâ€”not another global USPS credential. Extend dropship shipping instead of bolting core USPS onto marketplace quotes. Plan OAuth credential rotation per vendor or per warehouse according to your marketplace rules. Test split carts with multiple vendor origins before launch.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

Standalone FedEx Dry Ice Shipping for Magento 2

Branden Thomas — Sat, 13 Jun 2026 03:53:29 +0000

Perishable and temperature-sensitive products need more than a generic FedEx rate quote. Dry ice shipments require correct service mapping, package handling assumptions, and carrier rules that core Magento does not ship out of the box. Towering Media's standalone FedEx Dry Ice extension gives merchants a focused carrier module for this lane. Without dry-ice-aware logic, checkout may hide valid services or quote rates that operations cannot actually fulfill.

Who needs this

Food, supplement, lab-sample, and cold-chain Magento merchants that ship with dry ice via FedEx. Also useful for agencies supporting clients who cannot use a full multi-carrier suite but still need compliant dry-ice rating at checkout. Operations teams tired of manually overriding shipping after customers pick the wrong method at checkout are a common buyer profile.

Why teams adopt it

FedEx REST migrations already forced many Magento stores to revisit carrier extensions. Dry ice adds another layer: not every FedEx service accepts dry ice packaging, and quoting the wrong option creates chargebacks and reship costs. A stand-alone module lets you adopt dry-ice rating without buying the entire Towering Media carrier bundleâ€”useful when UPS or USPS are handled elsewhere. Admin configuration ties services to your origin and cold-chain SOPs so merchandising and ops stay aligned. Staging tests should include weight breakpoints and transit times your CS team promises on PDPs.

Key features

FedEx dry-ice-focused shipping method for Magento 2
Works as a stand-alone extension without requiring the full Towering Media carrier bundle
Admin configuration for services and origin assumptions tied to cold-chain workflows
Designed for real-time rating alongside standard checkout flows
Maintained by a Magento agency with production FedEx REST migrations
Reduces checkout surprises when PDPs promise overnight cold-chain delivery
Fits merchants who only need FedEx dry iceâ€”not a full multi-carrier rewrite

Learn more

Explore the FedEx Dry Ice stand-alone extension for setup details, compatibility notes, and licensing.

If dry-ice failures show up as missing methods or wrong service levels at checkout, treat it as a carrier specialization problemâ€”not a theme bug. A purpose-built module is usually faster than patching generic FedEx logic. Validate rates against your warehouse cutoffs and transit promises before peak season, when support tickets spike. Document which SKUs require dry ice so CS and merchandising share the same assumptions at checkout.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

Add Apple Pay, Google Pay, and PayPal Express to Magento 2 Checkout

Branden Thomas — Sat, 13 Jun 2026 03:42:31 +0000

Shoppers expect wallet buttons at the top of checkoutâ€”not buried behind a long address form. The React Checkout Pro Express Add-on adds an express wallet row above the checkout form in Towering Media's React Checkout Pro, so high-intent buyers can approve payment and shipping in one step. Mobile conversion often dies in the first three fields of a traditional checkout. Express wallets skip repetitive data entry by returning verified email, shipping, and payment tokens from Apple, Google, or PayPal directly into your Magento order pipeline.

Who needs this

Magento 2 and Adobe Commerce stores already running React Checkout Pro that want faster mobile checkout without rebuilding payment integrations. It fits B2C brands where cart abandonment spikes on phones and stores that already support guest checkout or smart account creation. Marketing teams pushing paid social traffic to mobile landing pages also benefitâ€”every extra form field costs measurable revenue.

Why teams adopt it

Core Magento checkout and many Luma themes treat wallets as afterthoughts. React Checkout Pro already modernizes the flow with a React SPA; the Express Add-on layers wallet authorization on that foundation without forking payment modules. PayPal Express talks to Magento backends directly, so returned addresses stay consistent with your shipping rules. Apple Pay requires domain verification in adminâ€”plan that step during staging, not launch day. Google Pay appears only where the browser supports it, which prevents the broken-button experience that hurts trust.

Key features

Express wallet row at the top of checkout (admin toggle, disabled by default on new installs)
Apple Pay on Safari macOS/iOS with verified-domain support
Google Pay on supported Chrome browsers
PayPal Express with one-click approval and address return via direct backend calls
Auto-fills email and shipping from wallet data; shows only buttons that work on the shopper's device

Learn more

Explore the React Checkout Pro Express Add-on for setup details, compatibility notes, and licensing.

Wallet-first checkout is not a theme tweakâ€”it is a dedicated express layer on top of a modern React checkout. If your team is optimizing conversion on mobile, start with express buttons that respect device capabilities instead of showing broken payment options. Measure drop-off before and after enabling the row; most merchants see the biggest lift on Safari iOS and Chrome Android.

Branden Thomas, cofounder of Towering Media Co. https://toweringmedia.com

AI-Powered Search for Magento 2: What It Actually Changes for Merchants

Branden Thomas — Sat, 13 Jun 2026 03:41:58 +0000

"AI search" gets pitched to Magento merchants as magic: flip a switch, conversions go up, SEO fixes itself. The reality is more practicalâ€”and more valuable when you understand what actually changes at checkout, on category pages, and in your search reports.

At Towering Media, we ship search and AI tooling for Magento 2 stores daily. This article explains what AI-powered site search means for merchantsâ€”not in vendor-slide language, but in terms of autocomplete behavior, synonym management, relevance tuning, and the conversion metrics you can measure this quarter.

Default Magento search is a catalog filter, not a sales tool

Out of the box, Magento search matches keywords against product attributes. It does not understand that "sneakers" and "running shoes" are the same intent. It does not learn from queries that return zero results. It does not surface bestsellers when relevance scores tie.

Merchants feel this as:

Shoppers type natural language and get empty results
Autocomplete shows SKU fragments instead of products people buy
Marketing teams maintain synonym lists in spreadsheets that never reach production
Search reports show volume but not revenue per query

AI-powered search in Magento does not replace your catalog. It improves how shopper intent maps to productsâ€”and gives you levers to tune that mapping without redeploying code.

What changes: autocomplete that sells

The first visible upgrade is search autocomplete. Good AI-assisted autocomplete does more than prefix-match product names:

Ranks suggestions by purchase probability, not alphabetical order
Groups products, categories, and popular queries in one dropdown
Handles typos and partial words ("runing shos" â†’ running shoes)
Respects stock status and visibility so you do not suggest unavailable items

For merchants, the measurable outcome is search-to-cart rate on autocomplete clicks vs full search results page visits. Stores with slow or irrelevant autocomplete lose high-intent shoppers before they see a product grid.

When evaluating search tooling, ask: can merchandisers adjust autocomplete ranking weights without a developer ticket? If not, you will not iterate fast enough to matter.

What changes: synonym management that stays in sync

Synonyms are where most Magento stores leak revenue. A B2B industrial supplier sells "hex bolts" and "hex cap screws"â€”same product family, different search terms. A fashion retailer sells "trainers" and "sneakers" depending on customer geography.

Traditional approach: maintain a CSV, hope someone imports it, discover six months later it was never deployed.

AI-assisted search platforms built for Magento should offer:

Admin-managed synonym groups (two-way and one-way: "laptop" â†’ "notebook")
Query log analysis that surfaces zero-result searches worth adding as synonyms
Conflict detection when a synonym would override a intentional redirect or landing page

The merchant win is operational: your customer service team hears "I couldn't find X" less often, and your SEO team stops fighting internal search cannibalization.

Tools like Search Intelligence Core for Magento 2 bundle synonym management with broader SEO automationâ€”connecting on-site search behavior to indexation and content gaps, not just the search results page.

What changes: relevance tuning merchants can understand

"Relevance tuning" sounds like a data science project. For Magento merchants, it should mean adjustable weights on factors you already care about:

Signal	Merchant use
Conversion rate per product	Boost bestsellers for ambiguous queries
Margin or MAP constraints	Deprioritize low-margin matches when ties occur
New arrivals	Temporary boost during launch windows
Review score	Surface highly rated variants first
Category intent	Prefer "parts" category when query includes model numbers

AI does not remove the need for merchandising judgment. It gives merchandisers sliders and rules instead of Elasticsearch YAML files.

Start with one category that has high search volume and confusing nomenclatureâ€”automotive parts, medical SKUs, or configurable B2B catalogs. Run a two-week A/B: default Magento search vs tuned relevance. Track revenue per search session, not just click-through rate.

What changes: conversion rates (with realistic expectations)

Merchants ask us: "What lift should we expect?" Honest answer: 8â€“25% improvement in search-attributed conversion is common when you fix zero-result queries and autocompleteâ€”but only if search already drives meaningful traffic.

If only 3% of sessions use search, sitewide conversion lift will look small even when search conversion doubles. Check your analytics first:

Search usage rate â€” % of sessions with at least one search
Zero-result rate â€” queries returning no products
Search exit rate â€” searches followed by session end without add-to-cart
Revenue per search â€” tie search queries to order attribution

AI search pays off fastest when (a) search usage is above 15% of sessions, or (b) your catalog is large enough that browse navigation fails shoppersâ€”5,000+ SKUs, heavy configurables, or multi-attribute B2B catalogs.

Quick wins before any extension purchase:

Export 90 days of search terms; fix the top 20 zero-result queries manually (synonyms, redirects, or new products)
Measure autocomplete latency; anything over 200ms feels broken on mobile
Ensure searchable attributes actually contain how customers describe products

AI search vs AI customer service

Search handles product discovery; conversational AI handles order questions and policy queries. Nora AI for Magento 2 complements search tuningâ€”it does not replace it.

Implementation reality on Magento 2

Whether you use native Elasticsearch/OpenSearch, Algolia, or a Magento-native suite, AI features only work if:

Product data is clean â€” searchable attributes populated, configurable children indexed correctly
Staging matches production â€” tune relevance on a copy with real catalog volume
HyvÃ¤/Luma/PWA frontends â€” autocomplete JavaScript must match your theme; test mobile INP
Cache invalidation â€” synonym changes should appear within minutes, not after overnight reindex only

Avoid "AI" modules that are thin wrappers around a single API call with no admin tooling.

Bottom line

AI-powered search for Magento is not about chatbots on your homepage. It is about autocomplete that converts, synonyms your team can maintain, and relevance rules tied to business outcomesâ€”with metrics merchants already track.

If search drives meaningful traffic and your catalog is hard to navigate, the ROI case is straightforward. If search is an afterthought, fix analytics and data quality first; AI will not rescue an empty description field.

For a Magento-native approach that connects search intelligence to SEO workflows, see Search Intelligence Core. For customer-facing AI beyond product discovery, explore Nora AI.

About the author: Branden Thomas is cofounder of Towering Media, a Chicago Magento agency since 2008. Towering Media builds AI-powered search, SEO, and customer service extensions for Magento 2 and Adobe Commerce merchants across the US and Canada.

UPS Just Deprecated Their XML API: Magento 2 Migration Guide

Branden Thomas — Sat, 13 Jun 2026 03:29:09 +0000

If your Magento store still pulls UPS rates through the legacy XML API, treat that integration as expiredâ€”not "working fine for now."

UPS has been winding down XML access in favor of REST APIs with OAuth 2.0. Magento's built-in UPS carrier was built for the old model: Access Key, User ID, Password, and XML payloads over HTTP. That stack is increasingly unreliable, and when it fails, checkout shows no UPS options with little useful error detail in admin.

At Towering Media, we have migrated US and Canadian merchants off UPS XML alongside FedEx SOAP and USPS Web Tools migrations. This guide covers what changed, how to audit your store, and the production path we use for Magento 2 and Adobe Commerce.

What UPS changed (and why XML is a liability)

The legacy UPS integration most Magento stores know is the XML Rating and Shipping API accessed with static credentials. UPS now expects new integrations on the UPS Developer Portal using:

REST endpoints (Rating, Shipping, Tracking as separate APIs)
OAuth 2.0 client credentials (short-lived access tokens)
JSON request and response bodies
Separate sandbox and production credentials

This is not a URL swap. Authentication, error handling, and payload structure all differ from XML.

SOAP/XML failures tend to arrive without warning:

UPS methods disappear from checkout while other carriers work
Rate requests return empty with no admin log entry
Label or tracking jobs fail during peak season when legacy throttling kicks in

If you already migrated FedEx or USPS to REST, UPS is the remaining legacy legâ€”delaying it leaves a single point of failure.

Step 1: Inventory every UPS touchpoint

Before changing credentials, map where UPS is used:

Stores â†’ Configuration â†’ Sales â†’ Delivery Methods â†’ UPS â€” core carrier settings
Custom modules â€” search for Ups, ups, AccessLicenseNumber, RatingService
Marketplace and dropship extensions â€” vendor-origin rating often wraps the legacy UPS model per warehouse
ERP, WMS, and label crons â€” batch jobs may hardcode XML endpoints

From your Magento root:

grep -ri "ups" app/code vendor/your-namespace --include="*.php" --include="*.xml" | grep -i "rate\|ship\|carrier"

Document which environments use production vs test credentials. REST OAuth keys are not interchangeable with XML Access Keys.

Step 2: Create UPS REST credentials

In the UPS Developer Portal:

Create an application (or use your organization's existing app)
Enable Rating API and Shipping API if you print labels from Magento
Note your Client ID, Client Secret, and UPS account number
Start in the Customer Integration Environment (CIE) sandbox; production credentials are separate

OAuth uses the client credentials grant:

POST https://wwwcie.ups.com/security/v1/oauth/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64(client_id:client_secret)

grant_type=client_credentials

Production uses https://onlinetools.ups.com/security/v1/oauth/token. The response includes a short-lived access_token you must cacheâ€”not request fresh on every rate call.

Step 3: Choose your Magento implementation path

Option A: Core or Adobe Commerce updates

Check whether your Magento version ships a maintained UPS REST carrier. If yes, plan an upgrade-first path and regression-test rates against your last known XML baselines.

Option B: Replace with a maintained REST extension

For most merchants we support, a dedicated Magento 2 UPS REST API shipping extension is faster and lower risk than patching core. Look for:

OAuth token caching with automatic refresh before expiry
Configurable services (Ground, 3 Day Select, Next Day Air) mapped to Magento methods
Residential and commercial address handling from quote data
Structured logging with masked credentials
HyvÃ¤ and headless checkout compatibility

Option C: Custom module

Build a carrier model that maps RateRequest to UPS REST JSON only for unique multi-origin or packaging logic. Marketplace stores should audit multi-vendor FedEx, USPS, and UPS dropship integrations alongside UPS migration.

Step 4: Parallel-test rates on staging

Never flip production in one deploy. Run XML (if still working) and REST side by side on staging:

Configure REST with CIE sandbox credentials
Build a basket matrix: light parcel, heavy parcel, residential vs commercial, Alaska/Hawaii if applicable
Compare REST quotes to last known XML quotes (small deltas are normal; large gaps mean wrong service mapping)

Example REST rating request structure (simplified):

{
  "RateRequest": {
    "Shipment": {
      "Shipper": { "Address": { "PostalCode": "60601", "CountryCode": "US" } },
      "ShipTo": { "Address": { "PostalCode": "90210", "CountryCode": "US" } },
      "ShipFrom": { "Address": { "PostalCode": "60601", "CountryCode": "US" } },
      "Package": { "PackagingType": { "Code": "02" }, "PackageWeight": { "Weight": "5", "UnitOfMeasurement": { "Code": "LBS" } } }
    }
  }
}

Log full request/response pairs during testing. UPS REST error payloads are JSON and far easier to debug than XML fault strings.

Step 5: Cut over and monitor

Once rates match:

Disable the legacy UPS carrier in admin (keep config for rollback one sprint)
Enable the REST carrier with production OAuth credentials
Re-test checkout: guest, logged-in, multi-shipment quotes if applicable
Update ERP/WMS mappings if tracking number formats changed
Monitor logs for 401/403 spikesâ€”usually expired or uncached tokens

Run bin/magento cache:flush after deployment and verify env.php does not lock old carrier settings.

Common migration pitfalls

Negotiated vs published rates. REST requires explicit rate request types. If you only request list rates, account-negotiated pricing may not appear.

Dimensional weight. REST is stricter about package dimensions. Weight-only requests can produce mismatches vs the old XML integration.

Multi-origin dropship. Vendor modules that call UPS per origin need each ship-from address in the REST payload. One global origin config is not enough for marketplace stores.

Token thrashing. Requesting a new OAuth token on every rate call adds latency and can trigger UPS rate limits.

Why this is urgent

FedEx SOAP and USPS Web Tools migrations are already production reality for most serious Magento stores. UPS XML is the remaining legacy carrier for many US merchants. Peak season is the worst time to discover your rating integration no longer responds.

If checkout shipping is business-critical, schedule UPS REST migration this quarterâ€”not after your next FedEx/USPS fire drill.

Summary checklist

[ ] Audit codebase and extensions for legacy UPS XML usage
[ ] Create UPS Developer Portal REST + OAuth credentials (CIE sandbox first)
[ ] Implement REST carrier (extension or custom) with token caching
[ ] Parallel-test rate matrix on staging
[ ] Cut over production; monitor errors for 72 hours
[ ] Revoke legacy XML Access Keys in the UPS portal

About the author: Branden Thomas is cofounder of Towering Media, a Chicago Magento and Adobe Commerce agency since 2008. Towering Media builds UPS REST, FedEx REST, and USPS OAuth shipping integrations for US and Canadian merchants.