GitHub Copilot para WordPress: plugins, PHP, WooCommerce y debugging con IA

Crea esta funcionalidad
en mi plugin WordPress.

Analyze this WordPress plugin
before changing anything.

Identify:

- plugin entry point
- main classes
- actions and filters
- AJAX handlers
- REST API routes
- database access
- custom tables
- cron jobs
- WooCommerce integration
- frontend JavaScript
- admin JavaScript
- security-sensitive code
- automated tests
- build commands

Explain the architecture
and data flow.

Do not modify files yet.

Implement the following feature.

Goal:
Allow administrators
to export plugin records as CSV.

Requirements:

- add the action
  to the existing admin screen
- only administrators
  with the required capability
  can export
- protect the request
  against CSRF
- do not expose records
  belonging to other sites
  in multisite
- stream the CSV
  instead of storing
  a public file
- preserve current filters
- follow existing project patterns

Before coding:

1. locate the existing admin screen
2. identify the correct capability
3. identify existing export helpers
4. propose a minimal plan

After implementation:

- run syntax checks
- run relevant tests
- inspect the complete diff
- report anything not verified.

.github/
└── copilot-instructions.md

# Project

This repository contains
a WordPress plugin.

Follow existing project architecture
before creating new abstractions.


# WordPress

Prefer public WordPress APIs.

Use actions and filters
instead of modifying core behavior.

Preserve:

- hook names
- shortcode names
- REST routes
- AJAX action names
- public PHP APIs
- database compatibility


# Security

Treat request data
as untrusted.

For state-changing actions:

- verify authentication when required
- verify capabilities
- verify ownership when relevant
- verify nonces where appropriate

Remember:

A nonce is not authorization.

Validate before processing.

Sanitize before storage.

Escape at output.


# Database

Prefer WordPress APIs.

For dynamic SQL
use $wpdb->prepare().

Never concatenate
untrusted values
into SQL.


# REST API

Every custom REST route
must define
permission_callback.

Public endpoints
must be explicitly public.

Protected endpoints
must perform meaningful
authorization checks.


# AJAX

Review:

- wp_ajax_*
- wp_ajax_nopriv_*
- nonce
- capability
- ownership
- input validation
- structured JSON response


# Changes

Avoid unrelated refactors.

Do not change public behavior
unless explicitly requested.


# Verification

Before finishing:

- run PHP syntax checks
- run relevant automated tests
- run lint/static analysis if configured
- inspect git diff
- report anything not verified

Review every AJAX handler
in this plugin.

For each handler inspect:

- action name
- authentication
- nonce
- capability
- object ownership
- expected input types
- validation
- sanitization
- database operations
- output escaping
- wp_send_json_success()
- wp_send_json_error()

Pay special attention
to wp_ajax_nopriv_* handlers.

Report concrete
exploitation scenarios.

Do not change code yet.

function ciborg_delete_record() {

    check_ajax_referer(
        'ciborg_delete_record',
        'nonce'
    );

    if ( ! current_user_can( 'manage_options' ) ) {
        wp_send_json_error(
            array(
                'message' => 'Unauthorized',
            ),
            403
        );
    }

    $record_id = isset( $_POST['record_id'] )
        ? absint( $_POST['record_id'] )
        : 0;

    if ( ! $record_id ) {
        wp_send_json_error(
            array(
                'message' => 'Invalid record',
            ),
            400
        );
    }

    // Perform the authorized operation.

    wp_send_json_success();
}

'permission_callback' => '__return_true'

add_action(
    'rest_api_init',
    function () {

        register_rest_route(
            'ciborg/v1',
            '/settings',
            array(
                'methods'             => 'POST',
                'callback'            => 'ciborg_update_settings',
                'permission_callback' => function () {
                    return current_user_can(
                        'manage_options'
                    );
                },
            )
        );

    }
);

Audit all $wpdb usage.

Find:

- concatenated request data
- dynamic WHERE conditions
- dynamic ORDER BY
- dynamic LIMIT
- LIKE queries
- dynamic identifiers
- direct writes
- missing error handling

Verify whether
$wpdb->prepare()
is used correctly.

Do not assume
sanitize_text_field()
makes arbitrary SQL concatenation safe.

global $wpdb;

$row = $wpdb->get_row(
    $wpdb->prepare(
        "SELECT *
        FROM {$wpdb->prefix}ciborg_records
        WHERE user_id = %d
        AND status = %s",
        $user_id,
        $status
    )
);

