Last updated: July 2026

This page defines the technical, visual, security, functional, packaging, documentation, licensing, compatibility and presentation requirements for WordPress themes submitted to WPBay. It applies to new products, resubmissions and product updates, including classic themes, block themes, hybrid themes, child themes and any companion plugins or starter-content tools delivered with them.

These are minimum marketplace requirements, not optional suggestions. Meeting them does not guarantee approval: WPBay also evaluates whether the theme provides genuine buyer value, has a professional and coherent design, is realistically usable outside the seller’s own development environment and is presented honestly. Approval is not a security, accessibility, performance or legal certification and does not transfer responsibility from the seller. You remain responsible for the theme, its companion plugins, dependencies, assets, data handling, licensing, compatibility, maintenance and support commitments.

This is the authoritative technical standard for WordPress themes on WPBay. Older WPBay articles remain useful as background guidance, but this page takes precedence if an older example or recommendation conflicts with it.

How to read these requirements

The following terms are used deliberately:

• Must, required and must not describe approval requirements. A violation can block approval.
• Should describes an expected practice. A different implementation may be accepted when it is technically sound and clearly justified.
• May describes an optional practice.
• Blocker means an issue that must be corrected before approval.
• Recommendation means an improvement that normally does not block approval by itself.

WPBay reviews themes against four broad standards:

1. Technical quality: Is the theme secure, maintainable, compatible, standards-based and appropriately implemented for WordPress?
2. Real-world readiness: Can an ordinary buyer install, activate, configure, update, customize and replace the theme without hidden knowledge or avoidable failures?
3. Design quality and honest presentation: Does the theme offer a polished, useful design and do the screenshots, demo, description and supplied package accurately represent it?
4. Ownership and licensing: Does the seller have the right to sell every included component and are all applicable licenses respected?

Important clarifications to older WPBay guidance

Some examples in older marketplace articles reflect development practices from a much earlier browser and WordPress ecosystem. For current theme reviews:

• Testing Internet Explorer 6, 7 or 8 is not required. Themes must instead work in current supported versions of major browsers and relevant mobile browsers.
• A theme is not rejected merely because a validator does not recognize a current HTML element, modern CSS feature, vendor prefix, custom property or WordPress-generated attribute. Real syntax errors, invalid nesting, duplicate IDs, inaccessible markup and broken output remain blockers when material.
• WPBay does not enforce a fixed line-height range. Typography is judged by readability, hierarchy, rhythm, responsive behavior, language support and the actual design context.
• Using a visible separator character such as | is not automatically a rejection reason. Navigation and groups of links must still use semantic structures and purely decorative separators should normally be produced with CSS.
• Inline CSS is not automatically rejected. Static theme styling should live in stylesheets, theme.json, block styles or another maintainable asset. Small, genuinely dynamic values may be added through appropriate WordPress APIs when safely generated.
• A complete no-JavaScript copy of every interactive feature is not always required. Navigation and essential public content must remain understandable and accessible and critical actions should degrade sensibly where practical.
• A classic theme is not rejected merely because it is not a block theme and a block theme is not required to reproduce classic Customizer behavior. The product must accurately describe which architecture and editing experience it supports.
• A focused theme is not rejected merely because it has few templates. It must still provide enough design value, flexibility, documentation, polish and tested coverage to justify being sold.
• WordPress.org mainly reviews directory themes for code, security, licensing and usability. WPBay is a commercial marketplace and also evaluates visual quality originality, buyer value, completeness and whether the advertised premium experience is actually delivered.

Contents

• Submission and product readiness: review decisions, package, headers and versions, documentation and presentation, ownership, design quality and functional completeness
• Theme architecture and engineering: plugin territory, coding standards, security, classic themes, block themes, customization and portability
• Front-end quality and responsibility: assets and markup, responsive behavior, accessibility, internationalization, performance, privacy and demo import
• Delivery and integrations: licensing and updates, compatibility, WooCommerce, page builders and specialized themes
• Verification and submission: required testing, approval blockers, seller checklist, related WPBay guidance and official references

1. Review decisions and enforcement

WPBay may return one of the following decisions:

Approved

The theme has no identified blocker after a proportionate code, design, compatibility and product review. Approval does not mean that the theme is guaranteed to be free from every defect or compatible with every possible configuration.

Changes required

The theme has one or more identifiable, repairable blockers. This is the normal result for security omissions, plugin-territory functionality, broken templates, packaging defects, poor compatibility, incomplete demo imports, misleading claims, inaccessible primary controls, substantial visual problems or documentation gaps. The seller may correct the issues and resubmit.

Rejected

The theme is malicious, deceptive, stolen, intentionally dangerous, deliberately obfuscated, a prohibited clone, fundamentally non-viable or built around behavior that WPBay cannot responsibly distribute. Repeated serious violations or attempts to conceal prohibited behavior may also affect the seller’s account.

Temporarily disabled after approval

WPBay may temporarily disable an approved theme if a serious vulnerability, legal issue, malicious dependency, broken update, major compatibility failure or materially misleading claim is discovered later. Sellers are expected to respond promptly and provide a tested correction.

Automated tools support the review but do not decide it. Theme Check, PHP_CodeSniffer, accessibility tools, malware scanners, dependency audits, HTML/CSS validators and performance tools provide evidence. Reviewers examine the actual code and user experience, verify likely false positives and assess the real impact. Passing Theme Check does not guarantee approval and a harmless recommendation or modern-syntax warning does not automatically justify rejection.

2. Required submission package

2.1 Installable theme ZIP

The submitted theme archive must be directly installable through Appearance → Themes → Add New Theme → Upload Theme on a standard WordPress installation.

The installable theme ZIP must:

• contain one clearly named top-level theme directory;
• place style.css directly inside that directory;
• contain the required classic or block theme entry files described later;
• contain every runtime file required for the theme’s advertised presentation;
• use a stable, unique, lowercase folder slug, normally with hyphens between words;
• use portable paths and consistent filename capitalization;
• extract without path traversal, invalid filenames, broken symlinks or operating-system-specific paths;
• avoid a second unnecessary wrapper directory;
• avoid requiring the buyer to search for the installable theme inside the theme ZIP;
• activate without Composer installation, npm installation, a command-line build, manual file edits or private development credentials.

WPBay may provide an “all files and documentation” package containing the installable parent theme, an optional child theme, separately installable companion plugins, documentation, starter-content resources and design-source files. Every WordPress component inside that outer package must still have its own correctly structured installable ZIP.

The parent theme ZIP must not contain installable plugin ZIPs, a child-theme ZIP, another theme or demo-import archives. These belong beside the theme in the outer buyer package or in WPBay’s component-delivery system, not inside the production theme directory.

2.2 Stable theme identity

The theme folder, theme slug, text domain, parent-theme identity, WPBay license slug and update identity must remain stable across releases. Child themes, translations, saved template customizations, update checks and buyer integrations can depend on these identifiers.

Do not rename an established theme folder or change its technical identity after customers exist unless WPBay has approved a documented and tested migration plan. A product rebrand may change the displayed theme name without changing the technical slug.

Do not knowingly reuse the folder slug of an unrelated theme from WordPress.org or another installed product. Use the WordPress Update URI header and a correctly scoped updater to prevent an unrelated directory theme from overwriting the WPBay product.

Pattern slugs, style-variation filenames, template names, template-part names, menu-location identifiers, sidebar identifiers, theme-mod keys, public hooks and CSS classes documented for child-theme developers should also remain stable or receive a compatibility path.

2.3 Files that must be included

Every theme package must include:

• the complete production theme code;
• style.css with valid theme metadata;
• all required templates for its declared architecture;
• readme.txt or README.md;
• license.txt, LICENSE or an equivalently clear license file;
• a changelog, either inside the readme or in a separate clearly named file;
• screenshot.png or screenshot.jpg showing the actual theme;
• third-party copyright, source and license notices;
• translation template files when the theme is presented as translation-ready;
• local fonts, icons, scripts, styles, images and other assets required by the default design;
• configuration examples or developer documentation needed to use supported extension points.

When first-party JavaScript, CSS, SVG or another runtime asset is compiled, bundled or minified, readable source and reproducible build instructions must be included or supplied to WPBay for review. A reviewer must be able to determine how the distributed asset was produced and compare it with the submitted source.

Online documentation may supplement the package but must not replace a basic included readme.

2.4 Files that must not be included

Remove unrelated, unsafe or development-only artifacts before packaging, including:

• .git, .svn, IDE metadata, operating-system files and hidden project files;
• .env files, private keys, API credentials, access tokens, database passwords, signing secrets or live service credentials;
• database dumps, production logs, customer data, support exports, email lists or analytics exports;
• content.xml, widget-import .wie files, Customizer-import .dat files, database snapshots and other demo-import payloads inside the theme ZIP;
• installable plugin ZIPs, child-theme ZIPs, unrelated theme ZIPs and backup archives;
• .DS_Store, __MACOSX, Thumbs.db, desktop.ini, editor swap files, .bak, .old, .orig and duplicate theme copies;
• unnecessary node_modules, local Composer caches, build caches, coverage reports and large source archives;
• development servers, hot-reload clients, localhost references, debug scripts, test screenshots and private source-map paths;
• unused demos, abandoned templates, placeholder modules, generated mock data or integrations that are not part of the sold product;
• executable binaries, encrypted payloads or encoded source that is not essential, documented, licensed and reviewable;
• unoptimized full-resolution stock images or videos that unnecessarily inflate the production package.

Allowed configuration files such as theme.json, phpcs.xml, wpml-config.xml or another legitimate integration file must be used for a real purpose and must not expose private development details.

3. style.css headers, metadata and version consistency

The root style.css file must contain a valid WordPress theme header. WPBay expects the following fields where applicable:

All version declarations must agree. The following must not report different releases:

• the style.css header;
• readme and changelog;
• PHP, JavaScript, CSS or build version constants;
• WPBay product version;
• downloadable package name, when a version is included;
• updater metadata;
• companion-plugin compatibility declarations;
• documentation screenshots or release notes that identify a version.

Use a predictable versioning system, preferably semantic versioning. Breaking changes should not be shipped as silent patch releases. Removed templates, renamed hooks, changed preset slugs, altered theme-mod keys, changed companion-plugin requirements and other buyer-impacting changes must be documented.

Do not claim compatibility with an unreleased WordPress, PHP, WooCommerce, page builder or dependency version unless the release is explicitly marked as a beta tested against a named prerelease. “Tested up to” means tested.

4. Documentation, product description, screenshots and demo

4.1 Included documentation

The documentation must enable a buyer who understands normal WordPress administration, but not the theme’s source code, to reproduce the advertised result.

Document, as applicable:

• whether the theme is classic, block, hybrid or a child theme;
• installation and activation of the parent theme, child theme and companion plugins;
• a concise quick-start path from a clean site to a representative result;
• the supported Customizer, Site Editor, Global Styles, page-builder, widget and menu workflows;
• all major templates, template parts, patterns, style variations, layout controls and theme options;
• required WordPress, PHP, WooCommerce, browser, server and dependency versions;
• required and optional plugins, where they are obtained and what each one provides;
• whether a paid third-party plugin, account, API key, subscription, font service or separate license is required;
• starter-content and demo-import instructions, including what will be created or changed;
• how to remove, repeat or recover from a demo import;
• recommended image dimensions and media preparation;
• supported post formats, featured-image behavior, menu locations, widget areas and page templates;
• WooCommerce setup and exactly which classic or block storefront experiences are supported;
• child-theme setup and safe customization practices;
• public hooks, filters, CSS custom properties, template interfaces, pattern slugs and extension points intended for developers;
• where theme settings and imported data are stored;
• update instructions, compatibility notes and known upgrade effects on customized block templates;
• known limitations and intentionally unsupported configurations;
• support status, support channel and the practical scope of support;
• common errors and troubleshooting steps;
• a complete, readable changelog.

Instructions such as “import the demo,” “install the required plugins,” “configure normally,” or “edit the template as needed” are not sufficient when buyers need exact steps, prerequisites or recovery information.

Documentation links must work without requiring an unrelated purchase, private account or inaccessible service. The included documentation must contain enough information to install, configure, update and recover the product if the seller’s website is temporarily unavailable.

4.2 Product description

The WPBay listing must describe the exact package submitted. Every major claim may be tested.

The product title, category, tags, compatibility metadata and search keywords must be accurate. Do not use competitor names, unrelated integrations, popular niches or trademarked terms merely to attract search traffic.

The listing must clearly disclose:

• the theme architecture and intended audience;
• meaningful design and editing limitations;
• all required dependencies;
• whether companion plugins are included;
• page-builder requirements and whether a paid builder edition is needed;
• external services, accounts and recurring third-party costs;
• whether demo images, fonts, icons, templates and commercial plugins are included;
• whether starter-content import is available and what it changes;
• free-versus-premium differences;
• license and activation limits;
• whether support is included;
• whether the theme sends data off the buyer’s website;
• whether updates or key functionality depend on the seller’s server;
• which WooCommerce checkout architecture and features are supported;
• whether a feature is beta, experimental or available only in certain environments.

Do not describe templates, style variations, demos, integrations, accessibility features, performance scores or builder widgets that are not delivered and reachable in the submitted product.

Claims such as “100% accessible,” “fully WCAG compliant,” “guaranteed Core Web Vitals,” “SEO guaranteed,” “GDPR compliant,” “works with every plugin,” or “the fastest WordPress theme” require evidence that normally cannot be established by a marketplace review. Use precise and limited wording instead.

4.3 Screenshot and gallery images

The root theme screenshot must show the actual theme, not merely a logo, device mockup, feature list, advertisement or unrelated composition. WPBay recommends a 4:3 image at 1200 × 900 pixels so it displays consistently in WordPress and marketplace tooling.

The WPBay thumbnail, poster or cover image and gallery images may use a more promotional composition, but they must still represent the supplied theme accurately and must not imply that unavailable templates, services or assets are included.

Listing screenshots must:

• show the current submitted release;
• use readable and representative content;
• make clear which builder, template or variation is shown when relevant;
• avoid fabricated controls, results or integrations;
• avoid showing premium third-party features that are not included without a prominent explanation;
• use assets that the seller may legally display;
• avoid implying that demo-only stock photography, logos or commercial fonts are supplied when they are not.

4.4 Live demo

A live demo is strongly expected for a premium theme and may be required when screenshots cannot demonstrate the theme adequately.

The demo must:

• be stable and reasonably fast;
• represent the current sold version;
• demonstrate inner pages and content states, not only a single homepage;
• avoid broken links, placeholder errors, empty menus and unfinished sections;
• disclose major demo-only plugins or assets;
• avoid fake checkout, membership, booking, directory or account functionality;
• remain safe if visitors receive editor or administrator-like access.

Security requirements for public demos are defined later in this document.

5. Ownership, licensing and selling rights

You must own the theme and its design or hold documented rights to sell and distribute them. This applies to PHP, JavaScript, CSS, JSON, templates, patterns, companion plugins, fonts, icons, images, video, audio, sample data, starter content, AI-generated assets, screenshots and documentation.

The product license may be GPL-compatible, MIT, proprietary or another license accepted by WPBay, but it must be legally valid for the submitted package and accurately disclosed before purchase. A marketplace or proprietary license does not override GPL, attribution, source-availability, redistribution or other obligations attached to incorporated components.

The package must:

• include a clear product license;
• include copyright information for the theme itself;
• identify every third-party resource in a resources or third-party-notices file;
• preserve attribution and copyright notices required by third-party licenses;
• provide the source and license for fonts, icons, images, scripts, starter themes, frameworks and other resources;
• use dependencies and assets under terms compatible with the way the theme is distributed;
• comply with WordPress licensing obligations and the licenses of WordPress-derived components;
• identify forks and substantially modify any starter theme rather than merely renaming it;
• avoid trademark misuse, false affiliation and names designed to impersonate another product;
• avoid “nulled,” cracked, bypassed or unlawfully redistributed commercial code;
• avoid demo assets, fonts or stock media that the seller may use only on one website but cannot redistribute to buyers;
• avoid copied layouts, distinctive illustrations, pattern sets or complete designs taken from another theme or website.

If requested, the seller must provide source files, purchase records, commercial licenses, contributor agreements, design files, assignment agreements, AI-generation records or other reasonable evidence of ownership and distribution rights.

AI-assisted and AI-generated design or code is allowed, but the seller must verify originality, licensing, accuracy, security, maintainability and quality. AI assistance does not make copied designs or license-incompatible output acceptable.

6. Design quality, originality and buyer value

WPBay themes are paid design products. A technically valid theme can still require changes or be declined when its design and buyer experience are not commercially credible.

The theme must demonstrate:

• a coherent visual system rather than an assortment of unrelated sections;
• clear hierarchy, readable typography, deliberate spacing and consistent alignment;
• consistent colors, borders, shadows, radii, icon treatment and interaction states;
• an appropriate relationship between the design and the stated audience;
• polished desktop, tablet and mobile layouts;
• consistent treatment of WordPress-generated content, not only builder-created demo sections;
• usable default values and a sensible appearance before demo content is imported;
• professional empty, error, loading, validation and no-results states where applicable;
• enough variation and flexibility for the advertised use cases;
• attention to real content rather than layouts that work only with exact demo text lengths.

WPBay may decline:

• a superficial recoloring or renaming of an existing theme;
• a clone of a recognizable competing product or website;
• an almost unmodified starter theme, framework or builder template kit;
• a generic collection of free patterns presented as a unique premium theme;
• a theme whose main value is actually an unlicensed third-party page-builder kit;
• a visually unfinished design with inconsistent typography, spacing, alignment or components;
• a theme that provides little credible value beyond what current default themes and free patterns already provide;
• a niche theme whose design does not address the basic needs of that niche.

Originality does not require an unprecedented visual style. Meaningful differentiation may come from a better design system, stronger niche coverage, high-quality templates, thoughtful patterns, excellent accessibility, superior performance, reliable compatibility, professional documentation or another clear buyer benefit.

Reviewers judge the submitted theme and attainable buyer result, not an external design prototype. A polished screenshot cannot compensate for a broken or materially different installable product.

7. Functional completeness and real-world readiness

The final packaged theme must work as described on a clean WordPress installation.

At minimum:

• installation, activation, deactivation through theme switching, reactivation, update and deletion must be tested;
• the theme must not produce fatal errors, uncaught exceptions, common PHP warnings or notices, database errors, invalid block warnings, broken markup or JavaScript console errors during ordinary use;
• the front page, posts page, single post, page, archive, category, tag, author, date, search, 404, attachment/media and other supplied templates must render correctly where supported;
• navigation, pagination, comments, password-protected content, sticky posts, featured images, galleries, embeds, tables, forms, captions and long content must behave correctly when the theme advertises or naturally encounters them;
• the site must not become blank, unusable or severely broken merely because starter content has not been imported;
• required plugins that are missing or inactive must produce a safe and useful notice, not a fatal error;
• optional plugins must not be treated as mandatory;
• templates, patterns, menu locations, widget areas, style variations, theme options and builder templates must be connected to functioning output;
• buttons and links must lead to real actions or clearly identified placeholder destinations in starter content;
• settings and Global Styles must save, preview and persist correctly;
• theme defaults must not depend on the seller’s private database, unpublished content, localhost paths, fixed attachment IDs or live credentials;
• no important advertised workflow may be simulated, hard-coded for the demo or marked “coming soon”;
• external-service failures must not break unrelated theme output or WordPress administration;
• activating the theme must not automatically publish content, change the homepage, install plugins, reset settings or redirect the administrator without informed action.

The theme must respect Settings → Reading. A classic theme must display the posts page and static front page according to WordPress settings. A block theme must use the proper template hierarchy and must not hard-code demo pages as the front page.

A theme may intentionally omit a specialized template and rely on the WordPress fallback hierarchy. The fallback must still produce a complete, coherent result. Creating many files is not a quality metric; working coverage is.

8. Theme territory, companion plugins and dependencies

8.1 Presentation belongs in the theme

Theme code should control design and presentation. Features that users reasonably expect to survive a theme switch belong in a plugin.

The theme itself must not implement:

• custom post types or taxonomies used to store business content;
• custom blocks;
• custom content widgets, builder elements or dashboard widgets;
• shortcodes;
• custom user roles or permanent capabilities;
• custom user-contact fields;
• custom MIME types;
• custom database tables;
• recurring cron events, queues and background jobs;
• forms, submissions, leads, newsletters or CRM records;
• transactional or marketing email systems;
• SEO metadata, redirects, analytics or schema-management systems;
• booking, directory, listing, real-estate, job-board, event, LMS, membership, marketplace or payment business logic;
• account dashboards, vendor accounting, commissions, subscriptions or order processing;
• security, backup, migration, maintenance-mode or remote-management functionality;
• content-generation or AI-service features;
• functionality whose data should remain available when the buyer changes themes.

Presentation-specific metadata, such as a per-page sidebar or layout choice, may be acceptable when it is securely implemented, optional and safely ignored after a theme switch. It must not become the only place where meaningful content is stored.

Block patterns, presentation-only block styles and variations, Global Styles, template parts, menu locations, sidebars, image sizes and theme presentation controls are valid theme territory. Registering a new content block or persistent business object is plugin territory.

8.2 Companion plugins

Portable functionality may be supplied in separately installable companion plugins. Every companion plugin is independently subject to WPBay’s WordPress plugin technical requirements.

Companion plugins must:

• be packaged separately from the parent theme ZIP;
• have their own stable slug, version, readme, changelog, license and update identity;
• activate safely before or after the theme;
• avoid fatal errors when the theme is switched;
• preserve the user’s business content after a theme change;
• provide suitable generic output or documented integration points when the original theme is inactive;
• receive a working update path for WPBay buyers;
• avoid requiring an unrelated marketplace purchase code;
• disclose whether they are required or optional.

