WordPress Testing Core Procedures

This Skill provides foundational WordPress testing knowledge and procedures for browser automation testing.

WordPress Login Procedure

Standard WordPress Admin Login

URL Pattern: http://localhost:8082/wp-admin (or your WordPress URL + /wp-admin)

Steps:

1. Navigate to WordPress admin URL
2. Take snapshot to see login form state
3. Locate username field (usually ID: user_login)
4. Locate password field (usually ID: user_pass)
5. Fill username: "admin"
6. Fill password: "password"
7. Click submit button (ID: wp-submit)
8. Wait for dashboard to load
9. Verify successful login (look for "Dashboard" in page title or admin bar)

Example Chrome DevTools Flow:

1. navigate_page(url: "http://localhost:8082/wp-admin")
2. take_snapshot() - Verify login form is visible
3. fill(uid: "username-field-uid", value: "admin")
4. fill(uid: "password-field-uid", value: "password")
5. click(uid: "submit-button-uid")
6. wait_for(text: "Dashboard")
7. take_snapshot() - Confirm admin dashboard loaded

Common Issues:

• If WordPress installation screen appears instead of login, WordPress needs setup
• If "Site Health" warnings appear, they can usually be ignored for testing
• If login fails, verify credentials in test.sh script or wp-config.php

Plugin Activation Verification

Via test.sh Script (Recommended for Setup)

Check plugin status:

cd /Users/mikkelfreltoftkrogsholm/Projekter/wp-plugins && ./test.sh plugins

Activate plugin:

cd /Users/mikkelfreltoftkrogsholm/Projekter/wp-plugins && ./test.sh activate [plugin-slug]

Deactivate plugin:

cd /Users/mikkelfreltoftkrogsholm/Projekter/wp-plugins && ./test.sh deactivate [plugin-slug]

Via Browser UI (For Verification)

URL: http://localhost:8082/wp-admin/plugins.php

Steps:

1. Navigate to Plugins page
2. Take snapshot to see plugin list
3. Verify plugin appears in list
4. Check if "Activate" or "Deactivate" link is present
5. If showing "Activate", plugin is inactive
6. If showing "Deactivate", plugin is active

Visual Indicators:

• Active plugins have white/light background
• Inactive plugins have grey background
• Recently activated plugins show notification banner

WordPress Admin Navigation Patterns

Admin Menu Structure

Common Menu Items:

• Dashboard (dashboard)
• Posts (edit.php)
• Media (upload.php)
• Pages (edit.php?post_type=page)
• Comments (edit-comments.php)
• Appearance (themes.php)
• Plugins (plugins.php)
• Users (users.php)
• Tools (tools.php)
• Settings (options-general.php)

Plugin Custom Menus: Plugins typically add menu items in two ways:

1. Top-level menu (appears in main sidebar)
2. Submenu under existing menu (e.g., under Settings)

URL Pattern for Plugin Pages:

/wp-admin/admin.php?page=[plugin-slug]
/wp-admin/admin.php?page=[plugin-slug]-settings

Settings Pages

Common Settings Submenus:

• General (options-general.php)
• Writing (options-writing.php)
• Reading (options-reading.php)
• Discussion (options-discussion.php)
• Media (options-media.php)
• Permalinks (options-permalink.php)
• Plugin settings often appear here

Testing Settings Pages:

1. Navigate to Settings menu
2. Click plugin's settings submenu
3. Verify page loads without errors
4. Check for proper nonce fields in forms
5. Test save functionality (if needed)

WordPress Frontend Patterns

Post/Page Structure

Single Post URL Pattern:

http://localhost:8082/[post-slug]/
http://localhost:8082/?p=[post-id]

Archive/List Pages:

http://localhost:8082/blog/
http://localhost:8082/category/[category-slug]/

Testing Frontend Features:

1. Create test post/page (or use existing)
2. Navigate to post URL
3. Take snapshot to see post content
4. Verify plugin elements appear (buttons, widgets, etc.)
5. Check console for JavaScript errors
6. Test interactions (click buttons, etc.)

Creating Test Content

Via WP-CLI (Fastest):

