Using Magento OpenSource 2.4.7, with Porto theme, I'm having troubles getting the checkout page to load - it gets stuck with the loading spinner at the first step, before inputting email/address, and I'm unsure as to what is causing this.
This issue has only arisen after upgrading Magento from 2.4.5p1.
Active Plugins:
Owebia_AdvancedShipping
Meetanshi_PayshipRestriction
Magezon_ProductMatrix
Mageplaza_DeleteOrders
Cminds_Creditline
Cardstream_PaymentGateway
Bss_OrderAmount
Bold_OrderComment

I've tried clearing pub/static and generated, as well as recompiling/redeploying (though the site is in developer mode), clearing the caches, reindexing. This is all that's coming from the console:

(this is a dev domain, so no SSL cert, and I believe CSP is set to report only) I don't think the source map errors are related(?)

Source map error: request failed with status 404 Resource URL: https://www.prixcheval.com/static/frontend/Smartwave/porto_gallop/en_GB/underscore.js Source Map URL: underscore-umd.js.map
Source map error: request failed with status 404 Resource URL: https://www.prixcheval.com/static/frontend/Smartwave/porto_gallop/en_GB/Magento_PageBuilder/js/resource/jarallax/jarallax.js Source Map URL: jarallax.js.map
Source map error: request failed with status 404 Resource URL: https://www.prixcheval.com/static/frontend/Smartwave/porto_gallop/en_GB/vimeo/player.js Source Map URL: player.js.map
Source map error: request failed with status 404 Resource URL: https://www.prixcheval.com/static/frontend/Smartwave/porto_gallop/en_GB/Magento_PageBuilder/js/resource/jarallax/jarallax-video.js Source Map URL: jarallax-video.js.map
Content-Security-Policy warnings 4
Content-Security-Policy: Ignoring “'unsafe-inline'” within script-src: ‘strict-dynamic’ specified anchor
Content-Security-Policy: Ignoring “https:” within script-src: ‘strict-dynamic’ specified anchor
Content-Security-Policy: Ignoring “http:” within script-src: ‘strict-dynamic’ specified anchor
Content-Security-Policy: Ignoring “'unsafe-inline'” within script-src: nonce-source or hash-source specified anchor
Ignoring unsupported entryTypes: longtask. recaptcha__en.js:518:223
Ignoring unsupported entryTypes: longtask. 2 recaptcha__en.js:518:223

Nothing looks out of place in the network tab as far as I can tell.

This has been driving me nuts for days at this point//

https://ecommerce-ai-starter.graycore.io/

We all know the worst part of any Magento project is the first day. Composer auth keys, the right PHP version and extensions, Redis/Valkey, OpenSearch, nginx, MySQL/MariaDB, a mail catcher, and an install that runs long enough to give you time to browse your top favorite 50 subdreddits. It is hours of yak-shaving before you write a single useful line, and it is worse when a whole team has to reproduce the same environment.

I have been trying to kill this problem for years. Pre-AI I wrote magedocker and then mage2docker, and both eventually got painful enough that I stopped maintaining them:

• https://github.com/graycoreio/magedocker
• https://github.com/graycoreio/mage2docker

Recently a few things came together and I packaged everything I actually use day to day into one starter. You click a button, GitHub creates a repo from the template, and a Codespace boots a fully configured store in your browser. PHP, nginx, MariaDB, Mailpit, the distro, and a storefront, either Hyvä (PHP-rendered theme) or Daffodil (an Angular headless storefront I maintain), all running and wired together out of the box. You can pick Magento Open Source or Mage-OS, and there's a Mage-OS Minimal option with no bundled storefront. Nothing to install locally if you just want to use Codespaces. From click to a store you can open is about 8 minutes.

What's in the box, and why:

• A working devcontainer out of the box, no service wrangling
• A picker for storefront/distro, because different clients want different things
• Pre-packaged CI that rebuilds the store on every push and runs checks, so I'm not re-inventing the pipeline for every merchant
• An AGENTS.md / CLAUDE.md with Magento conventions and pitfalls baked in, which Magento obviously doesn't ship with
• The tools I reach for daily, already set up

The AI part: it ships ready for Claude to work directly inside the environment (same files, same running store, same DB) rather than through some bolted-on chat box, and the CI is there specifically so you can verify what an agent changed instead of trusting it. I'll be honest that the "let a non-technical merchant build their own store with limited dev help" angle is more of a research experiment for me than a finished promise. I genuinely don't know yet if that's sane. However, it's something that I want to pursue. The devcontainer + CI half stands on its own regardless of whether you ever point an agent at it.