A companion plugin may contain custom blocks, widgets, builder elements, importers, post types and business integrations when these are implemented to plugin standards.

8.3 Dependency installation

Plugins may be recommended or required, but installation and activation must occur through an explicit administrator action. The theme must not silently install, activate, download, replace or modify plugins.

For every dependency:

• disclose the exact plugin and supported version range;
• state whether it is free, included, sold separately or requires an external subscription;
• provide a legitimate way for the buyer to obtain and update it;
• check availability before referencing its classes, functions, blocks or constants;
• fail safely when it is missing or incompatible;
• avoid showing repeated notices to users without permission to install plugins;
• avoid installing a modified or renamed copy that collides with the original plugin.

If the theme requires a premium dependency, the seller must have redistribution rights or make it unmistakably clear that the buyer must purchase it separately. A demo must not depend on premium modules that buyers cannot obtain under the disclosed terms.

8.4 Theme switching and lock-in

Switching to another theme must not destroy content, users, orders, settings owned by a companion plugin or other site data. The old design will naturally change, but the site must not lose business records because they were stored only in theme code.

Themes must not deliberately create lock-in through undocumented shortcodes, encrypted template data, theme-only custom blocks or content that becomes inaccessible without a remote service controlled by the seller.

9. WordPress coding standards and maintainable architecture

9.1 General standard

First-party code must substantially follow the current WordPress Coding Standards for PHP, JavaScript, CSS, HTML, accessibility, internationalization and inline documentation.

WPBay distinguishes style from risk. A few cosmetic spacing warnings normally do not block approval. Widespread standards violations, unreadable architecture, invalid callbacks, missing security controls, misuse of WordPress APIs or code that cannot reasonably be maintained can block approval.

9.2 Prefixes and public identifiers

All globally accessible first-party identifiers must use a unique namespace or a sufficiently distinctive prefix. This includes:

• PHP functions, classes, interfaces, traits and constants;
• theme mods and option keys;
• post meta used for presentation settings;
• cron hooks, actions and filters;
• AJAX actions and REST namespaces, if exceptionally justified;
• script and style handles;
• image-size names;
• pattern and pattern-category slugs;
• style-variation and block-style names;
• JavaScript globals;
• CSS classes used outside tightly scoped components.

Do not use generic WordPress or WooCommerce prefixes such as wp_, wordpress_, woo_ or woocommerce_ for first-party identifiers. A prefix should normally be at least four characters and should be unique rather than a common word.

Menu-location and sidebar identifiers do not need a visual vendor prefix when a clear, stable semantic identifier is more useful, but they must not collide.

9.3 Theme setup and file loading

Register theme supports, navigation locations, editor styles, image sizes and related features on the correct hooks, normally after_setup_theme.

Executable PHP files that are not intended as public endpoints should prevent direct execution, normally by checking ABSPATH.

Do not run expensive work merely because functions.php was loaded. The active theme loads on frontend, admin, REST, AJAX, cron and command-line requests. Keep initialization small and attach work to the correct context and hook.

Callbacks must be callable on every supported PHP version. Do not register missing classes, non-static methods as static callbacks or functions with the wrong accepted-argument count.

9.4 Use WordPress APIs and template hierarchy

Use the relevant WordPress API instead of bypassing it without a documented technical reason. This includes:

• template hierarchy and template-loading functions;
• Theme Support, Customizer, Settings, Options, Metadata, Filesystem, HTTP, Media, Navigation, Widget, Block, Pattern and Global Styles APIs;
• wp_enqueue_script() and wp_enqueue_style() for assets;
• WordPress media functions and responsive-image output;
• get_theme_file_uri(), get_theme_file_path() and their parent/child equivalents;
• WordPress date, locale, URL, path, escaping and translation functions;
• core post, term, comment and user APIs instead of direct table manipulation.

Do not:

• edit WordPress core or another plugin;
• redefine core functions;
• remove non-presentational core hooks;
• hide or disable the admin bar;
• replace WordPress login, update, editor or administration flows from the theme;
• hard-code wp-content, the database prefix, the uploads path, the site URL or the absolute theme path;
• bypass the template hierarchy with fragile URL inspection;
• include standard templates with raw PHP paths when get_header(), get_footer(), get_sidebar(), get_search_form(), get_template_part() or locate_template() is appropriate.

9.5 Code quality and public compatibility

Code must be understandable by a competent WordPress developer. Use clear names, appropriately sized functions, coherent components and comments where the reason for a non-obvious implementation matters.

The following can block approval when they obscure or endanger behavior:

• large duplicated template paths that have already diverged;
• dead production modules that reference missing files, blocks, controls or dependencies;
• placeholder comments used instead of implementation;
• swallowed errors and ignored failure results;
• pervasive suppression with @;
• unnecessary global state;
• fragile text replacement of WordPress, WooCommerce or builder output;
• hard-coded content IDs, attachment IDs, domains, filesystem paths, credentials, currencies or language assumptions;
• first-party code shipped only as minified, encoded, encrypted or machine-obfuscated output;
• generated template files that cannot be traced to readable source;
• a large framework included for trivial theme functionality.

Treat documented hooks, filters, template parts, preset slugs, pattern names, menu locations, sidebar IDs, CSS custom properties and child-theme interfaces as buyer-facing APIs. Do not remove or rename them in a routine update without a compatibility layer, deprecation notice, migration or clearly documented breaking release.

Third-party production libraries may be minified. Their identity, version, source and license must remain clear.

9.6 AI-assisted code and design

AI-assisted and AI-generated code or design is allowed, but the seller must understand, review, test, maintain and support it.

Common AI-generation defects are reviewed in the same way as human-written defects, including:

• nonexistent WordPress, WooCommerce, block or builder APIs;
• invalid block serialization and malformed theme.json;
• copied starter-theme identifiers or text domains;
• templates that reference missing parts, patterns, assets or controls;
• security callbacks omitted from theme settings;
• CSS that only works with the exact demo text;
• invented compatibility, accessibility and performance claims;
• placeholder interfaces and simulated results;
• assets or copied code with unknown licensing.

Using AI as a development tool is acceptable. Publishing its output without technical and design verification is not.

10. Security requirements

Security is an approval requirement. Theme code has a smaller legitimate attack surface than most plugins, but it still processes settings, content, URLs, metadata, imports and administrative actions.

Treat all external data as untrusted, including:

• $_GET, $_POST, $_REQUEST, $_COOKIE, $_FILES and request headers;
• Customizer, Site Editor, admin-setting, AJAX and REST values;
• starter-content and demo-import files;
• post, term, comment, user, menu, widget and theme-mod data;
• remote API responses;
• URLs, filenames, SVG, JSON, XML and serialized values;
• content submitted by administrators;
• values read from the database that originally came from a user, plugin, importer or external service.

10.1 Authentication, capabilities and CSRF protection

Every sensitive read or write action must verify that the current actor is authorized.

Use current_user_can() or the relevant WordPress mechanism. Theme configuration normally requires edit_theme_options; plugin installation and activation require their own narrower core capabilities. Do not authorize only by checking a role name.

State-changing browser actions must use a specific WordPress nonce in addition to capability checks. A nonce protects against cross-site request forgery; it is not authentication, authorization, ownership verification, rate limiting or proof that an administrator should be allowed to install a plugin.

Do not perform imports, resets, content creation, plugin installation, option changes, dismissals, license actions or destructive work merely because a GET parameter is present.

10.2 Validation and sanitization

Validate whenever the allowed set, type, range or format is known. Sanitization is not a substitute for validation.

For every saved value:

• verify that it exists before reading it;
• remove WordPress-added slashes where appropriate;
• cast it to the expected type;
• validate allowed values, lengths, ranges, formats and relationships;
• sanitize with the function appropriate to the data;
• reject invalid values instead of silently accepting an unsafe fallback.

Examples include:

• use absint() for attachment and content IDs, then verify that the object exists and is appropriate;
• use sanitize_key() and an explicit allowlist for layout, style, position, template, icon and enum choices;
• use sanitize_text_field() for plain single-line text;
• use sanitize_textarea_field() for plain multiline text;
• use sanitize_hex_color() or an equivalent strict validator for colors;
• use esc_url_raw() or sanitize_url() for stored URLs, then validate the permitted scheme and destination;
• use wp_kses() with a deliberate allowlist when selected HTML is genuinely needed;
• validate font families, font files, units, dimensions, breakpoints, CSS classes and custom CSS fragments according to their real destination;
• recursively validate arrays and reject unexpected keys or excessive nesting.

Every Customizer setting must have an appropriate sanitize_callback. A select or radio setting must validate against its registered choices, not merely strip characters.

10.3 Escape output in its final context

Escape dynamic output as late as practical. Sanitizing a value when it is saved does not remove the need to escape it when rendered.

Use standard WordPress template functions for post content, titles, excerpts, menus, comments and classes where they provide the correct handling. Do not blindly escape complete rendered post content and destroy its allowed markup, but do not assume custom metadata is safe merely because it came from WordPress.

Do not:

• use sanitize_text_field() as output escaping;
• concatenate untrusted values into HTML, CSS or inline JavaScript;
• insert untrusted strings through innerHTML or jQuery .html() without safe handling;
• print raw theme mods, Customizer settings, URLs, CSS classes, SVG or imported values;
• suppress escaping warnings without verifying every output path.

10.4 Theme settings, admin actions, AJAX and REST

Themes should rarely need custom AJAX or REST endpoints. When an endpoint is genuinely necessary, it must follow the same security requirements as a plugin endpoint:

• a specific nonce for authenticated browser requests;
• the appropriate capability;
• validation and sanitization for every parameter;
• object-level authorization where an object ID is accepted;
• bounded queries and responses;
• structured errors;
• no unnecessary exposure of private content, user data, filesystem paths or settings.

REST routes must use a unique, versioned namespace and a meaningful permission_callback. Public endpoints require a clear reason, strict output control and abuse protection.

Theme or companion-plugin admin code must not add globally permissive CORS headers, expose administrator data to the frontend or localize secrets into JavaScript.

10.5 Database, file and remote-request safety

Direct SQL should be exceptional in a theme. Use WordPress APIs. If direct SQL is unavoidable, use $wpdb->prepare(), trusted identifiers, correct prefixes, bounded results and appropriate error handling.

File uploads, archive extraction, demo imports, exports or filesystem writes belong in a companion plugin and must follow WPBay plugin security requirements. They must prevent executable uploads, path traversal, archive bombs, symlink escapes, unauthorized downloads, formula injection and partial destructive imports.

Use the WordPress HTTP API for remote requests. Do not disable TLS verification. Every remote request needs finite timeouts, size limits, error handling, response validation and a failure mode that does not break the site.

Do not allow arbitrary remote URLs that can reach localhost, private networks, link-local addresses, cloud metadata endpoints, local files or unsafe redirect destinations.

10.6 Secrets, dangerous execution and obfuscation

