When a marketplace says a product is “reviewed,” buyers deserve to know exactly what that means. Who performed the review? What did they check? Which release did they inspect? Was the product tested by a person or merely passed through a scanner? What happens when the seller uploads an update? And if a customer discovers a problem, where should it be reported?
This page is WPBay’s clear answer.
Every new WordPress plugin, WordPress theme or standalone script submitted to WPBay is reviewed before it is first made available for sale. A typical review combines automated analysis, manual inspection and practical testing. Its depth is proportionate to the product’s functionality and risk. Approval applies to the specific version recorded as reviewed; it is not a permanent security guarantee, a penetration test or a promise that no defect will ever be discovered.
The short version: WPBay’s human reviewers inspect the submitted package, use appropriate automated tools as supporting evidence, test important buyer workflows, compare the product with its listing and documentation, and assess technical quality, security-sensitive behavior, usability, compatibility, packaging, licensing and buyer value. Products with unresolved blockers are not approved. The reviewed version, review date and reviewer should be shown beside the review claim on each product page.
Who reviews products submitted to WPBay?
WPBay reviews are performed by real software developers, not decided by an automated score.
I am Szabolcs-Istvan Kisded—usually Szabi—a WPBay co-founder and the developer behind CodeRevolution. I lead and perform reviews across WPBay’s product categories. I have spent more than a decade building commercial WordPress software. Through CodeRevolution, I have released more than 140 commercial plugins, served roughly 13,000 buyers, maintained a customer rating around 4.9/5 and generated more than $500,000 in marketplace sales.
Those figures are not included as decoration. They explain the perspective I bring to a review. I have handled difficult updates, API failures, WordPress compatibility changes, database migrations, security reports, refund requests and thousands of real support conversations. I know how a small packaging mistake becomes an activation failure, how a missing permission check becomes a vulnerability, and how a feature that worked perfectly on a development site can fail immediately on a clean customer installation.
Stefan, WPBay co-founder, founder of King’s Plugins and creator of B2BKing, also reviews products across categories. His WooCommerce, B2B ecommerce and commercial plugin experience is particularly valuable when a submission handles pricing, roles, orders, payments or complex store workflows.
You can meet both reviewers on the WPBay team page. Automated checks assist us, but a scanner does not approve or reject a product. A human reviewer interprets the findings, examines the surrounding implementation and makes the final decision.
Does WPBay apply the same rules to founder-owned and third-party products?
Yes. The same published requirements apply whether the seller is new to WPBay, an established third-party developer, CodeRevolution, King’s Plugins or another business connected to a WPBay team member.
A product does not receive a different technical standard because its seller helped build the marketplace. Founder-owned products can be returned for changes, corrected, reported by customers or temporarily disabled under the same rules as third-party products. The same reviewed-version disclosure, maintenance-data separation and post-publication reporting process must be used for all products.
This matters because WPBay’s founders are also working developers and sellers. We consider that practical experience an advantage, but not an exemption. Trust is earned by applying the standard consistently and describing it accurately.
What does “reviewed by WPBay” mean?
It means that WPBay completed a proportionate review of a named product release and did not identify an unresolved approval blocker in that reviewed version.
The review may include automated scans, source inspection, installation in a clean environment, configuration, testing of important advertised features, examination of failure paths, review of documentation and comparison of the package with the product page. The exact work depends on what the software does.
A small plugin that changes one display option does not need the same depth of review as a payment extension that writes orders, accepts webhooks and affects customer totals. A JavaScript presentation component is not treated like a Laravel application with authentication, uploads and billing. A theme is evaluated as both software and a visual product.
Risk determines where attention is concentrated. Products that handle privileged actions, customer data, uploads, downloads, remote requests, payments, authentication, public endpoints, scheduled jobs or destructive database operations receive more scrutiny in those areas.
What approval does not mean
WPBay approval is not a security certification. It does not mean that every line of every dependency was audited, that formal penetration testing was performed, that the product was tested in every possible hosting environment, or that no bug or vulnerability can ever exist.
No responsible software marketplace can guarantee that. Software changes. WordPress, PHP, browsers, operating systems and third-party APIs change. Dependencies publish new releases. A safe code path can become exposed by a later modification. Some defects appear only under unusual combinations of data, permissions, traffic or server configuration.
Approval also does not transfer responsibility from the seller to WPBay. The seller remains responsible for the product’s code, bundled components, data handling, legal compliance, maintenance, support promises and security response.
Our claim is deliberately narrower and more useful: a human reviewer examined the identified release using a risk-based marketplace process, and no unresolved approval blocker was identified before approval.
Which product version was reviewed?
A review applies to the exact release package submitted and recorded during the review. It should never be interpreted as a timeless approval of every past and future version carrying the same product name.
Each reviewed product page should display the following information beside the WPBay review claim:
- the version that received the review;
- the date that review was completed;
- the human reviewer;
- whether it was an initial review, full update review or targeted update review; and
- a link to this explanation.
The product’s current version is separate information. When the current download is newer than the last fully reviewed release, the product page should say so plainly. WPBay may review updates, particularly when they materially change security-sensitive functionality, dependencies, compatibility, licensing behavior, installation, payments, data handling or major buyer-facing features. A minor update may not receive the same complete review as the initial release.
This version distinction gives customers useful facts without creating a misleading guarantee. It also lets WPBay identify precisely which package was examined if a later report needs investigation.
How the WPBay product review process works
1. We receive the final customer package
The review begins with the archive or release a buyer is meant to receive—not an idealized development copy. A WordPress plugin or theme should normally be directly installable through the WordPress dashboard. A standalone script should include what is needed to reproduce its documented setup from a clean supported environment.
We examine whether required runtime files, documentation and license information are present. We also look for material that should never have been shipped: development credentials, private keys, production API tokens, customer information, database dumps, debug logs, backup copies, editor files, obsolete builds, unrelated source archives or commercial assets the seller cannot redistribute.
2. We establish the release identity
Version information needs to agree. Depending on the product, we compare the version in the WPBay listing, plugin or theme headers, readme, changelog, internal constants, schema version, package name and updater metadata.
This is not administrative fuss. Inconsistent versions can break automatic updates, prevent a database migration, make a customer install the wrong release or make a security report impossible to scope accurately.
3. We use automated checks as evidence
Depending on the product type, WPBay may use tools such as WordPress Plugin Check, Theme Check, coding-standard checks, static analysis, malware scanning, dependency analysis and secret detection. For another platform or language, we may use tools appropriate to its ecosystem.
These tools help us locate code worth inspecting. They do not make the decision.
A scanner can report a false positive. It can also miss a serious business-logic flaw: for example, a perfectly valid database query exposed to the wrong user role. A harmless style warning does not carry the same weight as missing authorization, a broken migration or an exposed credential. Conversely, a clean scan is not proof that the product is secure.
4. We inspect security-sensitive behavior
Review depth follows risk. We focus on boundaries where untrusted input, permissions, sensitive data or external systems meet the product.
Common review areas include authentication, account recovery, roles and capabilities, nonces and CSRF protection, AJAX actions, REST endpoints, forms, validation, sanitization, output escaping, SQL queries, database writes, uploads, downloads, archive extraction, imports, exports, file paths, remote requests, webhooks, custom tokens, payment operations, secrets, logging, scheduled jobs, queues and background processing.
We pay particular attention to the difference between interface restrictions and server-side authorization. Hiding a button from a subscriber does not protect the AJAX action behind it. Giving an endpoint an obscure URL does not make it private. A nonce can help confirm request intent, but it does not prove that the current user has permission to perform an administrative action. The permission decision must be enforced where the action is processed.
We also distinguish validation, sanitization and escaping. Validation determines whether a value is acceptable. Sanitization converts untrusted data into an appropriate form. Escaping protects it when printed in a specific HTML, attribute, URL, JavaScript or other output context. One operation does not automatically replace the others.
5. We install or start the product from a clean environment
Where practical, we test without the seller’s accumulated development state. A clean installation exposes missing tables, absent default options, undeclared dependencies, stale assumptions and runtime packages that existed only on the seller’s machine.
For WordPress products, we may test installation, activation, initial setup, deactivation, reactivation and uninstall behavior. When an update includes a data or schema change, an upgrade from a previous release can matter as much as a clean install.
For scripts and standalone applications, the equivalent question is whether another person can reproduce the documented setup with the stated runtime, dependencies, environment variables, database and build commands.
6. We test important advertised functionality
We do not stop when a dashboard page renders. The reviewer follows meaningful buyer paths.
If a product says it exports data, the export should contain the expected information. If it says it automatically publishes content, the scheduled or background workflow should actually reach that outcome. If it creates pricing rules, those rules should affect the correct products and users. If an interface reports success, the underlying action should genuinely have succeeded.
Failure paths matter too. A missing dependency, expired API key, unavailable remote service, rejected webhook or database error should not be silently reported as success. Where reasonably possible, unrelated parts of a WordPress site or application should continue working instead of crashing.
7. We compare the product with its documentation and listing
The page customers read is part of the product review. Major claims may be checked against the submitted release. Screenshots and demos should represent the version being sold, not a future design or a different edition.
Required dependencies, commercial plugins, API accounts, paid subscriptions, usage fees, server extensions, geographical restrictions and important limitations must be disclosed before purchase. Compatibility claims must reflect actual testing rather than hope.
Documentation should let a buyer understand what the product does, install it, complete initial setup and use its main workflows. More complex products need more detail. If an API key, webhook, cron job, queue worker or database migration is required, the buyer should not need to reverse-engineer the source to discover it.
8. We examine ownership and licensing
The seller must own the product or hold the rights required to sell and distribute it. This applies to more than first-party source code. Fonts, icons, images, audio, video, templates, sample data, demo content, bundled plugins and libraries can have separate license terms.
A license that permits an image to appear on a demo website does not necessarily allow the original file to be placed inside thousands of customer downloads. Generated code and generated assets do not remove the seller’s responsibility to verify quality, originality and redistribution rights.
9. A human reviewer makes the decision
The normal decisions are Approved, Changes Required or Rejected. An approved product can also be temporarily disabled later if a serious problem is discovered.
A legitimate product with fixable problems normally receives Changes Required. The seller receives the important findings and can correct the underlying issues, test the new package and resubmit it. We do not expect a seller to weaken correct code merely to silence a scanner; a well-explained false positive can be evaluated in context.
What we check in WordPress plugins
A WordPress plugin runs inside another application and commonly shares the site with dozens of unrelated extensions. It can affect administration, public pages, scheduled tasks, customer data and database state. Review therefore covers more than whether the plugin activates.
Depending on the plugin’s features, our review may examine:
- installable ZIP structure and the presence of all required runtime files;
- stable folder, filename, text-domain, licensing and updater identity;
- plugin headers, version consistency and genuine WordPress, WooCommerce and PHP compatibility;
- clean installation, activation, setup, deactivation, reactivation, update and uninstall behavior;
- database table creation, migrations, rollback assumptions, preservation of customer data and behavior on partial failure;
- settings, forms, blocks, shortcodes, widgets, admin pages and the main workflows advertised on the product page;
- AJAX actions and REST routes, including authentication, nonces, capability checks and object-level authorization;
- validation, sanitization and correct context-specific escaping;
- SQL construction, prepared values, dynamic identifiers and database error handling;
- uploads, downloads, imports, exports, backups, archive extraction, file types and path traversal protection;
- remote HTTP requests, redirect behavior, response validation, timeouts, secrets and failure handling;
- cron hooks, Action Scheduler tasks, queues, locks, retries, idempotency and prevention of duplicated orders, emails, imports, records or charges;
- external APIs, webhooks, payment providers and third-party services;
- data collection, privacy-sensitive information, consent where applicable and disclosure when data leaves the site;
- scripts and styles, scope, avoidable loading, large assets, expensive queries and repeated remote requests;
- required and optional plugin dependencies, including graceful behavior when they are missing or disabled;
- prefixing or namespacing of functions, classes, constants, option names, cron hooks, REST namespaces and asset handles;
- WPBay licensing, activation and automatic-update integration when the seller uses it;
- localization, understandable labels, keyboard access and practical accessibility;
- documentation, changelog, support scope, screenshots, demo and product-page accuracy; and
- ownership and licensing of all included code and assets.
The full mandatory standard is published in the WPBay Technical Requirements for WordPress Plugins.
What we check in WordPress themes
Themes are reviewed as software and as visual products. Valid PHP is not enough if the mobile menu is unusable, the advertised design cannot be reproduced, a checkout overlaps at a common breakpoint or the demo importer depends on data left behind on the developer’s website.
Depending on the theme, our review may cover:
- installable package structure, required files, theme headers, text domain, version and license;
- classic-theme or block-theme architecture, template hierarchy, templates, parts, patterns, theme configuration and Site Editor behavior;
- activation, clean setup, required and recommended companion plugins and understandable dependency notices;
- Customizer, Site Editor, Global Styles and other configuration changes saving and reloading correctly;
- visual consistency, typography, spacing, buttons, forms, navigation and repeated interface components;
- responsive behavior across realistic desktop, tablet and mobile sizes;
- navigation, focus states, headings, form labels, contrast and practical keyboard accessibility;
- frontend PHP warnings, JavaScript errors, broken resources and avoidable console noise;
- child-theme compatibility and the ability to customize an intended parent theme safely;
- separation of presentation from durable content or functionality that users should retain after changing themes;
- page-builder compatibility when claimed, including required paid editions and bundled templates;
- WooCommerce catalog, cart, checkout, account and responsive behavior when WooCommerce support is claimed;
- one-click demo import from an empty WordPress installation, including missing remote files and failed requests;
- performance, asset loading, image sizes and avoidable frontend weight;
- accuracy of screenshots, demos, included layouts and advertised features; and
- redistribution rights for demo images, fonts, icon sets, bundled plugins, templates and other assets.
The detailed requirements are available in the WPBay Technical Requirements for WordPress Themes.
What we check in scripts and standalone applications
“Script” is a broad category. A Laravel application, Node.js service, JavaScript component, Python tool, command-line utility, Flutter project and React Native application cannot be reviewed against one artificial framework checklist. We apply the same marketplace principles to the technology, deployment model and risk of the actual product.
The central test is reproducibility: can another person set up and use the product from a clean supported environment by following the documentation?
Depending on the application, a script review may examine:
- package completeness, directory structure and whether the distributed release matches the listing;
- supported runtime, operating system, browser, framework, database and server requirements;
- dependency manifests, lock files, installation commands, build steps and production start commands;
- safe example configuration, required environment variables and absence of production secrets;
- database creation, seed data, migrations, upgrades, rollback expectations and preservation of existing data;
- authentication, session handling, password storage, account recovery, role checks and object-level authorization;
- CSRF, injection, cross-site scripting, unsafe deserialization, server-side request behavior, open redirects and information disclosure where relevant;
- file uploads, downloads, generated archives, storage permissions and path handling;
- public APIs, rate limits, webhooks, signature verification, replay resistance and sensitive tokens;
- payments, refunds, order state, duplicate callbacks and idempotent processing when money is involved;
- queues, scheduled processes, workers, retries, concurrency, locks and duplicate side effects;
- logging that helps diagnose failures without exposing passwords, tokens or personal information;
- third-party APIs, timeout and retry behavior, unavailable services and malformed responses;
- backup, recovery, update and deployment instructions appropriate to the product;
- readable first-party source and sufficient build information when production files are compiled or minified;
- mobile permissions, signing, build requirements and store dependencies for mobile projects where applicable;
- documentation, examples, support boundaries, limitations and the accuracy of demo claims; and
- ownership and license compliance for dependencies, templates and included media.
The complete standard is published in the WPBay Technical Requirements for Scripts.
Common reasons a product is returned for changes
Most Changes Required decisions do not involve malicious software. They involve repairable problems that could cause a poor or unsafe customer experience.
Examples include an AJAX action without an appropriate capability check; a nonce used as the only authorization rule; a REST endpoint that exposes private data; unsafe SQL construction; output that is not escaped for its context; an upload or download route that trusts a filename; activation that depends on a table created only on the seller’s development site; a migration that overwrites existing customer data; background jobs that create duplicates; an API failure displayed as success; a missing dependency that causes a fatal error; conflicting version numbers; a theme that breaks on mobile; a demo import that cannot run from a clean site; undisclosed recurring API costs; documentation that omits required setup; or an archive containing secrets, customer information or unlicensed assets.
A reviewer may report a specific example, but the seller is expected to fix the underlying pattern. Correcting only the named line while leaving identical problems elsewhere is not a complete response.
Approved, Changes Required, Rejected and Temporarily Disabled
Approved
No unresolved approval blocker was identified during the proportionate review of the recorded version. This is the status that allows a new product to be published.
Changes Required
One or more identifiable and repairable blockers were found. This is the normal outcome for security omissions, broken functionality, packaging errors, inaccurate compatibility, misleading claims, incomplete integrations or substantial documentation gaps. The seller can correct the product and resubmit the final package.
Rejected
The submission cannot responsibly be accepted. This decision is reserved for products that are malicious, deceptive, stolen, intentionally dangerous, deliberately concealed, fundamentally non-viable or affected by similarly serious problems. Repeated attempts to hide prohibited behavior can also affect the seller’s account.
Temporarily Disabled after approval
An existing listing may be temporarily disabled if WPBay later discovers a serious vulnerability, broken update, malicious dependency, legal problem or materially misleading claim. The seller is expected to investigate promptly and provide a tested correction.
How updates are handled after the first approval
Approval is the beginning of a product’s life on WPBay, not the end of the seller’s responsibility.
Sellers must maintain the compatibility they continue to advertise, fix significant defects, respond appropriately to security reports, keep an understandable changelog and handle updates without unnecessarily damaging existing customer data or workflows.
WPBay may review product updates, especially when a release changes privileged operations, authentication, public endpoints, payments, uploads, stored data, migrations, dependencies, license enforcement, automatic updates or important product claims. When an update receives a full or targeted re-review, the reviewed-version record should be updated accordingly.
When a newer release has not received a complete re-review, the product page should not imply that it has. This does not automatically make the release unsafe. It simply keeps the review claim accurate.
Maintenance data is not a security guarantee
Some WPBay product pages show a maintenance snapshot containing facts or signals such as the date of the latest update, recent seller activity, declared or tested WordPress compatibility, release history and support responsiveness.
That snapshot answers a different question from the product review.
A review is an assessment of a recorded release. A maintenance snapshot summarizes current marketplace data that may help a buyer judge whether a product appears actively maintained. A recently updated product is not automatically secure. An older product is not automatically vulnerable. Fast support does not prove code quality, and a quiet changelog does not prove abandonment.
For this reason, WPBay keeps maintenance signals separate from security and review claims. The maintenance snapshot should carry its own timestamp and methodology, while the review box should identify the reviewed version, date and reviewer. Neither should use language such as “100% secure,” “vulnerability-free” or “guaranteed safe.”
How customers can report a problem
Customer reports are part of responsible marketplace oversight. A reviewed product can still contain a defect, and we want reports to reach the right people quickly.
If you purchased the product and need normal technical support: sign in to WPBay, open My Downloads, find the product and use its available Get Support option. The product page explains whether support is provided through WPBay, the seller’s email address or the seller’s own support system.
If the product is broken, misleading, contains prohibited material or creates a marketplace-level concern: use the Report this product button on that product’s page. You may also use the WPBay contact form or email [email protected].
If you believe you found a security vulnerability: report it privately. Do not publish exploit details in a product comment or public review. Use the product report form and select the security-related report type where available, or email [email protected]. Include the product name, affected version, steps to reproduce, required account role or configuration, observed impact and any safe proof that helps us verify the problem. Do not include real customer data or attempt testing on a website you do not own or have permission to assess.
WPBay can investigate, notify the seller, request a correction, warn affected customers where appropriate or temporarily restrict a listing while a serious issue is handled. Sellers dealing with potentially serious or actively exploited vulnerabilities should also consult WPBay’s vulnerability and incident reporting guidance. Contacting WPBay does not replace any legal or regulatory reporting duty that applies to the seller.
For ordinary troubleshooting, see how to get support for a WPBay product that is not working correctly.
What information makes a report useful?
Please include the product name and version, purchase or order reference when applicable, WordPress/PHP/framework version, relevant dependencies, the steps that trigger the problem, the result you expected, the result you received and any exact error message or log excerpt. Screenshots can help with visual problems, while a short screen recording can make a multi-step workflow easier to reproduce.
Before sending logs, remove passwords, API keys, license keys, session cookies, access tokens, customer records and other sensitive information.
Why we publish the process
“Human reviewed” should be more than a badge. A buyer should be able to inspect the meaning behind the claim, and a seller should know the standard before spending time preparing a release.
Publishing the process also keeps us accountable. If our public wording says that new products are reviewed before publication, our Seller Guidelines must say the same thing. If a badge refers to a review, it should link here and identify the reviewed version. If a maintenance panel summarizes activity, it should not be presented as proof of security. If the marketplace founders sell products, those products must follow the same rules as everybody else’s.
For sellers preparing a submission, the practical next step is the WPBay Seller Guidelines and Product Review Process, followed by the detailed technical requirements for the relevant product type.
Frequently asked questions about WPBay reviews
Are WPBay products reviewed before publication?
Yes. New plugins, themes and scripts are reviewed before their first publication. A product with unresolved approval blockers is returned for changes or rejected rather than knowingly published first and reviewed later.
Is every WPBay product review performed by a human?
A human reviewer makes the approval decision. Automated tools may be used to support the review, but no scanner, warning count or automated score approves a product by itself.
Who are WPBay’s product reviewers?
WPBay reviews are performed by experienced developers. Szabi/CodeRevolution and Stefan/King’s Plugins are listed as reviewers across all categories on WPBay’s team page.
Does WPBay review every line of code?
Not necessarily. Reviews are proportionate and risk-based. The reviewer combines tools, manual inspection and practical testing, concentrating effort on the product’s important workflows and security-sensitive areas. Approval is not a complete code audit or penetration test.
Does approval mean a product is completely secure?
No. Approval means no unresolved approval blocker was identified during the proportionate review of the recorded version. It cannot guarantee that software contains no defect or that a vulnerability will never be discovered.
Are product updates reviewed?
WPBay may review updates, particularly when a release materially changes security-sensitive behavior, dependencies, compatibility, licensing, data handling, installation or important buyer-facing functionality. The product page should distinguish the current version from the last version that received a recorded full or targeted review.
Are CodeRevolution and other founder-owned products treated differently?
No. The same published requirements and enforcement options apply to founder-owned and third-party products.
What should I do if I find a bug?
For normal product support, use the support route shown in My Downloads or on the product page. For a broken or misleading listing, use Report this product or contact WPBay support.
How should I report a security issue?
Report it privately through the product report form or [email protected]. Include the affected product and version, reproducible steps, required permissions or configuration and the likely impact. Do not post exploit details publicly.
Our standard in one sentence
WPBay uses experienced human reviewers, supported by appropriate tools and practical testing, to identify meaningful approval blockers in a specific submitted release—and we tell buyers which release was reviewed, without turning a marketplace review or maintenance score into a security guarantee.