Quality and review

Two checks, two timings

Two independent gates apply to your packages:

• Package review - a one-time look at the package itself when you first add it: the repository, the name, the pricing model. Some marketplaces run this as an explicit per-package step; others activate packages on creation and rely on the vendor-application review instead. Your operator can tell you which mode this marketplace uses.
• Release checks - automated checks run on every release tag you push. There is no manual review per release.

Where the per-package review applies, release tags you push during that time still go through the automated checks, so when the review completes the package is ready for buyers.

Package review

When you add a package on My packages, a marketplace running with per-package review enabled looks at things like:

• That the composer name matches the name field in your composer.json on a recent tag.
• That the package type is one of magento2-module, magento2-theme, metapackage, or library.
• That the repository is real and accessible, and that the README and CHANGELOG read coherently.
• That at least one tag exists with a parseable composer.json.
• That there is no obvious name conflict or trademark issue against the chosen composer namespace.
• That your pricing model is consistent with the licence declared in composer.json (for example, you cannot sell a GPL-only module without a clear commercial-use grant).

Most reviews clear within a few business days. You receive an email when the review completes, and the package becomes available to buyers. On marketplaces that activate packages on creation, this step does not apply: the same expectations are still on you, but they are enforced after the fact through suspensions and takedowns rather than up front.

Release checks

Every release tag you push runs through an automated pipeline. Results appear on the release's page in your dashboard, grouped into four areas and run in this order.

Compatibility

Each supported Magento release line is installed on its supported PHP versions, then your module is built (dependency-injection compilation and static-content deploy) and its unit and integration suites are run. The matrix shows the Magento lines and PHP versions your module is confirmed to install and run on. The code-quality results below are reported separately and never affect compatibility.

Code quality

Advisory checks against your module's source. They surface issues for you to act on and never change the compatibility result: a coding-standard finding cannot make a module incompatible.

Static analysis

Coding standards (phpcs), mess detection (phpmd), copy-pasted code (cpd), PHP cross-version compatibility, and composer.json validity. Each runs once across the whole module.

PHPStan

Type-checks your module's PHP against a real Magento install at the configured gate level. It re-runs per Magento and PHP version, because the symbols it can resolve differ between releases.

Tests

Your unit and integration suites, run for each applicable Magento and PHP version. A test failure speaks to your module's behaviour, not its compatibility with a Magento line, so it is reported here separately and never reddens the compatibility matrix.

Security

Security checks run directly against your module. Each runs once.

Dependency audit

composer audit against the published advisories list. Surfaces vulnerable dependencies in your release lockfile with their severity, CVE and fix line.

Malware scan

Scans your source for malware and web-shell signatures. A detection fails the version outright.

Each check reports passed, failed, or pending. Whether a failed code-quality, test, or audit result hides the release from buyers depends on your operator's policy: some marketplaces serve every release and treat the results as a quality signal vendors act on; others hide releases until everything passes. A malware detection is the exception, it fails the version outright regardless of policy. Either way, the per-rule detail stays on the release page so you can see exactly what to fix and where.

Where you see results

• Activity feed: a row lands as soon as the checks finish, with the pass or fail outcome. See Activity feed.
• Release page: the Quality tab shows per-tool status, error and warning counts, and the per-rule breakdown for any failures.
• Email: a one-line summary for each release, linking to the release page.

Fix and re-tag

There is no retry button. To ship a fix, push a new semver tag with the corrected code. The new tag runs through the checks afresh. Leave the failed tag in place: the release page keeps an audit record of it, and the per-rule detail stays available. What buyers see for a failed release depends on your operator's policy (see Release checks above); a malware detection always fails the version outright.

Reporting a vulnerability

If you find a vulnerability in your own package, another vendor's package, or Packagento itself, report it privately through our contact form. Do not open a public issue or post exploit details. Packagento credits good-faith reports and coordinates patches with affected vendors before publishing advisories.

When you patch a security issue, tag the fix and add a brief, non-exploit-disclosing entry to your CHANGELOG. Buyers see the entry on the release page so they can decide whether to expedite the upgrade.

Troubleshooting

• Package stuck in review for more than a week: Get in touch through our contact form. Most reviews complete within a few business days; a longer delay usually means we have a question we could not reach you with.
• A release is hidden after a check failed: your operator is running the marketplace with check-failed releases hidden from buyers. Ship a corrected release; the new tag runs through the checks afresh.
• Static analysis disagrees with my local run: Packagento runs analysis with the official Magento type stubs. Local installs without those stubs often underreport. Run with the same stubs locally to reproduce.
• Dependency audit failing on a transitive dependency: bump the affected package in your composer.json require block and re-tag.