Input
↓
Validate
↓
Sanitize / Normalize
↓
Store / Process
↓
Escape for output context

Perform a security review
of this WordPress plugin.

Map the attack surface first.

Inspect:

- admin-post handlers
- admin-ajax handlers
- unauthenticated AJAX
- REST routes
- shortcodes
- file uploads
- file downloads
- cron handlers
- forms
- database writes
- redirects
- external requests

Check for:

- missing capability checks
- missing ownership checks
- CSRF
- SQL injection
- reflected XSS
- stored XSS
- unsafe redirects
- arbitrary file access
- insecure uploads
- path traversal
- secret exposure
- privilege escalation
- information disclosure

For every finding include:

- severity
- affected file
- attacker requirement
- vulnerable flow
- realistic impact
- recommended fix

Do not modify code yet.

.github/
└── skills/
    └── wordpress-security/
        │
        ├── SKILL.md
        ├── checklist.md
        └── examples/

---
name: wordpress-security
description: Review WordPress plugins for authentication, authorization, nonce, CSRF, SQL injection, XSS, REST API, AJAX, file handling, and privilege escalation issues.
---

# WordPress Security Review

## Attack surface

Locate:

- wp_ajax_*
- wp_ajax_nopriv_*
- register_rest_route()
- admin_post_*
- shortcodes
- file operations
- database writes
- redirects

## Authorization

For state-changing actions:

- identify the actor
- identify the resource
- verify capability
- verify ownership when needed

Nonce alone
does not establish authorization.

## Input

Validate expected:

- type
- range
- format
- allowed values

Sanitize before storage.

## Output

Escape at output.

## Database

Use WordPress APIs.

For dynamic SQL,
use $wpdb->prepare().

## Findings

Only report
concrete security issues
with a realistic attack path.

Investigate this WordPress bug.

Do not modify code yet.

First:

1. reproduce the failure
2. identify the exact request
3. inspect PHP errors
4. inspect browser console
5. inspect network response
6. trace the handler
7. identify the first incorrect state

Then explain:

- root cause
- evidence
- affected code
- smallest safe fix
- regression test required

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

define( 'WP_DEBUG_DISPLAY', false );

Read only the relevant
debug.log entries
for this failure.

Correlate timestamps
with the failing request.

Do not treat warnings
unrelated to this request
as the root cause.

wp plugin list

wp theme list

wp option get OPTION_NAME

wp cron event list

wp db query "..."

wp cache flush

$order = wc_get_order( $order_id );

if ( ! $order ) {
    return;
}

$order->update_meta_data(
    '_ciborg_reference',
    $reference
);

$order->save();

Audit this WooCommerce extension
for HPOS compatibility.

Find every place
that reads or writes
order data.

Flag:

- direct wp_posts access
- direct wp_postmeta access
  for order data
- get_post_meta() on orders
- update_post_meta() on orders
- WP_Query used for order storage
- SQL tied to legacy order tables
- internal WooCommerce classes

Prefer:

- wc_get_order()
- wc_get_orders()
- WC_Order getters
- WC_Order setters
- WooCommerce CRUD APIs
- supported public hooks

Do not refactor unrelated code.

Return:

- incompatible location
- reason
- HPOS-safe alternative
- migration risk

Audit this extension
for dependencies
on WooCommerce internals.

Find:

- Automattic\WooCommerce\Internal\*
- @internal methods
- undocumented properties
- direct assumptions
  about WooCommerce storage

For every match:

- explain the risk
- find a public alternative
- preserve current behavior.

Review this WordPress pull request.

Prioritize:

- behavioral regressions
- capability checks
- object ownership
- nonce usage
- REST permission_callback
- AJAX security
- SQL injection
- XSS
- unsafe redirects
- WooCommerce public API usage
- HPOS compatibility
- backwards compatibility
- missing regression tests

Ignore:

- purely cosmetic formatting
- issues already enforced
  by PHPCS
- speculative concerns
  without a realistic failure path

For each finding include:

- severity
- file
- concrete failure scenario
- impact
- smallest safe fix

vendor/bin/phpcs .

find . -name "*.php" \
  -not -path "./vendor/*" \
  -print0 \
  | xargs -0 -n1 php -l