API keys, passwords, signing secrets, private tokens, license secrets and service credentials must never be committed in the package, printed into HTML, exposed through JavaScript or API responses, written to public logs or sent over unencrypted connections.

The following are investigation triggers and can be immediate blockers when unexplained or reachable with untrusted data:

• eval(), dynamic PHP execution, generated PHP or dynamic include and require;
• shell_exec(), exec(), system(), passthru(), proc_open() and similar process functions;
• unserialize() on untrusted data;
• decoding chains using base64_decode(), compression, XOR, character maps or remote payloads;
• downloading executable code outside the normal update process;
• ionCube or another encoding system that prevents review;
• hidden administrator creation, backdoors, remote consoles, credential collection or stealth telemetry.

The presence of base64_encode() or a standard minified library is not automatically malicious. The seller must be able to explain every sensitive construct and demonstrate how its input is constrained.

10.7 Redirects, links and generated output

Use wp_safe_redirect() for local redirects and allowlist permitted external destinations. Never redirect to an arbitrary request value.

Generated CSS, SVG, JSON, HTML, feeds, emails, documents or QR codes must encode user-controlled values for the actual destination format. An SVG is active content and must not be treated as a harmless image merely because it has an image extension.

Theme credit links, affiliate URLs, social links and button destinations must use safe, accurately disclosed destinations. The theme must not inject hidden links, SEO spam or remote tracking pixels.

11. Classic theme requirements

Classic and hybrid themes must follow the WordPress template hierarchy and use the standard hooks and template functions that allow WordPress and plugins to operate correctly.

11.1 Required structure

A classic theme must contain, at minimum:

• style.css in the theme root;
• index.php as the final template fallback;
• the WPBay-required readme, license, changelog and screenshot files;
• every referenced template part and runtime asset.

A commercially complete classic theme will usually need additional templates, but WPBay does not require a file merely to increase template count. The supplied hierarchy must cover the product’s advertised use cases and produce a coherent fallback for everything else.

11.2 Document structure and core hooks

Classic output must:

• use a valid HTML document type;
• include language_attributes() on the root HTML element;
• output the site character set correctly;
• call wp_head() immediately before the closing head element;
• call wp_body_open() immediately after the opening body element;
• include body_class() on the body;
• call wp_footer() immediately before the closing body element;
• use post_class() on post containers where appropriate;
• use wp_link_pages() for paginated post content;
• declare title-tag support instead of hard-coding the document title;
• declare automatic-feed-links support;
• leave core and plugin hooks in place.

Do not hard-code a favicon, canonical URL, feed URL, generator output, document title, admin bar behavior or another feature already managed by WordPress or a suitable plugin.

11.3 Template hierarchy and the Loop

Use the WordPress template hierarchy rather than testing URLs or request strings manually.

If standard template files exist, load them with the standard functions:

• get_header() for header.php;
• get_footer() for footer.php;
• get_sidebar() for sidebar.php;
• get_search_form() for searchform.php;
• get_template_part() or locate_template() for reusable custom parts.

Templates must use the main query correctly. Do not replace the main Loop with an unrelated custom query that breaks pagination, sticky posts, archives, search, password protection, previews or plugin filters.

Secondary queries must reset post data, use bounded result counts and avoid changing global query state unnecessarily.

11.4 Core content behavior

Where relevant to the advertised theme, test and correctly display:

• posts with and without titles, excerpts, featured images, categories, tags, authors, dates and comments;
• sticky posts;
• password-protected posts;
• paginated posts and archives;
• nested and paginated comments;
• galleries, captions, audio, video, embeds, pullquotes, tables, lists, code blocks and wide or full-width content;
• search results and no-results states;
• 404 pages;
• empty menus and widget areas;
• very long titles, words, URLs and navigation labels.

Use WordPress functions for post classes, titles, content, excerpts, metadata, pagination, comment forms, comment lists and navigation. Do not reproduce core behavior with a partial hard-coded implementation that excludes plugins or edge cases.

Register menu locations and widget areas through WordPress, render assigned menus with wp_nav_menu() and render sidebars with dynamic_sidebar(). A fallback must not inject demo navigation or links that the buyer cannot edit. When threaded comments are supported and enabled, load the core comment-reply script only where it is needed.

11.5 Theme supports and editor experience

Declare only theme supports that are actually implemented and tested. Depending on the product, these may include:

• custom logo;
• post thumbnails;
• navigation menus;
• HTML5 markup;
• editor styles;
• responsive embeds;
• wide alignment;
• custom background or header;
• post formats;
• WooCommerce and product-gallery features.

If a support or marketplace tag is declared, its associated controls and output must work. Do not declare editor-style, rtl-language-support, accessibility-ready, wide-blocks, WooCommerce support or a similar capability solely for marketing.

The block editor should provide a reasonable preview of frontend typography, colors, content width and supported block styles. Perfect pixel identity is not required, but the editor must not be so different that buyers cannot predict the published result.

12. Block theme and theme.json requirements

Block themes are reviewed against the current WordPress Site Editor, Global Styles, template, pattern and block-theme architecture.

12.1 Required block-theme structure

A block theme must include:

• style.css in the theme root;
• templates/index.html as the fallback block template;
• a valid theme.json appropriate to the declared minimum WordPress version;
• the WPBay-required readme, license, changelog and screenshot files;
• every template part, pattern, style variation, font and asset referenced by the theme.

Optional PHP must remain presentation-focused. A block theme does not gain permission to implement plugin-territory functionality merely because it has a functions.php file.

12.2 theme.json

The theme.json file must:

• contain valid JSON without comments, duplicate keys, malformed values or trailing syntax errors;
• declare a schema version supported by the minimum WordPress version;
• use only supported properties for that schema version;
• validate against the corresponding WordPress JSON schema;
• define coherent content and wide widths;
• use stable, unique preset slugs;
• use valid CSS values, units and custom-property names;
• register existing custom templates and template parts accurately;
• avoid referring to missing fonts, files, patterns or blocks;
• avoid disabling core editor controls merely to create artificial product restrictions;
• produce compatible frontend and editor styles.

Using the latest schema is not automatically correct when the theme claims support for an older WordPress release. Test how the declared minimum version interprets every used property.

Colors, font sizes, spacing presets, gradients, shadows, duotone filters and other design tokens should form a usable system rather than hundreds of arbitrary values. Preset slugs may be saved into buyer content and must not be renamed casually.

Font-family declarations must refer to locally supplied and properly licensed files unless the user has explicitly opted into a remote provider. Define appropriate formats, weights, styles and fallbacks. Do not declare a bold or italic face that is not actually supplied.

12.3 Templates and template parts

Block templates must:

• use valid block-comment serialization;
• have correct opening and closing markup;
• contain no “invalid block” state on activation;
• use registered blocks available under the disclosed dependencies;
• use the proper template hierarchy and filenames;
• include meaningful landmarks and one clear main-content region;
• use dynamic blocks for dynamic site data instead of hard-coded demo values;
• avoid fixed post IDs, attachment IDs, menu IDs, author IDs, product IDs or demo-domain URLs;
• preserve editable post content where buyers expect to edit page content;
• avoid excessive locking that prevents normal customization without a documented reason.

Every referenced template part must exist in /parts and every registered custom template must exist in /templates. Human-readable template and part titles must be accurate and translatable.

Use Query Loop, Post Content, Site Title, Navigation, Comments and other core dynamic blocks correctly. Do not hard-code a demo article list or site identity into static HTML and describe it as dynamic WordPress content.

12.4 Patterns and starter layouts

Bundled patterns must:

• have valid pattern headers and unique slugs;
• use complete, valid block markup;
• use only core blocks or blocks from clearly disclosed dependencies;
• avoid absolute demo URLs, private endpoints and fixed site-specific IDs;
• avoid hidden links, affiliate links, tracking resources and promotional content;
• use licensed images and icons;
• provide translatable titles, descriptions, categories and visible first-party text;
• remain usable after insertion rather than depending on code that only runs in the demo;
• avoid inserting PHP, shortcodes or executable content into posts;
• avoid forcing template locking or content permissions unrelated to the design.

PHP pattern files may generate presentation markup and correctly escaped theme asset URLs. They must not create content, alter settings, contact remote services or perform state-changing work merely because the pattern inserter loaded them.

12.5 Style variations and block styles

Every global style variation in /styles must be valid JSON, use a unique filename and accurate translatable title and work without missing fonts or unreadable color combinations.

Selecting a variation must not:

• produce invisible text, controls or focus indicators;
• break templates or editor controls;
• require an undocumented external font;
• replace content or create pages;
• contact a remote service;
• silently enable tracking.

Block style variations must use stable and scoped selectors. Prefer WordPress Global Styles, block-support APIs, public component classes and block stylesheets. Avoid relying on deeply nested internal block markup that WordPress or WooCommerce treats as private and may change.

12.6 Site Editor behavior

Test templates, parts, Global Styles, Navigation, style variations and patterns in the Site Editor.

The buyer must be able to:

• identify and edit the expected header, footer and primary templates;
• change global colors and typography without unrelated breakage;
• insert the supplied patterns;
• save and restore normal editor changes;
• preview representative desktop and responsive layouts;
• understand when a database-stored customization overrides an updated theme file.

Documentation must explain that user-customized block templates and Global Styles can take precedence over later theme-file changes. Do not force-delete buyer customizations during an update merely to make a new design appear.

13. Customizer, Site Editor, settings and onboarding

13.1 Use the native editing experience

Classic themes should use the Customizer for visual theme options where the Customizer is the appropriate core interface. Block themes should use theme.json, Global Styles, templates, patterns and the Site Editor rather than recreating those controls on a proprietary settings page.

A dedicated page under Appearance may be used for:

• documentation and support links;
• license and update status;
• dependency status;
• a clearly initiated starter-content workflow;
• specialized settings that do not have a suitable core design interface.

It must not become a parallel page builder or duplicate dozens of standard WordPress design controls without a strong technical reason.

13.2 Customizer settings

Every Customizer setting must:

• use a unique theme-prefixed ID;
• use edit_theme_options unless a narrower legitimate capability applies;
• declare a context-correct sanitize_callback;
• validate choice values against an allowlist;
• provide a safe default;
• use a suitable control type;
• save to an appropriate theme_mod or clearly justified option;
• preview safely through refresh, selective refresh or correctly encoded postMessage handling.

Controls must not render full saved secrets, execute arbitrary CSS or JavaScript or trust client-side validation.

If the theme supports a “reset settings” action, it must clearly identify what will be removed, require confirmation, verify capability and nonce and delete only the theme’s own presentation settings.

13.3 Settings storage

Use the Settings and Options APIs. Theme-specific presentation settings should normally use theme mods. When an option is justified, use a uniquely prefixed option and avoid creating hundreds of individual autoloaded values.

Do not store large logs, image binaries, generated CSS archives, import payloads, remote responses or queues in autoloaded options.

Do not modify the homepage, posts page, site identity, registration policy, permalink structure, user roles, mail sender, WooCommerce pages or another site-wide setting without an explicit user action and clear explanation.