cd /Users/mikkelfreltoftkrogsholm/Projekter/wp-plugins && ./test.sh wp post create --post_title="Test Post" --post_content="Test content for plugin testing" --post_status=publish

Via Browser:

1. Navigate to Posts > Add New
2. Enter title and content
3. Click Publish button
4. Note the post URL for testing

REST API Testing

WordPress REST API Patterns

Base URL: http://localhost:8082/wp-json/

Common Endpoints:

• Core API: /wp-json/wp/v2/
• Plugin custom endpoints: /wp-json/{namespace}/v1/

Testing REST Endpoints:

Method 1: Using evaluate_script (In Browser)

async () => {
  const response = await fetch('/wp-json/seo-llm/v1/content/1/markdown');
  const data = await response.json();
  return {
    status: response.status,
    ok: response.ok,
    data: data
  };
}

Method 2: Using Bash (Command Line)

curl -s http://localhost:8082/wp-json/seo-llm/v1/content/1/markdown

What to Verify:

• Response status code (200, 404, 401, etc.)
• Response content-type (application/json)
• JSON structure matches expectations
• Error responses have proper format
• Authentication works (if required)

REST API Authentication

Public Endpoints:

• No authentication needed
• Test directly with fetch or curl

Protected Endpoints:

• May require nonce, cookie, or token
• If testing from logged-in browser, cookies should work
• Check plugin documentation for auth requirements

Console Error Checking

Monitoring JavaScript Errors

Get all console messages:

list_console_messages(types: ["error", "warn", "log"])

Filter to errors only:

list_console_messages(types: ["error"])

Common WordPress Console Errors:

• "jQuery is not defined" - jQuery loading issue
• "Uncaught ReferenceError" - Missing JavaScript dependency
• "404 for .js file" - Asset not enqueued or wrong path
• "Uncaught TypeError: Cannot read property" - JavaScript logic error

When to Worry:

• Critical errors preventing functionality
• 404s for plugin assets
• Security warnings
• Multiple repeated errors

When to Ignore:

• Browser extension errors
• Third-party tracking script issues
• Deprecated warnings (if plugin still works)

Network Request Analysis

Checking Asset Loading

List all network requests:

list_network_requests()

Filter to specific resource types:

list_network_requests(resourceTypes: ["script", "stylesheet"])

Common Resource Types:

• script - JavaScript files
• stylesheet - CSS files
• xhr - AJAX requests
• fetch - Fetch API requests
• document - HTML pages

What to Check:

• Plugin assets loaded successfully (200 status)
• No 404s for plugin files
• AJAX requests return expected data
• No excessive requests (performance issue)

Analyzing Failed Requests

Get specific request details:

get_network_request(reqid: [request-id])

Common Failure Patterns:

• 404 Not Found - File doesn't exist or wrong path
• 500 Internal Server Error - PHP error in plugin
• 403 Forbidden - Permission issue
• 0 status - Request blocked or CORS issue

Browser Automation Best Practices

Taking Snapshots

Always snapshot before interactions:

take_snapshot() - See what's on page now
fill(uid: "field-uid", value: "test")
click(uid: "button-uid")
take_snapshot() - See result of interaction

Use verbose mode for debugging:

take_snapshot(verbose: true) - Shows detailed element tree

Save snapshots for documentation:

take_snapshot(filePath: "/path/to/snapshot.txt")

Waiting for Dynamic Content

Wait for specific text to appear:

wait_for(text: "Success", timeout: 5000)

Common wait scenarios:

• After form submission (wait for success message)
• After AJAX request (wait for content to appear)
• After page navigation (wait for new page to load)

Handling Timeouts

Increase timeout for slow operations:

navigate_page(url: "...", timeout: 30000) - 30 seconds

When to use longer timeouts:

• WordPress admin pages can be slow
• First load after Docker start takes longer
• Pages with lots of plugins loading

Common WordPress Testing Patterns

Pattern 1: Verify Admin Menu Item

1. Login to WordPress admin
2. Take snapshot of admin sidebar
3. Look for plugin menu item text
4. Verify menu item is present
5. Click menu item
6. Verify settings page loads

Pattern 2: Test Frontend Button

