Ecommerce Marketplace Publishing

E-Commerce Marketplace Publishing Guide

Overview

Publishing an e-commerce plugin to a platform marketplace transforms a private project into a distributed product. Each marketplace has its own submission process, review criteria, and ongoing maintenance requirements. This guide covers the publishing lifecycle from pre-submission preparation through review approval and post-launch maintenance, with platform-specific details in the reference files.

The publishing lifecycle follows a consistent pattern across platforms:

1. Develop -- Build the plugin following platform coding standards.
2. Prepare -- Audit code quality, security, documentation, and listing assets.
3. Submit -- Upload the package and listing to the marketplace review queue.
4. Review -- The platform team reviews code, functionality, and security.
5. Revise -- Address reviewer feedback and resubmit.
6. Publish -- The plugin goes live on the marketplace.
7. Maintain -- Release updates, respond to reviews, and maintain compatibility.

Pre-Submission Checklist

Before submitting to any marketplace, complete these checks. Skipping these steps is the primary cause of submission rejections.

Code Quality

• Run the platform's official code sniffer or linter (PHPCS with WordPress coding standards, Magento Coding Standard, PrestaShop Validator).
• Eliminate all errors and warnings from the linter output.
• Remove dead code, commented-out blocks, and debug statements (var_dump, console.log, error_log).
• Ensure all functions and classes are properly namespaced to avoid conflicts with other plugins.
• Prefix all global functions, constants, and database table names with the plugin slug.
• Verify no hardcoded credentials, API keys, or environment-specific paths exist in the codebase.

Security Audit

• Verify all user inputs are sanitized and validated before use.
• Confirm all database queries use parameterized statements or prepared queries.
• Check that CSRF tokens are present and validated on all state-changing forms and endpoints.
• Ensure all output is properly escaped for the rendering context (HTML, JavaScript, URL, CSS).
• Verify file uploads validate type, size, and content.
• Confirm sensitive data (API keys, tokens) is stored encrypted or in environment variables.
• Run a static analysis tool (PHPStan, Psalm, SonarQube) and resolve all critical findings.

Documentation

• Write a complete README with installation instructions, configuration steps, and usage guide.
• Document all hooks, filters, events, and extension points the plugin provides.
• Include screenshots of the admin UI and customer-facing features.
• Provide a changelog covering all versions.
• Add inline code documentation (PHPDoc, JSDoc) for public methods and classes.
• Create a FAQ section addressing common setup issues.

Listing Assets

• Prepare a plugin icon (square format, typically 128x128 and 256x256 pixels).
• Create banner images (marketplace-specific dimensions; WordPress: 772x250 and 1544x500).
• Write a compelling short description (under 150 characters) and long description.
• Prepare up to 5-10 screenshots with captions showing key features.
• Record a demo video if the marketplace supports it (Shopify App Store strongly recommends video).

For detailed per-platform checklists, see references/submission-checklists.md.

Platform Marketplace Comparison

Key differences:

• WordPress.org is the only major marketplace that requires plugins to be GPL-licensed and free.
• Shopify requires OAuth-based authentication for all apps and enforces strict rate limits.
• Magento Marketplace has the most rigorous technical review, including automated code scanning (MFTF tests, EQP quality checks).
• PrestaShop Addons requires module validation through their online validator tool before submission.
• BigCommerce requires a partnership application before app submission.

Versioning Strategy

Semantic Versioning (SemVer)

Follow Semantic Versioning 2.0.0 for all plugin releases:

MAJOR.MINOR.PATCH

MAJOR -- Incompatible API changes, breaking changes to database schema, dropped platform version support.
MINOR -- New features added in a backward-compatible manner.
PATCH -- Backward-compatible bug fixes, security patches, translation updates.

Examples:

• 1.0.0 -- Initial release.
• 1.1.0 -- Added new payment method support (new feature, backward-compatible).
• 1.1.1 -- Fixed checkout validation bug (bug fix).
• 2.0.0 -- Dropped support for PHP 7.x, changed settings storage format (breaking change).

Pre-Release Versions

Use pre-release suffixes for testing:

• 2.0.0-alpha.1 -- Early testing, unstable, feature-incomplete.
• 2.0.0-beta.1 -- Feature-complete, may have bugs.
• 2.0.0-rc.1 -- Release candidate, final testing before stable release.

Backward Compatibility

Before releasing a major version with breaking changes:

• Document all breaking changes in the changelog and migration guide.
• Provide a migration path (automatic database migration, settings converter, deprecation warnings in the previous minor version).
• Maintain the previous major version with security patches for at least 6 months after the new major release.
• Announce the end-of-life date for the previous version in advance.