13.4 Activation and onboarding

Theme activation must preserve the normal WordPress activation flow.

Do not:

• redirect automatically to a welcome page;
• show an activation popup or full-screen takeover;
• install or activate plugins automatically;
• publish starter content automatically;
• change site-wide settings automatically;
• repeatedly display an undismissable notice;
• hide WordPress or plugin notices.

One proportionate, dismissible admin notice may link to documentation, dependency installation or an optional setup wizard. Show it only to users with the relevant capability and do not display it forever after dismissal.

Admin pages and notices must use normal WordPress UI patterns and load their CSS and JavaScript only on the theme’s own screens.

14. Content portability, theme switching and child themes

14.1 Content portability

The buyer’s posts, pages, products, orders, users, business records, form entries, listings, courses, events, bookings and similar data must not be owned by the theme.

After switching themes:

• WordPress content must remain in the database;
• companion-plugin content types and records must remain accessible;
• core blocks must remain valid;
• custom plugin blocks must remain registered when their companion plugin is active;
• the former theme’s shortcodes must not appear because theme-only shortcodes are prohibited;
• site administration must remain usable;
• no cleanup routine may delete buyer content automatically.

The design will naturally change. That is not lock-in. Preventing access to content, storing business data in encrypted theme files or requiring the seller’s server to decode content is unacceptable.

14.2 Child-theme compatibility

A parent theme sold as customizable should support normal child-theme development.

Use:

• child-aware file-location functions where override behavior is intended;
• parent-specific functions only where the parent file must always be used;
• hooks and filters around meaningful extension points;
• stable template and public API names;
• enqueue dependencies that allow child themes to add or replace presentation safely.

Do not hard-code parent paths in a way that prevents supported overrides. Do not load parent and child styles through a fragile order that produces duplicated or missing CSS.

Parent-theme updates must never overwrite the active child-theme directory. A supplied sample child theme must have a correct Template header, its own text domain where necessary, a current version and documentation.

14.3 Products sold as child themes

If the WPBay product is itself a child theme:

• identify the exact required parent theme and supported versions;
• use the exact parent folder slug in the Template header;
• disclose whether the parent is free, included or purchased separately;
• verify the seller’s right to redistribute the parent when it is included;
• fail with a clear WordPress installation message when the parent is missing;
• avoid copying most of the parent theme into the child;
• provide enough original design and buyer value to justify the product;
• test updates to both the child and supported parent versions.

A child theme that depends on an inaccessible, abandoned or unrelated marketplace parent cannot be approved.

14.4 Block-theme customizations during updates

WordPress may store buyer-edited templates, template parts and Global Styles in the database. Those customizations can continue to override changed files after the theme updates.

Theme updates must:

• preserve those customizations;
• avoid silently deleting or resetting them;
• document important template changes that buyers may not see automatically;
• provide a safe way to compare, reset or reapply a theme template where practical;
• avoid renaming templates or preset slugs without a migration strategy.

15. CSS, JavaScript, HTML, images and fonts

15.1 Asset loading

Register and enqueue scripts and styles through WordPress. Declare dependencies accurately and use version strings that permit cache invalidation.

Load assets only where they are needed. Separate frontend, editor, Customizer, Site Editor and theme-admin assets when their scopes differ.

Use WordPress-bundled libraries where suitable instead of shipping conflicting duplicate versions. Third-party libraries must be maintained, licensed and free from known serious vulnerabilities.

Ordinary assets must be bundled locally rather than loaded from a public CDN. An official provider-hosted SDK may be accepted only when an intrinsic integration requires it and the dependency, privacy effects and consent behavior are disclosed.

15.2 CSS quality

Static CSS should live in stylesheets, theme.json, block stylesheets or another maintainable theme asset. Dynamic inline styles are acceptable when genuinely dynamic, safely generated and added through an appropriate WordPress API.

CSS must:

• be valid and maintainable;
• use a coherent design-token system where appropriate;
• be scoped to the intended frontend, editor, block or admin context;
• avoid overriding unrelated WordPress and plugin screens;
• avoid excessive !important rules used to fight every extension;
• avoid selectors tied to fragile block internals when a supported public interface exists;
• preserve visible focus, readable contrast, zoom, reflow and text spacing;
• support left-to-right and right-to-left layouts where advertised;
• avoid loading entire unused frameworks;
• avoid hiding content as a substitute for proper conditional rendering;
• avoid disabling text selection, browser zoom or normal user controls.

Modern CSS, custom properties, logical properties, container queries and progressive enhancement are allowed. Provide a usable fallback when a required feature is outside the theme’s disclosed browser support.

15.3 JavaScript quality

JavaScript must not:

• expose server secrets;
• create DOM-based XSS through unsafe HTML insertion;
• use eval(), generated functions or unsafe executable strings;
• depend on hard-coded demo IDs or URLs;
• silently ignore failed operations;
• bind the same event repeatedly;
• throw console errors during ordinary use;
• take over navigation, scrolling, keyboard behavior or browser history without an accessibility and usability reason;
• make primary content unavailable until a nonessential script finishes;
• implement business logic that belongs in a companion plugin.

Mobile navigation, dialogs, tabs, accordions, sliders, galleries, filters and other controls need correct keyboard behavior, focus management, names, states and reduced-motion handling.

First-party JavaScript must be readable and structured. When build tooling is used, supply reviewable source and build instructions.

15.4 Semantic HTML

Use valid and semantic HTML:

• links navigate and buttons perform actions;
• lists of links or repeated items use suitable list or navigation structures;
• labels identify form fields;
• headings form a meaningful hierarchy;
• tables are used for tabular data and include suitable headers;
• landmarks identify major page regions;
• IDs are unique;
• block-level structures are not placed in invalid inline contexts;
• placeholder text is not the only form label;
• decorative separators are not announced as meaningful content.

Do not remove WordPress-generated classes, attributes, hooks or markup solely to force a screenshot-perfect design if doing so breaks plugins or accessibility.

15.5 Images and media

Use WordPress media and responsive-image functions. Preserve srcset, sizes, intrinsic dimensions, captions and user-provided alternative text where appropriate.

Theme assets must:

• be compressed to a reasonable production size;
• use suitable dimensions and formats;
• avoid multi-megabyte images for small interface elements;
• avoid loading every demo image on every page;
• avoid using CSS backgrounds for meaningful content that requires alternative text;
• avoid autoplaying audio;
• avoid autoplaying video with sound;
• provide controls, captions or transcripts when media is essential.

Do not hard-code alternative text that misrepresents user-selected media. Decorative images should be handled so assistive technology can ignore them.

15.6 Fonts and icons

Every bundled font and icon set needs a documented source and redistribution license.

Prefer self-hosted fonts. Include only the weights, styles, character subsets and file formats actually used. Define fallbacks and avoid invisible text while fonts load.

Do not:

• fetch Google Fonts or another remote font without informed user choice;
• pretend a system font is a bundled commercial font;
• convert an unlicensed desktop font into a web font;
• load a complete icon library for a handful of icons;
• use an icon without an accessible name when it performs an action;
• rely on an icon font in a way that exposes meaningless characters when CSS fails.

16. Responsive design, browsers and devices

The theme must be usable at realistic viewport widths and with user zoom. Responsive quality is evaluated across complete templates, not only the homepage hero.

Test:

• narrow mobile widths, including approximately 320 CSS pixels;
• common larger mobile and tablet widths;
• laptop and desktop widths;
• portrait and landscape orientation where relevant;
• browser zoom and increased text size;
• touch, mouse and keyboard input;
• both logged-out and logged-in states;
• the WordPress admin bar on the frontend.

The design must avoid:

• unintended horizontal scrolling;
• clipped text, controls, menus, modals, tables, embeds and form fields;
• off-screen mobile navigation;
• controls that require hover;
• overlapping sticky headers and anchor targets;
• fixed elements that cover checkout or consent controls;
• unreadably small text or touch targets;
• content order that becomes illogical when columns stack;
• images and video that overflow their containers;
• breakpoints that only fit the exact demo content.

Use responsive design rather than user-agent sniffing. Device-specific behavior must have a robust fallback.

Test current supported versions of Chrome, Firefox, Safari and Edge as relevant to the product. Test mobile Safari and Chrome for public responsive interfaces. A reasonable and prominently documented limitation may be accepted; ordinary layouts and primary workflows must not break.

Internet Explorer 6, 7 and 8 are not required. Opera-specific testing is not normally required when the theme works correctly in the underlying current browser engine, unless the product explicitly supports or targets Opera.

17. Accessibility

All themes must meet a practical accessibility baseline. New and updated interfaces are expected to follow WordPress accessibility standards and target WCAG 2.2 Level AA where applicable.

Reviewers may check:

• a working skip mechanism when repeated content precedes the main content;
• meaningful landmarks and one clear main region;
• complete keyboard access;
• visible focus on links, controls, navigation and form elements;
• logical focus order;
• correct mobile-menu, modal, submenu, tab, accordion and dialog behavior;
• accessible names, roles, values and states;
• labels and instructions for forms;
• error identification and association;
• meaningful heading structure;
• text links distinguishable without relying only on color;
• sufficient text, icon, control, focus, hover and disabled-state contrast;
• information not conveyed by color, position or shape alone;
• suitable alternative text behavior for images;
• accessible captions, audio, video and animation;
• responsive reflow, zoom, text spacing and readable line length;
• no keyboard traps;
• no unexpected context changes;
• accessible hover and focus content;
• warning when a link unexpectedly opens a new tab or window;
• respect for reduced-motion preferences;
• adequate pointer-target size;
• screen-reader text that remains available and correctly hidden visually.

Use native HTML controls before ARIA. ARIA must accurately describe the real behavior and must not be added merely to silence a checker.

Mobile navigation is part of the accessibility review. Hiding a desktop menu and displaying a visually convincing but keyboard-inoperable replacement is a blocker.

If the theme claims accessibility-ready, WCAG conformance or an equivalent certification-style status, it must satisfy the complete current WordPress accessibility-ready requirements, include an accessibility statement and avoid requiring inaccessible companion plugins. A limited automated audit is not enough to justify the claim.

18. Internationalization, localization and RTL

All user-facing first-party strings must be translatable through the appropriate WordPress internationalization mechanism unless they are buyer content, a technical identifier or supplied by a disclosed external service.

Requirements include:

• use the stable theme text domain consistently;
• normally match the text domain to the theme folder slug;
• keep literal source strings inside translation functions;
• use translator comments where placeholders are not obvious;
• use numbered placeholders when translators may need to reorder values;
• use _n() or an equivalent plural mechanism;
• escape translated output for its final context;
• load JavaScript translations through WordPress;
• load theme and child-theme translation files through the appropriate current WordPress mechanism;
• keep companion-plugin strings in the companion plugin’s own text domain;
• make template, pattern, style-variation, Customizer and theme.json interface titles translatable;
• avoid concatenating sentence fragments that translators cannot reorder;
• use WordPress date, number and locale formatting;
• avoid hard-coded English, date formats, decimal separators, address order and currency assumptions.

