Skip to content

Commit 0143be2

Browse files
shftlvchshftlvch
committed
Merge branch 'add-review-and-ai'
2 parents dddeb61 + 273f3d2 commit 0143be2

4 files changed

Lines changed: 287 additions & 0 deletions

File tree

‎.github/workflows/opencode-review.yml‎

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
name: opencode-review
2+
3+
on:
4+
pull_request_target:
5+
types: [opened, synchronize, reopened, ready_for_review]
6+
7+
concurrency:
8+
group: opencode-review-${{ github.event.pull_request.number }}
9+
cancel-in-progress: true
10+
11+
jobs:
12+
review:
13+
if: github.event.pull_request.draft == false
14+
runs-on: ubuntu-latest
15+
permissions:
16+
id-token: write
17+
contents: read
18+
pull-requests: write
19+
issues: read
20+
steps:
21+
- name: Checkout repository
22+
uses: actions/checkout@v6
23+
with:
24+
ref: ${{ github.event.pull_request.head.sha }}
25+
fetch-depth: 0
26+
persist-credentials: false
27+
28+
- name: Run OpenCode Review
29+
uses: anomalyco/opencode/github@latest
30+
timeout-minutes: 20
31+
env:
32+
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
33+
with:
34+
model: openai/gpt-5.4
35+
prompt: |
36+
You are reviewing a pull request for the `wordpress-plugins` repository.
37+
Focus on correctness, regressions, security, and repository-specific conventions.
38+
Do not nitpick formatting or suggest broad rewrites that are unrelated to the diff.
39+
40+
## Repo Context
41+
- The repo contains two classic WordPress plugins:
42+
- `anytrack-affiliate-link-manager/trunk`
43+
- `anytrack-for-woocommerce/trunk`
44+
- Plugins use WordPress.org SVN-style layout: `trunk/` for code, `assets/` for wp.org assets.
45+
- Architecture is legacy WordPress PHP: procedural functions, small bootstrap classes, `include`-based module loading, hooks, AJAX actions, and direct use of WordPress/WooCommerce APIs.
46+
- Admin UI is often assembled as concatenated HTML strings in PHP helper classes.
47+
- JavaScript is plain jQuery enqueued via WordPress; there is no React, TypeScript, bundler, or modern frontend build.
48+
- There is no Composer, PHPUnit, ESLint, or package-based build/test pipeline in this repo.
49+
50+
## Repo Conventions To Enforce
51+
- Prefer minimal changes that fit the current plugin architecture; avoid broad modernization unless the diff explicitly calls for it.
52+
- Follow existing prefixes and naming:
53+
- `anytrack_for_woocommerce_*` for WooCommerce plugin functions
54+
- `aalm_*` for Affiliate Link Manager functions
55+
- New modules should be wired through the plugin bootstrap include list rather than through autoloading.
56+
- Prefer WordPress and WooCommerce APIs over raw PHP when an equivalent helper already exists.
57+
- Match the touched file's existing formatting style; do not flag minor spacing or brace inconsistencies unless they cause a real bug.
58+
59+
## Review Priorities
60+
- Start with real behavioral regressions, data loss risks, access-control mistakes, security issues, and broken WordPress/WooCommerce hooks.
61+
- Be especially careful in redirect logic, AJAX handlers, order hooks, settings save handlers, and admin delete flows.
62+
- Check nonce validation, capability checks, sanitization of `$_POST` / `$_GET`, escaping of rendered output, and safe redirects.
63+
- Watch for misuse of WooCommerce objects and getters, incorrect hook signatures, duplicate tracking, and changes that can fire on the wrong page or multiple times.
64+
- Flag unsafe direct superglobal usage, missing `isset` guards, and broken assumptions around options, post meta, cookies, and request payloads.
65+
- Do not suggest adding frameworks, dependency injection, namespaces, or type-heavy refactors unless the PR is already moving in that direction.
66+
67+
## Testing Expectations
68+
- There is no automated test suite in this repo, so do not require PHPUnit or JS tests that do not exist.
69+
- Prefer validation suggestions that match the repo:
70+
- `php -l` for changed PHP files
71+
- narrow manual verification in a local WordPress or WooCommerce flow
72+
- `bash generate-zips.sh` when packaging behavior is affected
73+
- If the diff changes runtime behavior but lacks any realistic validation path, mention that as residual risk.
74+
75+
## Review Output Format
76+
- Report only actual findings from the diff. Do not praise the PR or restate the implementation.
77+
- Order findings by severity and include file or symbol references plus concise reasoning and impact.
78+
- Use this structure:
79+
1. 🚨 **Critical** - Must fix before merge (security, data loss, breaking changes)
80+
2. ⚠️ **Major** - Should be addressed (bugs, performance, best practices)
81+
3. 💡 **Minor** - Suggestions for improvement, very short description is enough
82+
- If there are no findings, say that explicitly and mention any residual risk or missing validation.
83+
- Append each finding with: *Re-check this finding against the exact changed lines and fix it only if the issue is confirmed in the diff.*
84+
- Only report actual issues from the diff. Do not invent findings about missing build, typecheck, or linter steps that this repo does not have.