For complete versioning and changelog practices, see references/versioning-and-changelog.md.

Changelog and Release Notes

Changelog Format

Follow the Keep a Changelog format (keepachangelog.com):

## [1.2.0] - 2026-04-25

### Added
- Multi-currency support for EUR, GBP, and JPY.
- Webhook retry dashboard in admin panel.

### Changed
- Improved checkout validation error messages.
- Updated Stripe SDK to v15.0.

### Fixed
- Cart total calculation rounding error with tax-inclusive pricing.
- Shipping rate cache not invalidating on address change.

### Security
- Patched XSS vulnerability in order notes display.

### Deprecated
- Legacy API endpoint `/api/v1/orders`. Use `/api/v2/orders` instead. Will be removed in 2.0.0.

Release Notes Best Practices

• Write release notes for the audience: merchants and store administrators, not developers.
• Lead with the most impactful change (new feature or critical bug fix).
• Highlight security fixes prominently -- merchants need to know when to update urgently.
• Include upgrade instructions if the update requires any manual steps.
• Link to documentation for new features.
• Keep entries concise -- one line per change, with optional detail in a linked document.

Common Rejection Reasons

Understanding why marketplaces reject plugins prevents wasted review cycles. These are the most frequent rejection reasons across all platforms:

1. Security Vulnerabilities

• Unsanitized input -- User input rendered without escaping. Fix: use platform escaping functions on all output.
• Direct database queries without preparation -- SQL concatenation instead of parameterized queries. Fix: use prepared statements or the platform's query builder.
• Missing CSRF protection -- Forms submit without nonce/token validation. Fix: add CSRF tokens to all forms.
• Exposed sensitive data -- API keys in JavaScript, debug information in production. Fix: move credentials server-side, disable debug mode.

2. Coding Standards Violations

• Wrong coding style -- Tabs vs. spaces, brace placement, naming conventions. Fix: run the platform's coding standards checker and fix all violations.
• Missing text domain -- Strings not wrapped in translation functions. Fix: wrap all user-facing strings in __(), _e() (WordPress), or the platform's i18n function.
• Incorrect file structure -- Files not in the expected directory layout. Fix: follow the platform's documented file structure.

3. Functionality Issues

• Plugin causes errors on activation -- Fatal errors, PHP notices, JavaScript errors. Fix: test on a clean installation of the supported platform versions.
• Conflicts with other plugins -- Using generic function names, enqueueing scripts globally. Fix: namespace everything, enqueue scripts only on plugin pages.
• Missing uninstall cleanup -- Plugin leaves database tables, options, and files after uninstallation. Fix: implement a clean uninstall routine that removes all plugin data.

4. Listing Quality

• Misleading description -- Description claims features not present in the plugin. Fix: accurately describe current functionality.
• Low-quality screenshots -- Blurry, cropped, or missing screenshots. Fix: capture clean screenshots at the required resolution.
• Missing privacy policy -- Plugin collects data but does not disclose it. Fix: add a privacy policy section describing what data is collected, stored, and transmitted.

5. Performance Issues

• Excessive database queries -- Running queries on every page load. Fix: cache results, use lazy loading, query only when needed.
• Large asset files -- Unminified CSS/JS, uncompressed images. Fix: minify and compress all assets.
• No caching -- Recalculating expensive operations on every request. Fix: implement transient/object caching.

6. Compatibility

• Hardcoded paths or URLs -- Plugin breaks on non-standard installations. Fix: use platform functions for paths and URLs.
• PHP version incompatibility -- Using syntax not available in the minimum required PHP version. Fix: test on the minimum supported PHP version.
• Missing dependency checks -- Plugin assumes another plugin or extension is installed without checking. Fix: verify dependencies on activation and display a clear error if missing.

Licensing Considerations

Plugin licensing requirements vary by marketplace. WordPress.org requires GPL-compatible licenses. Other marketplaces allow proprietary licenses. Dual licensing (open-source core with proprietary add-ons) is a common monetization strategy.

For detailed licensing guidance per platform, see references/licensing-guide.md.

Reference Files

• Submission Checklists -- Per-platform submission checklists for WordPress.org, Shopify App Store, Magento Marketplace, PrestaShop Addons, BigCommerce, and OpenCart
• Versioning and Changelog -- SemVer practices, changelog format, migration guides, deprecation policy
• Licensing Guide -- GPL, MIT, proprietary licenses, dual licensing, per-platform requirements