Add a new Plugin Check rule to detect potential trialware or locked built-in functionality in plugins submitted to WordPress.org.
Problem
Plugins hosted on WordPress.org must be fully functional. Some plugins include functionality in the submitted codebase but restrict access to it behind license keys, trials, payment checks, quotas, “pro” plan gates, or similar artificial limits. These cases are difficult to catch reliably with static checks alone and benefit from AI-assisted review.
Proposed Solution
Add a new trialware check under the plugin_repo category.
The check should:
- Scan code-like files for trialware and locked-feature indicators.
- Detect phrases and identifiers such as license keys, free trial limits, pro/premium access gates, quota limits, “unlock” messaging, and similar patterns.
- Report findings as AI-review candidates rather than immediately final violations.
- Use AI analysis to confirm whether the candidate is a genuine issue or a false positive.
- Promote AI-confirmed candidates to errors.
- Remove or hide unconfirmed/false-positive candidates from the final result output.
Expected Behavior
When a plugin contains code that restricts built-in functionality behind a license, trial, quota, or payment gate, Plugin Check should report a confirmed trialware issue.
When a plugin only references a separate premium product, external service, or harmless license/update wording without locking bundled functionality, Plugin Check should avoid reporting it as a final issue.
Implementation Notes
- Add a new
Trialware_Check class under includes/Checker/Checks/Plugin_Repo/.
- Register it in
Default_Check_Repository with the slug trialware.
- Add an AI prompt for reviewing trialware candidates.
- Add candidate and confirmed result codes, for example:
trialware_locked_feature_candidate
trialware_locked_feature_detected
- Add PHPUnit coverage for plugins with and without trialware-like patterns.
- Document the new check in
docs/checks.md.
Acceptance Criteria
trialware appears in the available checks list.
- Candidate patterns are detected from PHP/JS-style plugin files.
- AI-confirmed candidates become errors.
- AI false positives do not appear as final blocking issues.
- PHPUnit coverage exists for positive and negative fixtures.
composer lint, composer phpstan, and composer phpmd pass.
Add a new Plugin Check rule to detect potential trialware or locked built-in functionality in plugins submitted to WordPress.org.
Problem
Plugins hosted on WordPress.org must be fully functional. Some plugins include functionality in the submitted codebase but restrict access to it behind license keys, trials, payment checks, quotas, “pro” plan gates, or similar artificial limits. These cases are difficult to catch reliably with static checks alone and benefit from AI-assisted review.
Proposed Solution
Add a new
trialwarecheck under theplugin_repocategory.The check should:
Expected Behavior
When a plugin contains code that restricts built-in functionality behind a license, trial, quota, or payment gate, Plugin Check should report a confirmed trialware issue.
When a plugin only references a separate premium product, external service, or harmless license/update wording without locking bundled functionality, Plugin Check should avoid reporting it as a final issue.
Implementation Notes
Trialware_Checkclass underincludes/Checker/Checks/Plugin_Repo/.Default_Check_Repositorywith the slugtrialware.trialware_locked_feature_candidatetrialware_locked_feature_detecteddocs/checks.md.Acceptance Criteria
trialwareappears in the available checks list.composer lint,composer phpstan, andcomposer phpmdpass.