Catalog Completeness runs on Mage-OS 4.0

Yes: Catalog Completeness, our free Magento Open Source module, passes our full install-to-uninstall bench on Mage-OS, one release from every minor line, 1.0.6 to 4.0.0. On Mage-OS 4.0.0, the shipped 1.0.0 passed with no change. Lines 1.1 to 2.2 needed one uninstall fix for a Mage-OS defect; it ships in Catalog Completeness 1.0.1. We tested lines 1.1 to 1.3 on PHP 8.3, because Mage-OS's own code there doesn't compile on PHP 8.4.

Mage-OS calls itself "100% compatible with existing Magento extensions" (Mage-OS). Its 4.0.0 notes hedge that "extensions that read compiled configuration directly may need attention" (Mage-OS). A compatibility claim isn't a test result, so we ran our Magento bench on 17 Mage-OS stores and published the table.

What we tested on Mage-OS, and how#

By November 2, 2026, Mage-OS had shipped 26 releases in 16 minor lines, the last of them 4.0.0, released on October 30, 2026 (Mage-OS) and tagged the same day (GitHub). We benched one release per line, the highest patch each line had on the bench date: 1.0.6, 1.1.1, 1.2.0, 1.3.1, 2.0.0, 2.1.0, 2.2.2, 2.3.0, 3.0.0, 3.1.0, 3.2.0, 3.3.0, 3.4.0, 3.5.0, 3.6.0 and 4.0.0. Mage-OS 4.0.0 ran twice, on PHP 8.4 and on PHP 8.5: 17 benches in all.