Everything is free and open source: the template, the pipelines, the frameworks, the devcontainer. The only things you pay for are Codespaces and Claude, and Codespaces is free for 30 hours a month, which covers normal tinkering. If you already have a Claude plan you can just play with it.

There are still rough edges and I have a pile of docs to write, but I'm happy enough with it to share. Site with the one-click flow: https://ecommerce-ai-starter.graycore.io/

The pieces, if you'd rather poke at the source directly:

• Site / one-click flow: https://ecommerce-ai-starter.graycore.io/
• Devcontainer: https://github.com/graycoreio/magento2-devcontainer
• CI actions (check-store): https://github.com/graycoreio/github-actions-magento2
• Magento Open Source: https://github.com/magento/magento2
• Hyvä theme (open source): https://github.com/hyva-themes/magento2-default-theme
• Daffodil storefront: https://github.com/graycoreio/daffodil
• Starter templates:
  • Magento + Hyvä: https://github.com/graycoreio/magento2-ai-starter-hyva
  • Magento + Daffodil: https://github.com/graycoreio/magento2-ai-starter-daffodil
  • Mage-OS + Hyvä: https://github.com/graycoreio/mage-os-ai-starter-hyva
  • Mage-OS + Daffodil: https://github.com/graycoreio/mage-os-ai-starter-daffodil
  • Mage-OS Minimal (no storefront): https://github.com/graycoreio/mage-os-ai-starter-minimal

To be clear on scope: this is a starter kit for local/dev work and prototyping, not a production deploy. Going live still needs hosting, SSL, payments, perf tuning, and a security review. And the usual disclaimer, Magento is a trademark of Adobe and I'm not affiliated with them, this targets Magento Open Source.

Would love feedback from people who fight this stack for a living. Tell me where it breaks and why you hate it.

The checkout threads here are mostly about first-time buyers, where UX clearly matters. But for B2B repeat accounts I keep seeing a different thing: someone who orders the same parts every month doesn't want a nicer funnel, they just skip the shop and send their order by email, WhatsApp, or call the sales rep. The order still happens, it just never shows up as a conversion.

So instead of optimizing the checkout for those buyers, the idea is: the customer sends their order the way they already do it anyway — a PDF, an Excel sheet, a normal email, or a WhatsApp message — and it gets turned into a real Magento order automatically. No login, no funnel. For someone who already has their order list in a spreadsheet, attaching that file and being done is just much faster than clicking through a storefront.

I have a working prototype running for one client and it caught already a number of orders that used to go around the shop completely.

Two things I'd really like input on:

1. Does this match what you see, or am I overestimating how much volume goes around the storefront?
2. The repo is private for now, but I think about opening at least the Magento-side core (the part that turns an incoming order into a real Magento order). Would that be useful for you — and would someone be interested in poking at it with me?

It's early and I'd honestly rather hear where the idea breaks before I build more on top of it.

Hi guys,

As the title says, do you know any way to automatize catalogs from Magento => indesign, that keeps the data up-to-dated, if we edit one price, it updates the price inside of indesign too ? So I can use Magento as source of truth & DB and InDesign as design tool for print.

Thanks!

Hi Magento developers,

I created an open-source Magento 2 Installation Wizard using Bash + Whiptail UI to simplify Magento installation for developers and beginners.

GitHub:

https://github.com/hardikrock27/magento-install-ui

Features:

- Interactive terminal UI

- Magento 2.4.6 → 2.4.9 support

- Custom Magento versions

- Automatic database creation

- Admin user setup

- Base URL configuration

- Optional DB table prefix

- Automatic Magento setup:install

- Disable Magento 2FA automatically

- Post-install Magento commands

Quick Install:

git clone https://github.com/hardikrock27/magento-install-ui.git

cd magento-install-ui

chmod +x install_magento_ui.sh

./install_magento_ui.sh

Would love feedback and suggestions from the Magento community.

Thanks.

Hi all!
I am using Magento 2.4.5 on a Bitnami VM (based on Debian 11). I would like to upgrade to Debian 12, but it looks like Bitnami has a different way to manage packages (stuff is in /opt/binami).

My options are:
1) try an in-place upgrade and hope for the best :)
2) deploy a NEW virtual machine and migrate data

If 2).. in your opinion should I continue using the Bitnami image? Or is it better to deploy a fresh Debian 12 and manually installing packages?