1. Navigate to published post
2. Take snapshot to see post content
3. Locate plugin button (by text or ID)
4. Take screenshot of button for documentation
5. Click button
6. Verify expected action (modal opens, etc.)
7. Check console for errors

Pattern 3: Test Settings Form

1. Navigate to plugin settings page
2. Take snapshot of form
3. Verify all fields render correctly
4. Fill form fields with test data
5. Click Save button
6. Wait for success message
7. Verify settings were saved (reload page and check)

Pattern 4: Test REST API Endpoint

1. Use evaluate_script to call endpoint
2. Verify response status code
3. Check response data structure
4. Test error cases (invalid ID, etc.)
5. Verify authentication (if required)

WordPress-Specific Element Patterns

Common Element Selectors

Admin Elements:

• Admin bar: ID wpadminbar
• Main menu: ID adminmenu
• Content area: ID wpbody-content
• Submit buttons: class button-primary
• Form tables: class form-table

Frontend Elements:

• Post content: class entry-content
• Post title: class entry-title
• Comments: ID comments
• Sidebar: ID secondary or class sidebar

Forms:

• Nonce fields: input with name ending in _wpnonce
• Submit buttons: type submit
• Settings: wrapped in <table class="form-table">

Debugging WordPress Issues

Check WordPress Debug Log

cd /Users/mikkelfreltoftkrogsholm/Projekter/wp-plugins && ./test.sh debug

Common PHP Errors:

• Fatal error - Plugin code has syntax error or missing file
• Warning - Non-critical issue but should be fixed
• Notice - Minor issue, often undefined variable

Check Docker Logs

cd /Users/mikkelfreltoftkrogsholm/Projekter/wp-plugins && ./test.sh logs

What to look for:

• PHP fatal errors
• MySQL connection issues
• WordPress installation problems
• Apache/Nginx errors

Environment Reset

If WordPress is misbehaving:

cd /Users/mikkelfreltoftkrogsholm/Projekter/wp-plugins && ./test.sh reset
cd /Users/mikkelfreltoftkrogsholm/Projekter/wp-plugins && ./test.sh install-wp

When to reset:

• WordPress won't load
• Database is corrupted
• Plugins conflict with each other
• Need clean slate for testing

Performance Considerations

Page Load Times

Normal load times for testing environment:

• Admin dashboard: 2-5 seconds
• Plugin settings page: 1-3 seconds
• Frontend post: 1-2 seconds

Slow page indicators:

• Over 10 seconds to load
• Multiple slow network requests
• Database query issues

Network Request Volume

Typical request counts:

• Admin page: 20-40 requests
• Frontend page: 10-30 requests
• Settings page: 15-25 requests

Excessive requests:

• Over 100 requests on single page load
• Repeated duplicate requests
• Unnecessary external API calls

Security Verification

Nonce Verification

All WordPress forms should have nonces:

• Look for hidden input with name ending in _wpnonce
• Nonce value should be long random string
• Form submission should verify nonce on server

Capability Checks

Plugin admin pages should check capabilities:

• Only administrators should access plugin settings
• Check if logged-out users can access admin features (they shouldn't)

Input Sanitization

Test with special characters:

• Try: <script>alert('XSS')</script>
• Try: ' OR '1'='1
• Verify plugin sanitizes input (doesn't execute/display raw)

Note: Don't actually try to exploit vulnerabilities, just verify sanitization exists.

Summary

Key WordPress Testing Procedures:

1. Login to admin (user_login, user_pass fields)
2. Navigate using admin menu structure
3. Verify plugin activation status
4. Test both admin and frontend features
5. Monitor console for JavaScript errors
6. Check network requests for failed assets
7. Use test.sh for environment management
8. Create test content for realistic testing
9. Test REST API endpoints with fetch
10. Document with snapshots and screenshots

WordPress URLs to Know:

• Admin: /wp-admin/
• Plugins: /wp-admin/plugins.php
• Settings: /wp-admin/options-general.php
• Add Post: /wp-admin/post-new.php
• REST API: /wp-json/

Common Issues:

• 404 for assets (check asset enqueue)
• JavaScript errors (check dependencies)
• Form submissions fail (check nonces)
• Slow loading (check network requests)
• White screen (check PHP errors in debug.log)