Do not use variables or constants as the original gettext string. Do not use multiple inconsistent text domains copied from starter themes or companion products.

RTL support

A theme that claims RTL or translation readiness must provide a usable right-to-left presentation.

Use logical CSS properties where practical or provide a maintained rtl.css. Test:

• navigation and submenus;
• icons and directional arrows;
• grids and columns;
• alignment controls;
• forms and validation;
• sliders and carousels;
• WooCommerce;
• editor styles and Global Styles;
• mixed left-to-right and right-to-left content.

Do not mechanically mirror icons whose meaning should remain unchanged. Bundled fonts must contain the characters required for advertised languages or use suitable fallbacks.

19. Performance and scalability

A premium theme must perform reasonably with realistic content, not only on an empty demo with caching.

19.1 Conditional loading

Load scripts, styles, block assets, libraries, editors and integrations only where needed.

Avoid:

• loading every slider, gallery, animation, icon, builder and WooCommerce asset on every page;
• network requests on every frontend view;
• scanning all posts, products, terms or files during a normal request;
• writing options or generated CSS on every page load;
• globally filtering every translated string;
• loading admin frameworks on unrelated WordPress screens;
• forcing a large JavaScript framework for a small menu toggle;
• rendering hidden copies of every responsive component.

19.2 Queries and rendering

Custom theme queries must be bounded, paginated where appropriate and reset correctly.

Filters that alter WordPress queries must be restricted to the intended frontend query. Check the main-query and administration context as appropriate rather than accidentally changing media, menu, REST, editor or admin-list queries.

Do not:

• use posts_per_page = -1 for public archives without a strict reason;
• query one related record per item in a large loop when data can be prefetched;
• count by loading full result sets;
• repeat the same expensive query in multiple template parts;
• bypass WordPress caching without need;
• trigger remote APIs during template rendering;
• render an unlimited mega-menu, product list, related-post list or social feed.

Business queries and complex data access belong in companion plugins. The theme should render supplied data efficiently.

19.3 CSS, JavaScript, images and fonts

Production assets should be compressed and cacheable. Remove development code, unused frameworks, duplicate libraries and oversized source maps.

Use:

• responsive images and correct intrinsic dimensions;
• lazy loading where appropriate;
• eager loading or suitable priority for the actual above-the-fold key image when justified;
• bounded and purposeful preloads;
• local fonts with limited weights;
• block-specific styles or conditional assets where they materially reduce unused CSS;
• stable asset versions for cache invalidation.

Do not lazy-load every image indiscriminately, especially the likely Largest Contentful Paint image. Do not preload fonts, scripts or images that the page does not use.

19.4 Performance claims

Do not advertise a guaranteed PageSpeed, Lighthouse, Core Web Vitals, load-time or query-count score without defining the environment and content. Performance depends on hosting, plugins, media, caching, geography, consent tools and buyer configuration.

A theme may advertise that it is optimized or lightweight when the package and realistic tests support that statement. A screenshot of one perfect laboratory run is not a universal guarantee.

20. Privacy, telemetry and external services

20.1 Privacy by default

Themes should render local presentation without contacting third parties.

Remote fonts, analytics, tracking pixels, error reporting, usage analytics, template libraries, remote images, marketing beacons and nonessential service calls must be opt-in. Consent must be informed, specific and reversible.

Do not:

• treat activation as consent;
• load a remote resource solely to count installations;
• send the site URL, administrator email, installed-plugin list, content,
• or server details without a documented need and permission;
• hide telemetry inside a license or update request;
• continue collection after opt-out;
• use the frontend to display remote advertisements.

Essential license and update requests are not automatically telemetry, but they must transmit only necessary data, use HTTPS and be disclosed.

20.2 External services

When a feature requires an external service, the listing and documentation must identify:

• the provider;
• why the service is needed;
• the exact data transmitted;
• whether an account is required;
• free and paid limits;
• separate charges;
• applicable geographical restrictions;
• relevant terms and privacy policy;
• what stops working when the service is unavailable;
• whether the buyer can select a different provider.

The theme must not become unusable merely because a nonessential documentation, marketing, analytics, font, license, update or template-library server is unavailable.

20.3 Logs and diagnostics

Themes should rarely create their own logs. Any log must be private, bounded and free of passwords, tokens, payment data, private content and unnecessary personal information.

Diagnostic exports must show the administrator what will be included before transmission. Do not silently send the database, environment details, access tokens or customer records to support.

20.4 Credits, upsells and affiliate behavior

The public site must display the site owner’s identity, not forced theme-author advertising.

A theme must not:

• inject hidden backlinks, SEO spam, advertisements or promotional content;
• require a visible “powered by” credit unless this is prominent before purchase and legally permitted;
• place upsells on the public frontend;
• imitate core security warnings;
• manufacture urgency or fake problems;
• obscure normal controls to force another purchase;
• replace the buyer’s affiliate ID;
• append undisclosed referral parameters;
• intercept unrelated outbound links.

Admin upsells must be truthful, proportionate, dismissible where presented as a notice and normally confined to the theme’s own screen. Affiliate relationships and commissions from required services must be disclosed.

20.5 Compliance claims

Do not claim that installing the theme automatically makes a website compliant with GDPR, CCPA, accessibility law, PCI DSS, medical regulation, tax law or another legal regime.

A narrower statement about included design or privacy tools may be acceptable when precisely described.

21. Starter content, demo import and live-demo security

21.1 Starter content and import architecture

Native WordPress starter content registered through the core starter-content theme support is allowed. It must be limited to the core starter-content workflow, use editable and legally distributable content and must not become a hidden substitute for a bulk importer.

More extensive demo import is portable functionality and must be implemented through a separately packaged companion plugin or an established importer plugin, not hidden in theme initialization.

Import payloads such as WordPress XML, widget .wie, Customizer .dat, builder kits and other demo data must not be embedded in the production theme ZIP. They may be delivered as separate buyer resources or retrieved through a documented import service after explicit user action.

The importer must:

• verify the appropriate capability and nonce;
• show which plugins and data are required;
• explain what will be created, changed, downloaded or replaced;
• obtain confirmation before changing site-wide settings;
• use WordPress APIs for content, media, menus, widgets and options;
• validate all local and remote payloads;
• parse XML without external-entity expansion or unintended network and local-file access;
• use HTTPS and safe remote-request handling;
• limit download and extraction size;
• prevent path traversal and executable uploads;
• map old URLs, IDs, authors, attachments, menus and relationships correctly;
• avoid importing administrator accounts, live credentials, API keys, private email addresses or seller-specific identifiers;
• handle partial failures and timeouts;
• avoid marking the import complete when a required stage failed;
• avoid duplicating everything when the user retries;
• provide a clear report of completed and failed steps.

Do not erase existing content, menus, widgets, products orders, pages, theme mods or builder settings unless the administrator has explicitly selected a clearly described destructive operation.

A practical rollback or “remove imported starter content” feature is strongly recommended. If full rollback is not possible, documentation must explain recovery and backup expectations before import.

21.2 Remote import services

If demo packages are downloaded from the seller:

• the service must be stable and documented;
• packages must be versioned and compatible with the theme release;
• responses and content types must be validated;
• package integrity should be verified through a trusted hash or signature where practical;
• failures must not break the theme;
• buyer credentials and site data must not be collected unnecessarily;
• imported executable PHP or plugin code is prohibited;
• the buyer must know that import depends on an external server.

A theme whose advertised appearance cannot reasonably be reproduced because its demo service is broken, private, temporary or inaccessible is not buyer-ready.

21.3 Demo content and asset rights

Every imported image, icon, font, video, audio file, text sample and template requires appropriate redistribution rights.

If a demo uses assets that are not included:

• disclose this clearly before purchase;
• replace them in the downloadable import with legally distributable alternatives;
• avoid making the unavailable asset the primary reason the design appears valuable;
• document how buyers can source or replace equivalent media.

Do not import copyrighted articles, logos, customer reviews, personal data or recognizable private individuals without permission.

21.4 Live-demo isolation

A live demo must never create a route into WPBay, the seller’s infrastructure, another customer or another visitor.

If visitors receive editor or administrator-like access:

• each session must be strongly isolated;
• file editing and file modifications must be disabled;
• theme and plugin installation must be blocked;
• arbitrary uploads and code execution must be blocked;
• dangerous capabilities must be removed server-side, not merely hidden with CSS;
• credentials and infrastructure secrets must not be shared with the demo;
• instances must expire and be cleaned up reliably;
• one visitor must not access another visitor’s data;
• reset processes must not expose backups, database dumps or private URLs.

Public demo provisioning requires strict rate limits, broader capacity limits, abuse controls, unpredictable instance identifiers, authenticated internal calls, resource limits and reliable cleanup. A CAPTCHA alone is not sufficient protection for an expensive anonymous provisioning endpoint.

22. WPBay licensing and updates

Licensing is optional unless required by the product’s business model. If the theme implements license activation or automatic updates, the WPBay version must support WPBay buyers.

22.1 Licensing

A WPBay theme must not:

• require an Envato, ThemeForest, another marketplace or unrelated store purchase code;
• activate only against a product ID owned by another marketplace;
• require the buyer to repurchase the theme elsewhere;
• contain a bypassed, cracked or nonfunctional licensing implementation;
• use a license failure to blank the frontend or make WordPress administration inaccessible;
• delete, encrypt, corrupt or hold buyer content hostage;
• expose API secrets or allow one buyer’s code to control another buyer’s activation;
• treat a temporary licensing-server outage as a permanent deactivation.

Use the WPBay license API or SDK when license verification is needed. License checks must use HTTPS, validate responses, handle timeouts, respect activation limits and provide a practical deactivate or reset path.

Document what happens when a license expires, is deactivated, reaches its activation limit or cannot contact the server. If expiration limits future updates, support, template-library access or another service, say so clearly before purchase.

The technical license slug must remain stable across updates and rebrands.

22.2 Parent-theme updates

Theme update code must:

• request updates only for the correct theme;
• use the stable theme folder and stylesheet identity;
• compare versions correctly;
• use HTTPS;
• validate remote responses;
• download only from trusted and expected sources;
• avoid accepting an arbitrary package URL;
• supply a correctly structured installable theme ZIP;
• preserve theme mods, user content, menus, widgets, Global Styles and database-stored template customizations;
• avoid overwriting an active child theme;
• run any genuinely necessary setting migration safely and only once;
• display release and compatibility information accurately;
• let WordPress handle the normal installation process.

An update must not download and execute PHP as a substitute for the normal WordPress update mechanism. Do not silently self-modify production PHP or JavaScript, write executable modules into the theme directory or operate a second hidden updater.

Before changing a template name, template-part name, style-variation filename, preset slug, menu location, sidebar ID, theme-mod key or public hook, determine how existing sites and child themes will be migrated.

Do not reset buyer customizations merely because the updated theme’s screenshot or demo has changed.