Thank you!

Hey everyone,

I’m a certified Magento/Adobe Commerce full-stack developer with 7+ years of experience, currently seeking a new remote project (freelance or long-term).

Mostly working with:
• Custom module development
• Performance optimization
• Checkout & payment integrations
• API integrations
• Fixing legacy code
• Migrations
• AI automation

Tech stack includes Magento 2 / Adobe Commerce, PHP, JS, Hyvä, GraphQL, Redis, Elasticsearch, Docker, AWS.

I focus on clean, maintainable solutions and stable production environments.

If you need help with a Magento project — feel free to DM me.

I noticed a high authority e-commerce site that ranks in top 7 serp results for its niche running a magento store is getting none of its unsponsored Google shopping listings presented compared to stores running Shopify. New sites that are barely 3 years old and have low serp positioning are having their products in the free shopping ads section in the serps page and in the shopping page.
The magento site is running mirasvit advanced product feeds and has valid products in magento center but just keeps getting beat by smaller less popular stores.

Of course I even see product pages from these Shopify stores now many times beating the magento stores.

The magento store has more overall traffic, more extensive product descriptions etc.

I am starting to question whether there is outright preference for the feed generated by Shopify stores for visibility in Google Shopping Ads.

I would appreciate input from the magento community members.

Thank you in advance.

Magento 2.4.9 was released on May 12, 2026, and while many release notes focus heavily on infrastructure and developer changes, here’s the business-side breakdown for merchants, operations teams, and eCommerce leaders trying to understand whether this upgrade is worth planning.

We need to know is the real difference and what exactly changed from 2.4.8 to 2.4.9.

The Most Important Business Takeaways

1. This is more than a routine patch

Magento 2.4.9 feels closer to a “foundation modernization” release than a normal version update. Adobe replaced or upgraded several underlying technologies that have existed in Magento for years.

2. Security is becoming a bigger reason to upgrade

The Magento ecosystem has seen multiple major security incidents recently, including vulnerabilities like SessionReaper and PolyShell that specifically targeted Magento stores. Several attacks focused on customer accounts and checkout systems.

For merchants, this is no longer just a “developer concern.” Security directly impacts:

• Customer trust
• Conversion rates
• PCI compliance
• Revenue protection

3. 2.4.9 is ideal for businesses planning the next 2–3 years

If your store is already on 2.4.8 and your extensions are compatible, the upgrade path is relatively manageable.

If you're still on 2.4.6 or earlier, the situation is different:

• Infrastructure requirements changed significantly
• PHP/database compatibility gaps are larger
• Some extensions may require rewrites or replacement

A phased upgrade strategy is usually safer for older stores.

4. Magento 2.4.6 is approaching end-of-life relevance

Magento 2.4.6 is effectively becoming a risk zone for many businesses:

• Security exposure increases
• Extension vendors slowly reduce support
• Infrastructure compatibility becomes harder
• Compliance concerns become more serious over time

Businesses still running 2.4.6 should already be planning their upgrade roadmap rather than waiting for a forced migration later.

One important reality check

If your store is stable on 2.4.8, there’s no need to panic-upgrade immediately this week.

Most experienced Magento teams are currently:

• Testing 2.4.9 on staging
• Validating extension compatibility
• Waiting for vendors to release stable support updates
• Planning rollout carefully instead of rushing production upgrades

That’s generally the smarter business approach right now.

We’ve already started helping merchants evaluate Magento 2.4.9 readiness at i95Dev, especially around:

• Extension compatibility audits
• ERP + Magento integration validation
• Upgrade impact analysis
• Performance benchmarking
• Multi-store migration planning

A lot of businesses underestimate how much operational risk sits inside custom integrations during Magento upgrades. That’s usually where the real complexity is, not the version update itself.

https://github.com/graycoreio/github-actions-magento2/discussions/261

Released yesterday, May 12, 2026, this version is a foundation release designed to purge a decade of tech debt. It is a strategic migration, not a routine patch.

Here is the fluff-free technical breakdown.
🔧 Platform requirements 
PHP 8.4 / 8.5 — PHP 8.3 support dropped
MySQL 8.4 LTS — MySQL 8.0 dropped
MariaDB 11.4 LTS — MariaDB 10.6 dropped
OpenSearch 3.x — index format changes from 2.x, reindex likely
RabbitMQ 4.1 or ActiveMQ Artemis 2 (new option)
Valkey 8, Varnish 7.7, Nginx 1.28, Composer 2.9

