Page 39 - Magento

Magento consumers run asynchronously against RabbitMQ, yet the actual processing logic behind them can be tested fully synchronously without a running broker once the consumer class and the domain logic are cleanly separated.

Snapshot tests sound tempting: run once, save the result, done. In practice, though, they quickly turn into a maintenance burden if you do not exactly understand which scenarios they fit and how much discipline the team needs to apply.

Legacy shops built on Magento 1 or an early Magento 2 base often still run on Solr as their search technology, even though Solr has not been supported since Magento 2.4. The search migration from Solr to Elasticsearch or OpenSearch touches schema, reindex process, and storefront behavior alike. This article delivers a complete checklist, a schema mapping, and a rollback plan for a low-risk switch.

When Redis causes trouble in a Magento environment, only a handful of error patterns are really common: refused connections, OOM errors on writes, and session lock timeouts during checkout. This article walks through each of these error patterns systematically, showing the diagnostic steps and the concrete fix.

Anyone who changes a GraphQL schema without knowing the existing clients risks silent breakage in the frontend. Additive evolution, structured deprecations, and automated schema diffs with GraphQL Inspector make schema changes predictable instead of random.

env.php does not belong in the repository, and it does not belong in the build artifact. Ignore that rule and you end up with a release model that breaks at the first environment switch. This article explains how app/etc, shared directories, and config.php correctly work together in the symlink release model with GitLab CI/CD.

A product attribute in Magento 2 is quick to create. It only becomes truly valuable once admin maintenance, EAV setup, frontend output and a clean widget in the theme all fit together. That is exactly what this tutorial is about.

Automatically generated factories for new objects, proxies for lazy loading of expensive services: both patterns explained together with concrete use cases and PHP 8.4.

After every deployment and after every manual cache flush, a Magento store starts out with a completely empty full page cache, and it is exactly at that moment that the first real visitors hit a server that has to render every page fresh from PHP and the database. For a store with meaningful traffic, this creates a classic thundering herd problem, where many parallel requests hit the same uncached resource at once and put unnecessary load on the server. This article shows how critical pages like the homepage, top categories, and bestsellers can be systematically pre-heated by script before real visitors are affected, and where the difference between reactive and proactive cache warmup lies.