‎.github/workflows/opencode.yml‎

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
name: opencode
2+
3+
on:
4+
issue_comment:
5+
types: [created]
6+
pull_request_review_comment:
7+
types: [created]
8+
9+
jobs:
10+
opencode:
11+
if: |
12+
contains(github.event.comment.body, ' /oc') ||
13+
startsWith(github.event.comment.body, '/oc') ||
14+
contains(github.event.comment.body, ' /opencode') ||
15+
startsWith(github.event.comment.body, '/opencode')
16+
runs-on: ubuntu-latest
17+
permissions:
18+
id-token: write
19+
contents: read
20+
pull-requests: read
21+
issues: read
22+
steps:
23+
- name: Checkout repository
24+
uses: actions/checkout@v6
25+
with:
26+
persist-credentials: false
27+
28+
- name: Run opencode
29+
uses: anomalyco/opencode/github@latest
30+
timeout-minutes: 30
31+
env:
32+
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
33+
with:
34+
model: openai/gpt-5.4

‎.vscode/settings.json‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
{}

‎AGENTS.md‎

Lines changed: 168 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,168 @@
1+
# AGENTS.md
2+
3+
This file gives coding agents a practical map of the `wordpress-plugins` repo.
4+
It reflects the current repository, not generic WordPress advice.
5+
6+
## Scope
7+
8+
- Repo root contains two WordPress plugins plus release helpers.
9+
- Main plugin paths:
10+
- `anytrack-affiliate-link-manager/trunk`
11+
- `anytrack-for-woocommerce/trunk`
12+
- Each plugin uses WordPress.org SVN-style layout: `trunk/` for code, `assets/` for wp.org assets.
13+
- There is no root package manager or PHP toolchain config: no `package.json`, `composer.json`, PHPUnit config, ESLint config, or PHPCS config in the repo.
14+
15+
## Rule Files
16+
17+
- No `.cursor/rules/` directory was found.
18+
- No `.cursorrules` file was found.
19+
- No `.github/copilot-instructions.md` file was found.
20+
- There are no repo-specific Cursor or Copilot rule files to merge into agent behavior.
21+
- `.github/workflows/opencode-review.yml` exists, but its prompt references an unrelated AnyTrack Nx monorepo; treat it as stale and not authoritative for this repo.
22+
23+
## Repository Layout
24+
25+
- `README.md` documents local development and release at a high level.
26+
- `generate-zips.sh` packages both plugins into `releases/`.
27+
- `release.sh <pluginName> <version>` publishes a plugin to WordPress SVN.
28+
- `scripts/copy-to-trafficker.sh` and `scripts/copy-from-trafficker.sh` sync code to/from a local DevKinsta WordPress install.
29+
- `svn/` is a temporary checkout target used by `release.sh`.
30+
31+
## Architecture
32+
33+
- Both plugins are classic procedural WordPress plugins with a small bootstrap class in the main plugin file.
34+
- Most behavior lives in `modules/*.php` files included from the plugin entrypoint.
35+
- WordPress hooks are the primary composition mechanism: `add_action`, `add_filter`, AJAX actions, and activation hooks.
36+
- Admin UI is largely rendered as concatenated HTML strings in PHP helper classes.
37+
- JavaScript is plain jQuery enqueued via `wp_register_script` / `wp_enqueue_script`.
38+
- There are no namespaces, Composer autoloading, dependency injection containers, or modern typed PHP patterns.
39+
40+
## Build, Lint, And Test Commands
41+
42+
There is no compile step, dependency install step, or formal build pipeline.
43+
44+
- Package both plugins:
45+
- `bash generate-zips.sh`
46+
- Release to WordPress SVN:
47+
- `bash release.sh anytrack-for-woocommerce 1.5.7`
48+
- `bash release.sh anytrack-affiliate-link-manager 1.5.5`
49+
- Sync repo -> local DevKinsta install:
50+
- `bash scripts/copy-to-trafficker.sh`
51+
- Sync local DevKinsta install -> repo:
52+
- `bash scripts/copy-from-trafficker.sh`
53+
54+
There is no configured lint runner. Use syntax checks instead:
55+
56+
- Lint one PHP file:
57+
- `php -l anytrack-for-woocommerce/trunk/modules/hooks.php`
58+
- Lint all PHP files in one plugin:
59+
- `rg --files anytrack-for-woocommerce/trunk -g '*.php' | xargs -I{} php -l "{}"`
60+
- `rg --files anytrack-affiliate-link-manager/trunk -g '*.php' | xargs -I{} php -l "{}"`
61+
- Optional manual style check if `phpcs` happens to be installed globally:
62+
- `phpcs --standard=WordPress anytrack-for-woocommerce/trunk`
63+
64+
There is no automated test suite checked in:
65+
66+
- No PHPUnit setup was found.
67+
- No WordPress test scaffold was found.
68+
- No JS unit test runner was found.
69+
70+
## Single-Test Guidance
71+
72+
There is no true "run one test" command in this repo.
73+
Closest equivalents:
74+
75+
- Single-file syntax check:
76+
- `php -l anytrack-affiliate-link-manager/trunk/modules/ajax.php`
77+
- Single behavior manual test in local WordPress:
78+
- redirect flow: create or edit one `custom_redirect` item and visit the source URL
79+
- WooCommerce flow: run one product view, add-to-cart, checkout, or thank-you scenario
80+
- Single plugin smoke test:
81+
- activate only the touched plugin in a local WordPress instance and verify the affected admin/front flow
82+
- Packaging smoke test:
83+
- `bash generate-zips.sh`
84+
85+
## Local Development Expectations
86+
87+
- The repo expects development against a real WordPress instance, not mocks.
88+
- DevKinsta paths are hardcoded in the sync scripts.
89+
- README mentions staging/production Kinsta sync as a possible workflow, but agents should avoid remote or destructive actions unless explicitly asked.
90+
- There is no repo-local cache or asset build to clear; changed plugin files take effect immediately in the target WordPress install.
91+
92+
## PHP Style Guidelines
93+
94+
- Follow the style already used in the file you touch; do not normalize the whole plugin.
95+
- New entry files should start with `<?php` and guard direct access with an `ABSPATH` check.
96+
- Keep one top-level responsibility per module file: hooks, AJAX handlers, settings, helper functions, scripts, CPT definitions.
97+
- Prefer WordPress APIs over raw PHP when an equivalent helper already exists.
98+
- Avoid introducing namespaces, traits, autoloaders, Composer-only patterns, or inconsistent scalar type hints / return types.
99+
100+
## Includes, Naming, And Structure
101+
102+
- There are no modern imports; plugin files are wired together with `include` from the main bootstrap file.
103+
- When adding a module, add it to the include list in the plugin entrypoint and keep paths relative to the plugin root.
104+
- Match existing prefixes:
105+
- `anytrack_for_woocommerce_*` for WooCommerce plugin functions
106+
- `aalm_*` for Affiliate Link Manager functions
107+
- legacy class names like `aalmFormElementsClass` are normal here
108+
- Keep option keys and meta keys in snake_case, matching existing names such as `waap_options`, `source_url`, and `_anytrack_processed`.
109+
- Avoid generic global function names that could collide with WordPress or another plugin.
110+
111+
## Formatting Conventions
112+
113+
- Indentation is inconsistent across the repo; some files use tabs, some spaces.
114+
- Preserve the dominant indentation and brace style of the file you edit.
115+
- Keep array syntax aligned with the local file; both `[]` and `array()` exist.
116+
- Avoid broad formatting-only diffs.
117+
- Keep edits surgical; these plugins are heavily hook-driven and run in live WordPress flows.
118+
119+
## Types And Data Handling
120+
121+
- Expect loose arrays and scalar strings from WordPress APIs, `$_POST`, `$_GET`, options, post meta, cookies, and WooCommerce objects.
122+
- Guard optional values with `isset` before use.
123+
- Cast IDs and counters explicitly when needed with `(int)` or `intval()`.
124+
- Prefer simple arrays and booleans over introducing DTOs or new abstraction layers.
125+
- When building payloads, append keys incrementally in the same style as nearby code.
126+
127+
## Error Handling And Security
128+
129+
- Sanitize request data before saving or sending it.
130+
- Escape output when inserting dynamic values into HTML, attributes, or URLs.
131+
- For AJAX and forms, use `check_ajax_referer` or `wp_verify_nonce`.
132+
- For privileged admin actions, check capabilities with `current_user_can`.
133+
- Prefer early returns or `wp_die` for invalid state, failed auth, or bad input.
134+
- Use `is_wp_error` when inspecting WordPress HTTP results.
135+
- Preserve existing redirect semantics such as `wp_redirect(..., 302)` unless requirements change.
136+
- Be careful with superglobals: many handlers read `$_POST` and `$_GET` directly, so tighten validation rather than expanding unsafe access.
137+
138+
## WordPress, WooCommerce, And JS Conventions
139+
140+
- Prefer hook-based extensions over editing unrelated control flow.
141+
- Use `get_option`, `update_option`, `get_post_meta`, and `update_post_meta` for persistence.
142+
- For WooCommerce data, prefer getters such as `$order->get_total()` and `wc_get_product()`.
143+
- Keep plugin textdomain usage aligned with the plugin-local prefix already used in each file.
144+
- Reuse localized script globals already present in the repo, especially `aalm_local_data` and `wpafw_local_data`.
145+
- JavaScript should stay as plain jQuery wrapped in `jQuery(document).ready(function($){ ... })`.
146+
- Do not introduce React, TypeScript, ESM modules, bundlers, or new frontend dependencies unless explicitly requested.
147+
148+
## HTML/Admin UI Conventions
149+
150+
- Many admin screens are intentionally built by concatenating HTML strings in PHP classes.
151+
- Preserve that legacy approach unless the task explicitly calls for a UI rewrite.
152+
- Escape dynamic visible text and attribute values.
153+
- Reuse the existing Bootstrap-like utility classes already shipped with plugin assets instead of adding a new CSS framework.
154+
155+
## Agent Working Rules
156+
157+
- Before claiming a command exists, verify it from repository files.
158+
- Do not invent Composer, NPM, PHPUnit, ESLint, or CI workflows that are not present.
159+
- If asked to "run tests", explain that validation is manual/syntax-based unless you also add a test harness.
160+
- Avoid broad modernization; prefer minimal changes that fit the current plugin architecture.
161+
- Be especially careful in redirect, AJAX, order-hook, and admin-delete code paths; validate nonce, capabilities, sanitization, and redirect targets.
162+
163+
## Good Final Verification Checklist
164+
165+
- Run `php -l` on every changed PHP file.
166+
- If packaging changed, run `bash generate-zips.sh`.
167+
- If WordPress behavior changed, verify the exact affected admin/frontend flow in a local WordPress install.
168+
- If WooCommerce behavior changed, test the narrowest affected scenario: product view, add to cart, checkout, thank-you page, or order update.

0 commit comments

Comments
 (0)