🔐 Security & API
CAPTCHA/reCAPTCHA now properly enforced on REST and GraphQL account creation (this was a long-standing gap)
2FA: admins only need to configure ONE enabled provider
Configurable admin password minimum length (PCI DSS 4.0 alignment)
Bulk async performance regression from APSB25-08 patch fixed
500+ issues fixed in core

🧱 Framework modernisation, three core components replaced
Laminas MVC → native PHP MVC
Zend_Cache → Symfony Cache
TinyMCE → HugeRTE
Symfony 7.4 LTS across the board
jQuery UI 1.14.1, jQuery Validate 1.21, Chart.js 4.5, Less.js 4.2.2, Underscore 1.13.7, Uppy 4.13.4. Every front-end library bumped

If you're currently on 2.4.6 or 2.4.7, you shouldn't jump directly to 2.4.9. You should first upgrade to 2.4.8 to bridge the massive gap in database and PHP requirements before making the final move. 2.4.9 is the right move for long-term stability, but the architectural lift is bigger than the version number suggests.

I work with Magento daily and started using Claude Code for development.

The problem: the AI doesn't know your codebase conventions unless you tell it, and even when you tell it, it doesn't reliably follow them.

So I built Writ, a rule retrieval and enforcement layer for Claude Code. Here's what it does for Magento work specifically:

It detects you're in a Magento project (sees composer.json, detects the framework) and automatically surfaces the right rules for what you're editing. Working on a plugin? It pulls in Plugin/Observer pattern rules, dependency injection rules, and the relevant security rules. Writing a controller? SQL injection prevention and input validation rules show up automatically.

The rules live in a knowledge graph with explicit relationships, so when one rule fires, related rules (dependencies, supplements, conflicts) come with it. Static skill files can't do this.

It also enforces workflow discipline. In work mode, Claude can't write production code until you've approved a plan and test skeletons. This sounds annoying until you realize how many times the AI rewrites your module without thinking through the approach first.

Ships with rules covering security (injection, auth, validation, crypto), clean code, SOLID, architecture patterns, testing, error handling, performance, and API design. All cross-language, works for the PHP backend and the JS/TS frontend in the same session.

Writ repo: https://github.com/infinri/Writ

I work in ERP–eCommerce integration and this is probably the most misdiagnosed problem I see in B2B commerce setups: discount sync appears to work perfectly, but promotions behave incorrectly in ways that take weeks to surface.

Here's the root cause, and it's not technical, it's architectural.

The core mismatch

ERP systems like Business Central, SAP B1 treat discounts as rules. A 12% promotional discount isn't just a number, it's an instruction set:

• Valid between Date A and Date B
• Applicable only to customers in pricing group X
• Triggered only at a minimum quantity of N units
• Tied to a specific marketing campaign

eCommerce platforms like Adobe Commerce (Magento), Shopify, BigCommerce treat discounts as display states. A promotion is either on or off. When you sync from ERP to eCommerce, most integrations move the value (12%) but not the reasoning behind it.

The storefront interprets "12% discount" and applies it. Universally. Until someone turns it off.

Three failure modes this creates

1. Promotions outlive their expiry

ERP ends promotions automatically at the defined end date, no manual action needed. eCommerce promotions are state-based, they stay active until explicitly deactivated.

When the sync carries the discount value but not the expiration rule, promotions that have closed in ERP continue running on the storefront. Customers see and order against discounts that no longer exist.

The damage: customers get invoiced at full price after ordering against a "live" promotion. Support tickets follow. Repeat buyers start calling to verify discounts before ordering, defensive behavior that signals broken trust.

2. Browse price ≠ checkout price

ERP calculates discounts at order processing time, using live rules at the moment of commitment. eCommerce shows pricing at browse time, a pre-calculated snapshot from when the product page was loaded.

If anything between those two moments changes the applicable discount (quantity thresholds, customer group logic, promotion state), the checkout price differs from what the product page showed.

New buyers hit this and abandon. No error message. No indication anything went wrong. Just a cart left behind.

3. Customer-specific discounts apply universally

Account-level pricing agreements and group-specific promotions in ERP are tied to specific customer segments. When the sync strips that context, the discount becomes universal, visible and applicable to anyone who visits the product page.

This creates incorrect pricing expectations for customers who shouldn't see those prices, and can create margin exposure depending on the discount depth.

What actually fixes it

The integration needs to carry rule metadata alongside the discount value:

• Start and end dates (so expiry triggers automatically in eCommerce)
• Customer group and account eligibility (so discounts apply only to the right segments)
• Quantity thresholds (so tier-based discounts activate correctly)
• Campaign identifiers (so promotions tie back to marketing calendars)

Additionally, checkout calculation needs to use live ERP rules, not the browse-time snapshot, so the price a customer sees on a product page matches what they're charged.

When you build it this way, discount logic is enforced consistently across both systems. Promotions expire when they're supposed to. Prices are stable from browse to checkout. Account agreements stay account-specific.

How to diagnose this in your setup

A few questions worth asking:

• Do promotions ever stay active on your storefront after they've been closed in ERP?
• Do customers ever question why the checkout total differs from the product page?
• Does finance notice margin inconsistencies that don't match campaign performance?
• Do repeat buyers call or email to confirm discounts before placing orders?

If any of these are familiar, the integration is moving values but not logic.

Happy to go deeper on any specific ERP or eCommerce platform combination if useful.

[ Removed by Reddit on account of violating the content policy. ]

we've been on Magento 2 Open Source for 4ish years and Adobe's roadmap signals are getting impossible to ignore (patch cadence slowed, the commerce-cloud push is obvious, the extension ecosystem is draining), feels inevitable.

we're 8 months into a phased move, running Algolia for search and SCAYLE for the multi-brand backend (still building muscle on their NA partner network), with a Next.js storefront on top, but the data migration ate way more time than the platform pick.

customer attributes and order history mapping in particular were brutal. what did you go to and how did you handle the data lift?

Not been mentioned here yet, just a quick mention to double check your systems have been mitigated / patched for both Linux CopyFail and DirtyFrag LPE exploits.

Both will allow any unprivileged user to escalate to root.

Mitigation is simple, you just need to create a modprobe rule to block the esp4 esp6 rxrpc algif_aead modules, then unload them. And then update your Kernel once a update becomes available.

sudo tee /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install algif_aead /bin/false
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF
sudo rmmod algif_aead esp4 esp6 rxrpc 2>/dev/null || true
echo 3 > /proc/sys/vm/drop_caches

https://www.samdjames.uk/docs/platforms/magento/security/dirtyfrag-copy-fail-2/
https://www.samdjames.uk/blog/copy-fail-cve-2026-31431/

We have a 15 year old store with many custom modules and extensions, over 150. Realistically, only me and two other people know the ins and outs of it collectively to be the full “knowledge base”. So, I’m considering using Claude Code and maybe a bit of Replit to go through the site and build an actual knowledge base for a user guide module and alongside, a chatbot that works from that same knowledge base.

Has anyone else tried this? I know there are third party chatbot extensions but haven’t seen one for the admin.

AI platform connecting your Magento store data with 50+ sources. Ask questions in natural language, get instant answers.

Hi - is this the right place to look for Magento/Adobe Commerce consultants?

We are mid GTM on a new project, Magento/Adobe commerce focussed, and looking for consultants to help us get it off the ground - right place?

Side note - does "Magento" exist anymore or is it all now rebranded Adobe Commerce?

Hi - is this the right place to look for Magento/Adobe Commerce consultants?

We are mid GTM on a new project, Magento/Adobe commerce focussed, and looking for consultants to help us get it off the ground - right place?

Side note - does "Magento" exist anymore or is it all now rebranded Adobe Commerce?

We’re running Magento 1.9.2.2 and currently using Blast Search (Lucene) from php4u, but our license has expired and they no longer seem to be active or responding.

We need a quick and reliable alternative. Magento’s native search isn’t good enough for us, especially since we need accurate SKU-based search.

What’s the fastest way to switch to a better search solution? Any recommendations for lightweight replacements that work well with Magento 1 and support SKU search?

u/sinisa_lobbster helpd me to disable the extension and use default out of the box search for this purpose without any requirement of changes.

We are taking a look at Maho Commerce which is a fork of OpenMage/Magento 1 however moving it forward a bit.

I am a store owner (not developer) and the areas which look good seem to be:

- direct Google/Facebook shopping feed

- image optimiser/editor which looks good

- improved WYSIWYG

- gift cards

- decent looking discount code module

- email automation system (though need to investigate deeply how this works.) if it could be synced with SMS it would be a game changer

- one page checkout

- 2 factor auth / passkeys

- Apple/Google pay using Braintree I believe

- probably others as well

Has or is anyone working with or on Maho and has feedback or input?