The other 10 releases are earlier patches on those lines, each followed by a later patch on the same or a later Magento base, and we don't list them as tested. One deserves a warning: Mage-OS 1.0.2's packages replace no magento/* package, so Composer can't install a module that requires one there, ours included. Mage-OS shipped 1.0.3 on the same base five days later.

Each bench, in order:

1. A fresh Mage-OS store: the distribution's own mage-os/project-community-edition at that release, from Mage-OS's Composer repository. Its CLI says so: on 4.0.0, bin/magento --version prints "Mage-OS CLI 4.0.0 (based on Magento 2.4.9)".
2. The install: composer require bigcartenergy/module-catalog-completeness, a checksum check that the installed code is the code under test, then setup and compile.
3. 16 phases, both indexer modes and the module's 104 unit tests. A phase is one scripted stage of the bench with a pass-or-fail verdict, judged by the same checker as our Magento benches.
4. Out and back in: module:uninstall with --remove-data, a check that every leftover count is zero and that a product still saves, then a clean re-install.
5. The fixtures: the 16 phases again, on our fixture data.
6. The admin walk: 111 checks covering the menu, User Roles, the settings and Periodic rescore, the cron rescore run from Magento cron, the No rules assigned view and work list, the filters, the exports, the REST states and six headless-Chrome screens.
7. Magento's own logs: no exception.log, no error report, no ERROR or CRITICAL line and no PHP deprecation.

PHP, MySQL and OpenSearch followed Mage-OS's own system requirements, with two exceptions. 1.1.1, 1.2.0 and 1.3.1 ran PHP 8.3, for a reason covered below. 1.0.6 ran MySQL 8.0 and OpenSearch 2.12, both on Adobe's list for Magento 2.4.7, instead of the Elasticsearch 8.11 Mage-OS lists; the module touches no search code. Composer was 2.8 throughout, as on our Magento benches. Mage-OS certifies 2.10.2 from 3.2.0, but the CLI's version doesn't reach the module's runtime.

What the bench doesn't cover: each store held our two packages and no other extension, so the table speaks for this module, not for the rest of your stack.

Results by Mage-OS release#

At Catalog Completeness 1.0.1, all 17 benches pass every check, and so do our Magento Open Source 2.4.9 and 2.3.7-p4 regression runs on the same code. At 1.0.0, 11 of 17 passed. All 17 cleared the 16 phases; six failed other checks on two Mage-OS defects, covered in the next section.

The scores matched Magento's exactly on every line: 100, 44, 33 and 89 for the four seeded products. Mage-OS follows its upstream on indexer mode: 1.1.0 and later start the completeness indexer in Update by Schedule, 1.0.x in Update on Save.

From 1.1.0, Mage-OS opens the admin in its own theme, a child of Magento's. Our admin walk ran in it on every line that ships it, and on 4.0.0 the module's admin styles compile into that theme's stylesheet with the same rule counts as on Magento 2.4.9. We also walked the 4.0.0 admin in a browser: the dashboard, the rule set editor for attribute sets and for channel profiles, and the product page panel render and work in Mage-OS's theme, with the admin footer reading "Mage-OS ver. 4.0.0" and no console errors.

Every Magento Open Source base below matches the one on Mage-OS's system requirements page.

What changed for Mage-OS: one fix, in 1.0.1#

Two Mage-OS defects stopped those six benches. Neither lives in our code, but one still needed our code to change.

Mage-OS 1.1.0 to 2.2.2 keep plugin lists where cleanup can't reach. These releases bundle a compiled-interceptor package that caches each area's plugin list in generated/staticcache. Magento's own cleanup, in module:uninstall and setup:upgrade, empties generated/code and generated/metadata, never that folder. Remove a module that has plugins, and the cached lists still name classes that are gone. On 2.0.0, a REST product save then returned HTTP 500 (Class "Magento\Catalog\Model\ProductRepository\Interceptor" does not exist), bin/magento could no longer build its command list, and setup:di:compile failed, so a production deploy would too.

It isn't our module: a throwaway module with one no-op plugin breaks the same store the same way. Deleting generated/staticcache repairs it at once. From 2.3.0, Mage-OS bundles the package's fixed release, which keeps the cache in generated/metadata/staticcache, where Magento's cleanup empties it.

The fix, in 1.0.1. After removing its data, the module's uninstall routine deletes the cached lists in generated/staticcache that name its plugins, and the package rebuilds them from the modules that remain. It checks for the folder first, so nothing happens where it doesn't exist: Magento Open Source, Mage-OS 1.0.x, and Mage-OS 2.3.0 and later. A failure there is logged as a warning, and the uninstall carries on unless that warning can't be written. Our Composer constraints didn't change.

That covers module:uninstall BigCartEnergy_CatalogCompleteness --remove-data, and the same command without the flag unless you answer no when it asks whether to remove the data. Any other way out on 1.1.0 to 2.2.2 runs none of our code: module:disable then composer remove, or module:uninstall with that question answered no. Delete the folder yourself, from the Magento root, once the code is gone and before setup:upgrade, setup:di:compile or the next request:

rm -rf generated/staticcache

Mage-OS 1.1 to 1.3 don't compile on PHP 8.4. In these lines, setup:di:compile stops on PHP 8.4 inside Mage-OS's own code: the CanViewNotification constructor marks a parameter nullable implicitly, which PHP 8.4 deprecates. It happens with or without any extension, and Mage-OS fixed it in 2.0.0 (GitHub). So we tested 1.1.1, 1.2.0 and 1.3.1 on PHP 8.3, which their metapackage allows.

4.0.0's upgrade notes, checked. The compiled DI change concerns extensions that read compiled configuration; Catalog Completeness reads none, and we benched 4.0.0 on PHP 8.4 and 8.5, where Mage-OS's object manager can hand out lazy-loaded objects. The inventory changes (order placement, shipment source, reservations) leave cataloginventory_stock_item, the one stock table the module reads, unchanged.

Installing Catalog Completeness on Mage-OS#

Same package, same command as on Magento Open Source. Run it from the Magento root of a staging copy first:

composer require bigcartenergy/module-catalog-completeness

It installs unchanged because Mage-OS's packages replace their magento/* twins at the upstream version: mage-os/framework 4.0.0 replaces magento/framework 103.0.9, for one. Composer brings in bigcartenergy/module-core with it, also unchanged. The package is on Packagist. From there, enable, upgrade and compile as the tool page's install steps say; the user manual covers every screen after that.

Two Mage-OS checks once it's in. bin/magento --version names your Mage-OS release and its Magento base, which is the pair to match against the table. And bin/magento indexer:show-mode bce_completeness_score shows which mode the indexer started in; set the one you want, as on Magento.

Composer resolves our requirements on every Mage-OS release except 1.0.2, but resolving isn't passing. Only the 16 releases in the table are tested, and the tool page's tested list is the one we keep up to date.

What Mage-OS merchants should know#

Feeds and scores are two jobs. Mage-OS 4.0 sends product feeds to "Google Shopping, Google Local Inventory, Google Promotions, Meta, Pinterest, TikTok and Microsoft Merchant Center" (Mage-OS). Its notes cover channels, delivery and opt-out, not completeness checks on the data that goes out. Catalog Completeness does that other job: it scores whether each product's data is complete for a channel, and it never sends anything. Five of its channel hints match those destinations: Google Merchant Center, Microsoft Merchant Center, Meta, Pinterest and TikTok Shop. We haven't tested the two together, so read this as two jobs side by side, not an integration. Weighing something bigger? Start with whether you need a PIM at all.

Patches go to one branch. Mage-OS "provides security patches and updates for the latest release branch only" (Mage-OS), and 3.6.0 reached end of life with 4.0.0 (Mage-OS). The 3.x rows above record what ran on November 2, 2026; they aren't a reason to stay on 3.x. Our Magento end-of-life guide covers what that policy means for older stores.

Removing any module on 1.1.0 to 2.2.2. The plugin-cache problem above follows any module with plugins out the door, not only ours. Until a store is on 2.3.0 or later, keep rm -rf generated/staticcache in its removal runbook.

Test the rest of your stack. The table covers one module, on stores with no other extension installed. Mage-OS's own migration guide says to "Review third-party extension documentation" and "Perform migration on staging and thoroughly test". Every other extension on a store needs its own run before a move to Mage-OS. Here's how we run an upgrade without breaking extensions.

Adobe Commerce is still out. Catalog Completeness is built for Magento Open Source, which keys product data by entity_id; Adobe Commerce keys its versioned product data by row_id. Mage-OS is a distribution of Magento Open Source, which is why it's in scope.

Have it set up on your Mage-OS store#

The module is free, every feature included, on Mage-OS as on Magento. Mage-OS's FAQ is clear that "The Mage-OS Association does not provide implementation services directly" (Mage-OS), so setup falls to your team or an agency's.

If it's ours: we install it on your staging copy first, write the rule sets for your attribute sets and a channel profile for each channel you feed, set the rescore schedule around your ERP or supplier syncs, and turn the first scored run into a cleanup plan for your catalog team. It's scoped in writing, and we don't publish prices. Send your Mage-OS version, a rough SKU count and the channels you feed through the setup form.

Catalog Completeness on Mage-OS FAQ

Sources