22.3 Companion-plugin updates

Companion plugins must update independently and safely through WPBay or another properly disclosed channel available to WPBay buyers.

A theme update must not:

• overwrite a companion plugin’s directory;
• ship an outdated embedded plugin copy;
• silently downgrade a plugin;
• require a matching plugin version that buyers cannot obtain;
• activate a plugin without consent;
• delete plugin-owned data.

Coordinate version compatibility so buyers are not left with a theme and companion plugin that cannot run together. Where a coordinated update is necessary, provide safe notices and backward-compatible transition releases.

23. WordPress, PHP, server and multisite compatibility

23.1 Declared WordPress and PHP versions

The minimum WordPress and PHP versions must reflect the entire package, including Composer dependencies, build output, optional PHP files, demo-import code and companion-plugin integration paths.

Do not declare PHP 7.4 while shipping PHP 8.1 syntax. Do not declare an older WordPress version while using block, theme.json or core APIs unavailable in it without a fallback.

Test at minimum:

• the oldest declared WordPress version;
• the current stable WordPress release;
• the oldest declared PHP version;
• at least one current supported PHP release;
• current supported versions of every required dependency.

The theme must not depend on deprecated behavior already removed from a declared compatible version. Deprecation warnings visible under WP_DEBUG must be addressed when they originate from first-party code.

23.2 Classic, block and hybrid compatibility

Describe the architecture accurately:

• a classic theme primarily uses PHP templates and may support the block editor for content;
• a block theme uses block templates and the Site Editor;
• a hybrid theme intentionally combines supported classic and block-theme techniques.

Do not label a theme “full site editing” when only page content is editable with blocks. Do not promise Customizer options that disappear because the product is actually a block theme.

If the theme requires the Gutenberg plugin or another prerelease feature beyond stable WordPress, disclose this prominently. A product intended for normal production use must not silently depend on an experimental plugin build.

23.3 Common hosting environments

Unless clearly sold for a specialized environment, the theme should work on normal WordPress hosting without:

• root access;
• a persistent Node.js or Python process;
• shell commands;
• a particular control panel;
• Apache-only rewrite rules;
• writable theme PHP files after installation;
• manual Composer or npm installation;
• unusually high memory or execution limits;
• disabled TLS verification;
• a permanent connection to the seller’s server.

Special requirements are acceptable only when intrinsic to the product, prominent in the listing and correctly tested.

23.4 Multisite

Do not claim multisite compatibility unless tested.

When multisite is supported:

• network installation and per-site activation must behave normally;
• theme settings must use the correct site scope;
• companion plugins must use the correct site or network scope;
• one site must not read another site’s private content or settings;
• starter-content import must affect only the intended site;
• network-only actions must use the appropriate super-admin capability;
• updates must not assume a single site or single active theme configuration.

If multisite is intentionally unsupported, disclose the limitation and fail safely.

23.5 Coexistence with WordPress and plugins

The theme must coexist with WordPress core, common caching and optimization systems, a normal SEO plugin, translation plugins, accessibility tools and extensions relevant to its stated purpose.

Avoid:

• generic PHP or JavaScript globals;
• globally invasive CSS;
• output buffering around entire WordPress responses;
• replacing core screens;
• filtering unrelated content;
• removing plugin hooks;
• hard-coded assumptions about the active plugin set;
• disabling core features to make the demo match a screenshot.

You are not required to guarantee compatibility with every plugin. Known material conflicts and exclusive integrations must be disclosed.

24. WooCommerce theme requirements

Themes that declare or advertise WooCommerce integration receive additional review.

24.1 Declaring and testing support

Declare WooCommerce support on the correct hook, normally after_setup_theme, when the theme provides WooCommerce-specific templates or behavior.

The listing and documentation must identify:

• the minimum and tested WooCommerce versions;
• whether the design is for classic WooCommerce templates, block templates or both;
• Cart and Checkout block support;
• any required WooCommerce extensions;
• any unsupported legacy or current storefront path.

Do not claim WooCommerce support merely because a generic page template happens to display a shortcode.

24.2 Classic WooCommerce templates

Prefer hooks and supported styling interfaces when they can achieve the design. Copying complete WooCommerce templates creates a maintenance obligation.

When template overrides are used:

• include only the overrides genuinely needed;
• retain required hooks and extensibility points;
• keep the template version headers accurate;
• compare every override with the current supported WooCommerce source;
• remove obsolete overrides;
• avoid a catch-all woocommerce.php when it conflicts with more specific archive overrides;
• avoid changing business logic inside presentation templates.

An outdated template that still renders is not automatically harmless. Review whether it omits security, accessibility, checkout, product or extension changes introduced by WooCommerce.

24.3 WooCommerce block templates

Block themes must test current WooCommerce product, catalog, cart, checkout, mini-cart, account, order-confirmation and notice experiences relevant to the design.

When overriding page-cart.html or page-checkout.html, keep the Cart or Checkout block in the assigned page content and render that content through the appropriate Post Content structure. Do not hard-code a Cart or Checkout block directly into a template in a way that makes the editor and storefront disagree.

Use Global Styles, supported block styles and public component classes where possible. Avoid deep selectors tied to WooCommerce block internals that are explicitly treated as private and subject to change.

24.4 Storefront design coverage

Test:

• shop and product-category archives;
• product search and no-results;
• simple, variable, grouped, external, downloadable, virtual, sale, out-of-stock and backordered products as relevant;
• product galleries, zoom, lightbox, variation selection and quantity controls;
• notices, validation, coupons, shipping, taxes and payment fields;
• Cart and Checkout at mobile and desktop widths;
• My Account, login, registration, addresses, orders and downloads;
• reviews and ratings;
• mini-cart and empty-cart states;
• long product names, prices, currencies, attributes and translated labels;
• keyboard use, focus, contrast, error messages and screen-reader output.

Do not hide a WooCommerce notice, required checkout field, terms checkbox, payment method, price, tax or order detail merely because it does not fit the visual design.

24.5 Business logic remains plugin territory

The theme must not calculate prices, discounts, taxes, shipping, commissions, payments, refunds, subscriptions, inventory, bookings or order states.

Do not query or modify WooCommerce orders directly from the theme. Any companion plugin that reads or writes orders must meet WPBay plugin requirements, including High-Performance Order Storage compatibility.

Theme switching must not make orders, products, customer accounts or other WooCommerce data inaccessible in WordPress administration.

25. Page builders and third-party platform integrations

Themes built around Elementor, WPBakery, Bricks, Beaver Builder, Divi, a block library, an LMS, a directory plugin or another platform must make that dependency transparent.

25.1 Dependency disclosure

State:

• the exact required platform and supported versions;
• whether the free or paid edition is needed;
• whether the license is included;
• whether updates are available to the buyer;
• which advertised templates require the platform;
• which features stop working without it;
• whether imported content remains editable after the dependency is disabled.

A buyer must not discover after purchase that the demo requires a separately purchased “Pro” edition, add-on bundle, template cloud or account.

25.2 Builder extensions

Custom builder widgets, modules, dynamic tags, controls, post types and portable functionality belong in a companion plugin.

The theme may:

• style the builder’s public output;
• provide templates or kits;
• register presentation settings through a supported API;
• integrate theme locations;
• provide design tokens and responsive presets.

It must not hide a full plugin inside functions.php or the theme’s inc directory.

25.3 Template imports and global settings

Builder templates and site kits must:

• be delivered and imported through a secure companion workflow;
• use licensed assets;
• avoid fixed demo URLs, private IDs and seller credentials;
• avoid overwriting the buyer’s global builder settings without clear consent;
• map fonts, colors, content and media correctly;
• avoid duplicate pages and templates on retry;
• remain editable with the disclosed builder edition.

25.4 Compatibility and maintainability

Use supported builder APIs rather than copying internal classes or targeting unstable generated markup.

Test:

• the minimum and current supported builder versions;
• frontend and editor views;
• responsive controls;
• theme header and footer integration;
• archive and singular templates;
• caching and asset optimization;
• builder safe mode or dependency deactivation;
• updates from the previous public theme version.

Do not bundle a modified commercial builder, bypass its license or promise that a separately licensed builder will remain available forever.

26. Specialized theme categories

Niche themes remain presentation products. Their associated business features must be provided by supported plugins.

26.1 Directory, listing, real-estate, automotive and job-board themes

Listings, properties, vehicles, applications, submissions, maps, payments, favorites, reviews, messaging and search indexes must belong to a companion or established third-party plugin.

The theme must test:

• archive, single, search, filter, map, empty and submission states supplied by the plugin;
• long and missing field values;
• missing images and locations;
• logged-out, owner, visitor, moderator and administrator views;
• mobile filters and map controls;
• content remaining available after a theme switch.

Do not advertise a complete directory business when the supplied product only styles static demo pages.

26.2 LMS, membership, marketplace and community themes

Courses, lessons, quizzes, memberships, subscriptions, vendor accounts, commissions, profiles, forums and messages belong to plugins.

Disclose the exact supported LMS, membership, marketplace, forum and community products. Test their current templates, blocks, dashboards, forms, permissions, empty states and mobile behavior.

Do not reproduce payment, access-control, grading, vendor or user-privacy logic in the theme.

26.3 Magazine, news and advertising themes

The theme must handle:

• long titles, breaking-news labels, multiple authors, categories, tags, dates and time zones;
• empty and large archives;
• pagination and search;
• responsive embeds and media;
• accessible carousels and tickers;
• ad positions without layout shift or hidden content;
• article readability independently of the demo builder.

Ad serving, consent, analytics, paywalls, subscriptions, newsletter collection and automated content import belong to plugins or external services. Disclose them.

Do not insert the seller’s ad IDs, analytics, affiliate links or promotional articles into buyer sites.

26.4 Portfolio, photography, video and creative themes

Test varying aspect ratios, portrait and landscape media, missing captions, large galleries, keyboard navigation, focus, reduced motion, responsive images and media-loading performance.

Do not require buyers to upload original full-resolution media merely to make thumbnails look correct. Lightboxes and galleries must remain accessible and must not block access to captions or controls.

If proofing, client delivery, watermarking, sales, private galleries or download permissions are advertised, that functionality must come from a disclosed plugin and work end to end.

26.5 Multilingual, RTL and accessibility-focused themes

Claims of multilingual-plugin compatibility, RTL support or accessibility readiness require testing beyond translated screenshots.

Test real translated content, longer labels, language switchers, mixed-direction content, mirrored layouts, local fonts, WooCommerce or relevant plugin output, keyboard operation, focus and screen-reader behavior.

Do not claim legal or universal accessibility compliance merely because the color palette passes one automated scan.

27. Testing required before submission

The seller must test the final packaged ZIP and buyer package, not only the development repository or live demo.

27.1 Installation and lifecycle test

Test:

• installation from the submitted parent-theme ZIP;
• activation on a clean site;
• activation without companion plugins;
• installation and activation of each required companion plugin through user action;
• dependency deactivation and version mismatch;
• switching to a default WordPress theme and back;
• activation with a child theme;
• update from the previous public release;
• deletion after switching away;
• preservation of content and settings through updates and theme switching;
• behavior when the license or update server is unavailable.

27.2 WordPress content coverage

Use the current WordPress Theme Unit Test data or equivalent comprehensive content.

Test:

• front page and posts-page settings;
• single posts and pages;
• categories, tags, dates, authors, search and 404;
• posts with no title, very long titles, long words and long URLs;
• excerpts and More links;
• password protection;
• sticky and paginated posts;
• comments, nesting, closure and pagination where supported;
• all common core blocks;
• images, captions, galleries, audio, video, embeds, tables, code, quotes, pullquotes, lists, buttons, columns, groups, covers and wide/full alignment;
• menus with deep nesting, long labels, missing assignments and many items;
• empty and populated widget areas for classic themes;
• missing featured images and unusually shaped media.

27.3 Classic-theme tests

Verify:

• all required hooks and body classes;
• template hierarchy and fallback behavior;
• the main Loop and pagination;
• Customizer settings, sanitization, preview, persistence and reset;
• editor styles;
• child-theme overrides;
• no duplicate assets or missing files when a child theme is active.

27.4 Block-theme tests

Verify:

• theme.json against the schema appropriate to every supported WordPress version;
• all templates and template parts in the Site Editor;
• no invalid or unavailable blocks;
• Global Styles and every style variation;
• pattern insertion and editing;
• Navigation behavior;
• custom template assignment;
• saving buyer template changes;
• theme updates with database-stored customizations;
• reset and recovery behavior;
• frontend/editor visual consistency.

27.5 Visual, responsive and accessibility tests

Test every major template at mobile, tablet, desktop, zoomed, keyboard-only and RTL states where claimed.

Check:

• overflow, clipping, overlap and layout shift;
• focus order and visibility;
• menu, submenu, modal, tab, accordion, gallery and carousel controls;
• labels, errors, contrast, landmarks and headings;
• reduced motion;
• long translated strings;
• high-content and empty states;
• current supported Chrome, Firefox, Safari and Edge;
• mobile Safari and Chrome.

Automated accessibility tools are useful, but manual keyboard and screen-reader-informed checks are still required for accessibility claims.

27.6 Integration tests

Test every compatibility claim against the actual supported product and version.

For WooCommerce, test the exact classic and block storefront paths described earlier. For page builders, test both editor and frontend behavior. For niche plugins, test real records and user roles rather than static screenshots.

Run starter-content imports on:

• a clean site;
• a site with existing content;
• a repeated import;
• a missing-dependency state;
• a remote-service failure;
• a limited-resource environment.

27.7 Debugging and automated checks

Before submission:

• run the current Theme Check tool;
• run PHP_CodeSniffer with the WordPress Coding Standards;
• run a PHP compatibility ruleset against the declared minimum PHP version;
• lint PHP, JavaScript, CSS, JSON and template files;
• validate theme.json, style variations, block markup and build output;
• check frontend HTML and CSS for substantive errors;
• audit Composer and npm production dependencies;
• scan for credentials, malware indicators, obfuscation, debug artifacts and accidental development files;
• test with WP_DEBUG, WP_DEBUG_LOG and SCRIPT_DEBUG;
• inspect the browser console and network panel;
• check WooCommerce’s template-status report when WooCommerce templates are overridden.

Resolve substantive errors. If a tool result is a genuine false positive or a WordPress.org-only directory policy that does not apply to WPBay, document the reason. Do not disable an entire ruleset to make the report look clean.

Automated visual regression and end-to-end tests are strongly recommended for themes with many templates, variations, builders or integrations.

28. Common approval blockers

The following normally result in Changes required:

• an invalid or incorrectly nested installable ZIP;
• a wrong theme folder, slug, text domain, parent Template or update identity;
• missing required files, readme, license, changelog or screenshot;
• version mismatches;
• incorrect minimum WordPress or PHP requirements;
• fatal errors, warnings, notices, invalid blocks, missing templates or console errors during ordinary use;
• a theme that is blank or severely broken until demo import;
• material visual-quality problems, unfinished templates or a demo that cannot be reproduced;
• a superficial clone, reskin or nearly unchanged starter theme;
• plugin-territory functionality inside the theme;
• companion plugins embedded inside the production theme ZIP;
• demo-import XML, WIE, DAT, plugin archives or development artifacts inside the theme ZIP;
• unavailable, unlicensed, insecure or undisclosed dependencies;
• a required premium builder or plugin not disclosed before purchase;
• unsafe Customizer settings, theme options, AJAX, REST, import, reset or license actions;
• missing capability, nonce, validation, sanitization or output escaping;
• direct SQL, unsafe file handling, SSRF, path traversal, arbitrary code execution or secret exposure;
• first-party source that is obfuscated or only supplied as unreadable build output;
• hidden telemetry, remote fonts without consent, SEO spam, forced credits or undisclosed affiliate behavior;
• copied or improperly licensed images, fonts, icons, layouts, templates or code;
• misleading accessibility, performance, compatibility, legal or feature claims;
• broken mobile navigation, severe responsive overflow, inaccessible primary controls or unreadable contrast;
• malformed theme.json, invalid block serialization, missing template parts or unusable Site Editor behavior;
• outdated WooCommerce templates or unsupported checkout claims;
• a starter-content importer that overwrites existing sites, duplicates content, imports credentials or cannot complete;
• an updater or license form that cannot serve WPBay buyers;
• an update that overwrites child themes, resets customizations, changes identity or loses settings;
• unbounded queries, excessively large assets or performance behavior that makes normal sites impractical.

The following may result in immediate Rejection:

• malware, backdoors, credential theft, remote control or destructive payloads;
• intentionally concealed executable behavior;
• cracked licensing or marketplace purchase-code bypasses;
• stolen themes, copied designs or absent selling rights;
• deliberate deception about the delivered theme, demo, dependencies or assets;
• hidden backlinks, black-hat SEO or spam as a central product behavior;
• an architecture whose central purpose is unsafe or abusive and cannot be corrected through a normal revision;
• repeated attempts to conceal previously identified dangerous behavior.

The following are not normally blockers by themselves:

• a small number of cosmetic PHPCS warnings;
• a modern CSS validation warning that does not indicate broken syntax;
• a focused template set with complete and coherent fallbacks;
• a classic theme that does not provide full-site editing;
• a block theme that does not reproduce classic Customizer controls;
• an optional support such as comment pagination, custom headers, wide alignment, responsive embeds, bundled patterns or editor styles when it is not claimed and its absence does not break the actual design;
• minified third-party assets with clear source and licensing;
• a properly disclosed and obtainable builder dependency;
• dynamic inline CSS generated safely through WordPress;
• a reasonable design recommendation that does not affect usability or advertised quality;
• benign encoding used for a documented data format.

29. Seller pre-submission checklist

Before submitting, confirm all of the following:

• The uploaded theme ZIP is the exact installable production package.
• The outer buyer package keeps the parent theme, child theme, plugins, documentation and demo resources separate.
• The theme ZIP contains no plugin archives, import data, credentials, logs, backups or development artifacts.
• The theme folder, text domain, license slug, parent identity and update identity are stable.
• style.css, readme, changelog, WPBay version, package and updater versions match.
• The minimum and tested WordPress, PHP, WooCommerce, builder and dependency versions are accurate.
• The theme installs and activates on a clean site.
• It remains usable before starter content is imported.
• It fails safely when every required or optional plugin is missing.
• Theme Check and WordPress Coding Standards have been run.
• The final package has been tested under the declared minimum and current environments.
• Classic templates use the required hooks, hierarchy, Loop and core functions.
• Block templates, parts, patterns, style variations and theme.json validate and work in the Site Editor.
• Every Customizer and theme setting has suitable capability, nonce, validation, sanitization and escaping.
• No portable functionality is trapped in the theme.
• Companion plugins are separately packaged, documented, licensed, updated and reviewed as plugins.
• Content survives theme switching.
• Parent updates do not overwrite child themes or reset buyer customizations.
• Frontend output is escaped in its final context.
• Assets are enqueued, scoped, licensed, optimized and free of private development references.
• Fonts are licensed, local by default and limited to used files and weights.
• The theme has been tested with comprehensive WordPress content and edge cases.
• Major templates work at mobile, tablet, desktop, zoomed, keyboard and translated states.
• Primary navigation and controls meet the accessibility baseline.
• RTL behavior works when claimed.
• External services, data transmission, accounts, charges and availability effects are disclosed.
• Telemetry and nonessential remote resources are opt-in.
• Demo assets and starter content are licensed and accurately disclosed.
• Demo import requires explicit action, protects existing content, handles retries and reports failures.
• The live demo matches the sold release and does not expose dangerous administrator capabilities.
• WooCommerce compatibility claims, templates, blocks, cart, checkout, account and responsive states are tested.
• Page-builder requirements, editions, licenses, templates and supported versions are disclosed.
• Licensing and updates work for WPBay buyers.
• No unrelated marketplace purchase code is required.
• Screenshots, description, demo, documentation and the submitted package all describe the same product.
• Every advertised template, variation, integration and editing feature works end to end.

30. Related WPBay guidance

These requirements should be read together with:

• What Makes a Product WPBay-Ready?
• WordPress Themes: Common Rejection Factors
• WPBay Seller Guidelines

Companion plugins are also subject to WPBay’s separate technical requirements for WordPress plugins.

Where an older page contains obsolete browser lists, rigid typography examples or general recommendations, the requirements on this page take precedence for theme review.

31. Official development references

The following primary references are useful when preparing a submission:

• WordPress Theme Handbook
• WordPress Theme Review requirements
• WordPress Theme structure
• Main stylesheet and theme headers
• WordPress Update URI theme header
• WordPress template hierarchy
• Custom theme functionality and plugin territory
• Including theme assets
• Global Settings and Styles with theme.json
• Introduction to theme.json
• Registering theme patterns
• Block theme style variations
• WordPress theme security
• Customizer settings and sanitization
• Theme internationalization
• WordPress child themes
• Writing theme documentation
• Theme testing
• WordPress Theme Unit Test data
• Theme Check
• WordPress Coding Standards
• WordPress Coding Standards for PHP_CodeSniffer
• Accessibility-ready theme requirements
• Validating data
• Sanitizing data
• Escaping data
• WordPress nonces
• WooCommerce theme design guidance
• WooCommerce classic theme development
• WooCommerce template overrides
• Theming WooCommerce blocks
• WooCommerce Cart and Checkout block theming

Final note

WPBay’s goal is not to reject themes for harmless formatting preferences, a particular design fashion or the number of template files. The goal is to prevent buyers from receiving insecure, visually unfinished, misleading, incompatible, inaccessible, locked-in, unmaintainable or legally questionable products.

If an implementation differs from a recommendation but is secure, testable, documented, visually coherent and appropriate for the product, explain that in the submission notes. If a requirement is unclear before submission, contact the WPBay review team.