Before fixing this bug,
write the smallest regression test
that reproduces it.

Requirements:

- test observable behavior
- do not test private implementation details
- make the test fail before the fix
- apply the fix
- prove the test passes afterward
- run related tests

Do not weaken
an existing assertion
to make the suite pass.

Investigate this WordPress frontend bug.

Check:

- enqueue dependencies
- script loading order
- localized data
- AJAX URL
- REST URL
- nonce
- event listeners
- duplicate initialization
- browser console
- network response
- DOM state
- responsive layout

Do not guess the root cause.

Collect evidence first.

GitHub MCP
│
├── Issue
├── Pull Request
└── Actions


Playwright MCP
│
├── Open site
├── Click
├── Fill form
└── Verify UI


Copilot
↓
Issue → Code → Browser verification

Implement issue #128.

First use GitHub MCP
to read:

- issue description
- comments
- linked pull requests

Then:

1. inspect the affected WordPress plugin
2. identify the root cause
3. propose a minimal plan
4. implement the fix
5. add a regression test
6. run relevant tests
7. run PHP syntax checks

Finally use Playwright
to verify the affected workflow.

Do not:

- merge
- deploy
- close the issue
- modify production data

Return:

- root cause
- files changed
- verification performed
- anything not verified.

Fix the WooCommerce order export bug.

Acceptance criteria:

- exports all filtered orders
- HPOS compatible
- uses WooCommerce CRUD APIs
- administrators only
- nonce protected
- no direct order-table SQL
- does not break existing CSV format
- regression test included

Run relevant tests.

Open a pull request
with a concise explanation
of the root cause
and the fix.

Design a safe migration plan.

Do not execute it.

Document:

- current schema
- target schema
- data volume assumptions
- backwards compatibility
- upgrade path
- rollback strategy
- idempotency
- batching requirements
- locking risks
- timeout risks
- multisite impact

Only after the plan
is reviewed
should implementation begin.

Audit this plugin's scheduled jobs.

Find:

- wp_schedule_event()
- wp_schedule_single_event()
- cron hooks
- duplicate scheduling
- missing unscheduling
- long-running callbacks
- network requests
- retries
- idempotency
- database writes

Verify activation,
deactivation
and uninstall behavior.

Review this plugin
for performance problems.

Look for:

- database queries in loops
- repeated identical queries
- autoloaded large options
- remote requests during page render
- uncached expensive calculations
- loading scripts globally
- loading admin assets on every screen
- inefficient WooCommerce queries
- unbounded result sets
- expensive work on init
- synchronous work
  that could be deferred

For every finding,
estimate when it becomes significant.

Review the plugin UI
for accessibility.

Check:

- semantic elements
- form labels
- keyboard interaction
- focus management
- aria-expanded
- aria-controls
- modal focus
- status messages
- color-independent states
- button vs link semantics

Do not add ARIA
when native HTML
already provides
the correct semantics.

Prepare this WordPress plugin
for release.

Do not publish anything.

Check:

- git working tree
- version consistency
- plugin header
- changelog
- PHP syntax
- automated tests
- PHPCS
- built assets
- missing development files
- accidental secrets
- debug statements
- backwards compatibility
- database migration safety
- WordPress compatibility
- WooCommerce compatibility
- HPOS compatibility if applicable

Return a release checklist.

Do not deploy.

Work on this WordPress plugin.

Goal:
[DESCRIBE THE FEATURE OR BUG]

Before modifying code:

1. inspect the relevant architecture
2. locate similar existing patterns
3. identify hooks and public interfaces
4. identify security boundaries
5. identify tests
6. propose the smallest safe plan

Implementation rules:

- follow existing architecture
- use public WordPress APIs
- avoid unrelated refactors
- preserve hooks and public behavior
- validate external input
- sanitize before storage
- escape at output
- verify capabilities
- verify ownership when relevant
- use nonces where appropriate
- use $wpdb->prepare() for dynamic SQL
- define meaningful REST permission_callback
- use WooCommerce public CRUD APIs
- preserve HPOS compatibility

Testing:

- reproduce the bug first when possible
- add regression coverage
- run relevant tests
- run PHP syntax checks
- run lint/static analysis if configured

Final review:

- inspect complete git diff
- check security-sensitive paths
- check backwards compatibility

Return:

- root cause or design rationale
- files changed
- tests executed
- verification result
- anything not verified.