{"owner":"wpscanteam","repo":"wpscan","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance to AI coding agents when working with code in this repository.\n\n## Project Overview\n\nWPScan is a WordPress security scanner written in Ruby. It provides WordPress-specific scanning capabilities including vulnerability detection, enumeration, and password attacks.\n\n**Key characteristics:**\n- Ruby gem with CLI tool\n- Architecture based on Controllers, Finders, and Models (MVC-like pattern)\n- Uses local database (in `$XDG_CACHE_HOME/wpscan/db` or `~/.cache/wpscan/db`, or `~/.wpscan/db` for existing installations) that syncs with WPScan API\n- Scanner framework lives in `lib/wpscan/` (Target, Browser, Controller::Base, Scan, Finders, Formatter, etc.) alongside the WordPress-specific code\n- Supports WordPress-specific security scanning features\n\n## Development Best Practices\n\n### Code Style\n- **Always run rubocop after making changes** to ensure code style compliance\n- Run `bundle exec rubocop -a` to auto-fix issues\n- For specific files: `bundle exec rubocop -a file1.rb file2.rb`\n- The project uses RuboCop for Ruby style enforcement\n\n## Development Commands\n\n### Setup\n```bash\nbundle install\n```\n\n### Running Tests\n```bash\n# Run all tests except slow ones (default for PRs)\nbundle exec rspec --tag ~slow\n\n# Run full test suite (includes slow tests, only runs on master)\nbundle exec rspec\n\n# Run specific test file\nbundle exec rspec spec/path/to/file_spec.rb\n\n# Run with coverage\nbundle exec rspec  # Coverage enabled by default via .simplecov\n```\n\n### Code Quality\n```bash\n# Run rubocop\nbundle exec rubocop\n\n# Auto-fix rubocop issues\nbundle exec rubocop -a\n\n# IMPORTANT: Always run rubocop after making code changes\n# Run on specific files being modified:\nbundle exec rubocop -a path/to/file1.rb path/to/file2.rb\n```\n\n### Building\n```bash\n# Build the gem (runs rubocop & rspec automatically)\nbundle exec rake build\n\n# Install gem locally\ngem install pkg/wpscan-*.gem\n```\n\n### Running WPScan Locally\n```bash\n# From source (outside git repo to avoid load path conflicts)\nruby -Ilib bin/wpscan --url https://example.com\n\n# Or after installing as gem\nwpscan --url https://example.com\n```\n\n### Database Operations\n```bash\n# Update local database\nwpscan --update\n\n# The database is stored in $XDG_CACHE_HOME/wpscan/db or ~/.cache/wpscan/db (new installations)\n# or ~/.wpscan/db (existing installations)\n```\n\n## Architecture\n\n### Core Components\n\n**Entry Point:**\n- `bin/wpscan` - CLI executable that chains controllers together\n- Controllers are chained using `<<` operator and executed in order\n\n**Controllers (app/controllers/):**\nControllers orchestrate the scanning process. The `Core` controller (app/controllers/core.rb) is implicitly handled by the scanner framework via `WPScan::Scan.new` and runs before the explicitly chained controllers. The explicit chain in bin/wpscan executes in this order:\n1. `VulnApi` - API token setup for vulnerability data\n2. `CustomDirectories` - Custom wp-content/plugins directory detection\n3. `InterestingFindings` - Header analysis, robots.txt, readme files\n4. `WpVersion` - WordPress version detection\n5. `MainTheme` - Active theme detection\n6. `Enumeration` - Plugins, themes, users, etc (see CLI options)\n7. `PasswordAttack` - Brute force attacks\n8. `Aliases` - Handle legacy CLI options\n\nNote: The `Core` controller handles database updates, WordPress detection, and banner display during the `before_scan` phase.\n\n**Finders (app/finders/):**\nFinders implement detection strategies for various WordPress components. Each finder type has multiple strategies (passive, aggressive, mixed):\n- `WpVersion` - Detects WordPress version\n- `MainTheme` - Detects active theme\n- `Plugins` - Plugin enumeration strategies\n- `Themes` - Theme enumeration strategies\n- `Users` - User enumeration (author ID brute forcing, API endpoints, etc)\n- `InterestingFindings` - Backup files, debug logs, etc\n- `ConfigBackups` - Config backup file detection (wp-config.php backups)\n- `DbExports` - Database export file detection\n- `Medias` - Media/attachment enumeration via brute forcing\n- `Timthumbs` - Timthumb script detection at known locations\n- `Passwords` - Authentication mechanisms (wp-login, XML-RPC)\n\n**Models (app/models/):**\nDomain objects representing WordPress components:\n- `WpItem` - Base class for plugins/themes\n- `Plugin`, `Theme` - Specific WordPress items\n- `WpVersion` - WordPress version with vulnerability info\n- `InterestingFinding` - Security-relevant findings\n- `ConfigBackup` - Detected wp-config.php backup files\n- `DbExport` - Detected database export files\n- `Media` - Media attachments found on the site\n- `Timthumb` - Timthumb script instances\n- `XMLRPC` - XML-RPC interface details\n\n**Database (lib/wpscan/db/):**\n- `Updater` - Syncs local database with WPScan API\n- `VulnApi` - API client for vulnerability data\n- `DynamicFinders` - Auto-generated finders from database metadata\n- `Fingerprints` - Version detection fingerprints\n- Database stored in `$XDG_CACHE_HOME/wpscan/db/` or `~/.cache/wpscan/db/` (new installations) or `~/.wpscan/db/` (existing installations) by default (overridden in specs to `spec/fixtures/db/`)\n\n### Important Patterns\n\n**Scanner framework:**\nThe scanner framework lives under `WPScan::` alongside the WordPress-specific code. Core framework classes — `WPScan::Target`, `WPScan::Browser`, `WPScan::Controller::{Base,Core}`, `WPScan::ParsedCli`, `WPScan::Vulnerability`, `WPScan::Model::{InterestingFinding,XMLRPC}`, etc. — are single unified classes, not split across framework/WordPress layers. WordPress-specific behavior is mixed in via modules (e.g. `WPScan::Target::Platform::WordPress` is included into `WPScan::Target`). Option parsing delegates to the external `opt_parse_validator` gem.\n\n**Dynamic Finders:**\nFinders can be dynamically generated from database metadata (see `lib/wpscan/db/dynamic_finders/`). This allows version detection strategies to be data-driven.\n\n**Slug Classification:**\nWordPress slugs (plugin/theme names) are converted to Ruby class names via `classify_slug` helper (lib/wpscan/helper.rb). Handles edge cases:\n- Slugs starting with digits get prefixed with `D_` (e.g., `123-plugin` becomes `D_123Plugin`)\n- Special characters are converted to underscores\n- Slugs with all non-latin characters become `HexSlug_` followed by hex-encoded bytes\n\n**API Requests Tracking:**\nThe codebase tracks API requests via `WPScan.api_requests` class variable to monitor usage against API limits.\n\n## Testing\n\n### Test Structure\n- Tests use RSpec with WebMock for HTTP stubbing\n- Fixtures in `spec/fixtures/`\n- Shared examples in `spec/shared_examples/`\n- Coverage via SimpleCov (configured in `.simplecov`)\n\n### Key Testing Helpers (spec/spec_helper.rb)\n- `rspec_parsed_options(args)` - Parse CLI arguments\n- `df_expected_all` - Dynamic finder test expectations\n- `vuln_api_data_for(path)` - Load vulnerability API fixtures\n- `redefine_constant(constant, value)` - Override WPScan constants for testing\n\n### Test Tags\n- `--tag ~slow` - Excludes slow tests (default for CI on PRs)\n- Full suite runs only on master pushes\n\n## Common Gotchas\n\n**Active Support Must Be First:**\n`active_support/all` must be required before other gems to avoid encoding issues with JSON (see lib/wpscan.rb:4-6).\n\n**Running Outside Git Repo:**\nWhen using `wpscan` from source, run it outside the git repo to avoid load path conflicts.\n\n**Database Location:**\nTests override `DB_DIR` to `spec/fixtures/db/`. Production uses `$XDG_CACHE_HOME/wpscan/db` or `~/.cache/wpscan/db` (new installations) or `~/.wpscan/db` (existing installations).\n\n**Port Normalization:**\nWebMock adapter has custom port normalization for Typhoeus (spec/spec_helper.rb:63-96) to handle default ports.\n\n## API Integration\n\n**WPScan API:**\n- Requires API token (via `--api-token` or `WPSCAN_API_TOKEN` env var or config file)\n- Free tier: 25 requests/day\n- One request per WordPress version, plugin, and theme detected\n- Response tracking via `Typhoeus.on_complete` hook in lib/wpscan.rb\n\n**Configuration Files:**\nWPScan loads options from (in order):\n1. `$XDG_CONFIG_HOME/wpscan/scan.json` or `$XDG_CONFIG_HOME/wpscan/scan.yml` (if `XDG_CONFIG_HOME` is set)\r\n2. `~/.config/wpscan/scan.json` or `~/.config/wpscan/scan.yml` (if `XDG_CONFIG_HOME` is not set)\r\n3. `~/.wpscan/scan.json` or `~/.wpscan/scan.yml`\n4. `pwd/.wpscan/scan.json` or `pwd/.wpscan/scan.yml`\n\nUse snake_case for CLI options in config (e.g., `api_token`, `max_threads`).\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance to AI coding agents when working with code in this repository.\n\n## Project Overview\n\nWPScan is a WordPress security scanner written in Ruby. It provides WordPress-specific scanning capabilities including vulnerability detection, enumeration, and password attacks.\n\n**Key characteristics:**\n- Ruby gem with CLI tool\n- Architecture based on Controllers, Finders, and Models (MVC-like pattern)\n- Uses local database (in `$XDG_CACHE_HOME/wpscan/db` or `~/.cache/wpscan/db`, or `~/.wpscan/db` for existing installations) that syncs with WPScan API\n- Scanner framework lives in `lib/wpscan/` (Target, Browser, Controller::Base, Scan, Finders, Formatter, etc.) alongside the WordPress-specific code\n- Supports WordPress-specific security scanning features\n\n## Development Best Practices\n\n### Code Style\n- **Always run rubocop after making changes** to ensure code style compliance\n- Run `bundle exec rubocop -a` to auto-fix issues\n- For specific files: `bundle exec rubocop -a file1.rb file2.rb`\n- The project uses RuboCop for Ruby style enforcement\n\n## Development Commands\n\n### Setup\n```bash\nbundle install\n```\n\n### Running Tests\n```bash\n# Run all tests except slow ones (default for PRs)\nbundle exec rspec --tag ~slow\n\n# Run full test suite (includes slow tests, only runs on master)\nbundle exec rspec\n\n# Run specific test file\nbundle exec rspec spec/path/to/file_spec.rb\n\n# Run with coverage\nbundle exec rspec  # Coverage enabled by default via .simplecov\n```\n\n### Code Quality\n```bash\n# Run rubocop\nbundle exec rubocop\n\n# Auto-fix rubocop issues\nbundle exec rubocop -a\n\n# IMPORTANT: Always run rubocop after making code changes\n# Run on specific files being modified:\nbundle exec rubocop -a path/to/file1.rb path/to/file2.rb\n```\n\n### Building\n```bash\n# Build the gem (runs rubocop & rspec automatically)\nbundle exec rake build\n\n# Install gem locally\ngem install pkg/wpscan-*.gem\n```\n\n### Running WPScan Locally\n```bash\n# From source (outside git repo to avoid load path conflicts)\nruby -Ilib bin/wpscan --url https://example.com\n\n# Or after installing as gem\nwpscan --url https://example.com\n```\n\n### Database Operations\n```bash\n# Update local database\nwpscan --update\n\n# The database is stored in $XDG_CACHE_HOME/wpscan/db or ~/.cache/wpscan/db (new installations)\n# or ~/.wpscan/db (existing installations)\n```\n\n## Architecture\n\n### Core Components\n\n**Entry Point:**\n- `bin/wpscan` - CLI executable that chains controllers together\n- Controllers are chained using `<<` operator and executed in order\n\n**Controllers (app/controllers/):**\nControllers orchestrate the scanning process. The `Core` controller (app/controllers/core.rb) is implicitly handled by the scanner framework via `WPScan::Scan.new` and runs before the explicitly chained controllers. The explicit chain in bin/wpscan executes in this order:\n1. `VulnApi` - API token setup for vulnerability data\n2. `CustomDirectories` - Custom wp-content/plugins directory detection\n3. `InterestingFindings` - Header analysis, robots.txt, readme files\n4. `WpVersion` - WordPress version detection\n5. `MainTheme` - Active theme detection\n6. `Enumeration` - Plugins, themes, users, etc (see CLI options)\n7. `PasswordAttack` - Brute force attacks\n8. `Aliases` - Handle legacy CLI options\n\nNote: The `Core` controller handles database updates, WordPress detection, and banner display during the `before_scan` phase.\n\n**Finders (app/finders/):**\nFinders implement detection strategies for various WordPress components. Each finder type has multiple strategies (passive, aggressive, mixed):\n- `WpVersion` - Detects WordPress version\n- `MainTheme` - Detects active theme\n- `Plugins` - Plugin enumeration strategies\n- `Themes` - Theme enumeration strategies\n- `Users` - User enumeration (author ID brute forcing, API endpoints, etc)\n- `InterestingFindings` - Backup files, debug logs, etc\n- `ConfigBackups` - Config backup file detection (wp-config.php backups)\n- `DbExports` - Database export file detection\n- `Medias` - Media/attachment enumeration via brute forcing\n- `Timthumbs` - Timthumb script detection at known locations\n- `Passwords` - Authentication mechanisms (wp-login, XML-RPC)\n\n**Models (app/models/):**\nDomain objects representing WordPress components:\n- `WpItem` - Base class for plugins/themes\n- `Plugin`, `Theme` - Specific WordPress items\n- `WpVersion` - WordPress version with vulnerability info\n- `InterestingFinding` - Security-relevant findings\n- `ConfigBackup` - Detected wp-config.php backup files\n- `DbExport` - Detected database export files\n- `Media` - Media attachments found on the site\n- `Timthumb` - Timthumb script instances\n- `XMLRPC` - XML-RPC interface details\n\n**Database (lib/wpscan/db/):**\n- `Updater` - Syncs local database with WPScan API\n- `VulnApi` - API client for vulnerability data\n- `DynamicFinders` - Auto-generated finders from database metadata\n- `Fingerprints` - Version detection fingerprints\n- Database stored in `$XDG_CACHE_HOME/wpscan/db/` or `~/.cache/wpscan/db/` (new installations) or `~/.wpscan/db/` (existing installations) by default (overridden in specs to `spec/fixtures/db/`)\n\n### Important Patterns\n\n**Scanner framework:**\nThe scanner framework lives under `WPScan::` alongside the WordPress-specific code. Core framework classes — `WPScan::Target`, `WPScan::Browser`, `WPScan::Controller::{Base,Core}`, `WPScan::ParsedCli`, `WPScan::Vulnerability`, `WPScan::Model::{InterestingFinding,XMLRPC}`, etc. — are single unified classes, not split across framework/WordPress layers. WordPress-specific behavior is mixed in via modules (e.g. `WPScan::Target::Platform::WordPress` is included into `WPScan::Target`). Option parsing delegates to the external `opt_parse_validator` gem.\n\n**Dynamic Finders:**\nFinders can be dynamically generated from database metadata (see `lib/wpscan/db/dynamic_finders/`). This allows version detection strategies to be data-driven.\n\n**Slug Classification:**\nWordPress slugs (plugin/theme names) are converted to Ruby class names via `classify_slug` helper (lib/wpscan/helper.rb). Handles edge cases:\n- Slugs starting with digits get prefixed with `D_` (e.g., `123-plugin` becomes `D_123Plugin`)\n- Special characters are converted to underscores\n- Slugs with all non-latin characters become `HexSlug_` followed by hex-encoded bytes\n\n**API Requests Tracking:**\nThe codebase tracks API requests via `WPScan.api_requests` class variable to monitor usage against API limits.\n\n## Testing\n\n### Test Structure\n- Tests use RSpec with WebMock for HTTP stubbing\n- Fixtures in `spec/fixtures/`\n- Shared examples in `spec/shared_examples/`\n- Coverage via SimpleCov (configured in `.simplecov`)\n\n### Key Testing Helpers (spec/spec_helper.rb)\n- `rspec_parsed_options(args)` - Parse CLI arguments\n- `df_expected_all` - Dynamic finder test expectations\n- `vuln_api_data_for(path)` - Load vulnerability API fixtures\n- `redefine_constant(constant, value)` - Override WPScan constants for testing\n\n### Test Tags\n- `--tag ~slow` - Excludes slow tests (default for CI on PRs)\n- Full suite runs only on master pushes\n\n## Common Gotchas\n\n**Active Support Must Be First:**\n`active_support/all` must be required before other gems to avoid encoding issues with JSON (see lib/wpscan.rb:4-6).\n\n**Running Outside Git Repo:**\nWhen using `wpscan` from source, run it outside the git repo to avoid load path conflicts.\n\n**Database Location:**\nTests override `DB_DIR` to `spec/fixtures/db/`. Production uses `$XDG_CACHE_HOME/wpscan/db` or `~/.cache/wpscan/db` (new installations) or `~/.wpscan/db` (existing installations).\n\n**Port Normalization:**\nWebMock adapter has custom port normalization for Typhoeus (spec/spec_helper.rb:63-96) to handle default ports.\n\n## API Integration\n\n**WPScan API:**\n- Requires API token (via `--api-token` or `WPSCAN_API_TOKEN` env var or config file)\n- Free tier: 25 requests/day\n- One request per WordPress version, plugin, and theme detected\n- Response tracking via `Typhoeus.on_complete` hook in lib/wpscan.rb\n\n**Configuration Files:**\nWPScan loads options from (in order):\n1. `$XDG_CONFIG_HOME/wpscan/scan.json` or `$XDG_CONFIG_HOME/wpscan/scan.yml` (if `XDG_CONFIG_HOME` is set)\r\n2. `~/.config/wpscan/scan.json` or `~/.config/wpscan/scan.yml` (if `XDG_CONFIG_HOME` is not set)\r\n3. `~/.wpscan/scan.json` or `~/.wpscan/scan.yml`\n4. `pwd/.wpscan/scan.json` or `pwd/.wpscan/scan.yml`\n\nUse snake_case for CLI options in config (e.g., `api_token`, `max_threads`).\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nThis file provides guidance to AI coding agents when working with code in this repository.\n\n## Project Overview\n\nWPScan is a WordPress security scanner written in Ruby. It provides WordPress-specific scanning capabilities including vulnerability detection, enumeration, and password attacks.\n\n**Key characteristics:**\n- Ruby gem with CLI tool\n- Architecture based on Controllers, Finders, and Models (MVC-like pattern)\n- Uses local database (in `$XDG_CACHE_HOME/wpscan/db` or `~/.cache/wpscan/db`, or `~/.wpscan/db` for existing installations) that syncs with WPScan API\n- Scanner framework lives in `lib/wpscan/` (Target, Browser, Controller::Base, Scan, Finders, Formatter, etc.) alongside the WordPress-specific code\n- Supports WordPress-specific security scanning features\n\n## Development Best Practices\n\n### Code Style\n- **Always run rubocop after making changes** to ensure code style compliance\n- Run `bundle exec rubocop -a` to auto-fix issues\n- For specific files: `bundle exec rubocop -a file1.rb file2.rb`\n- The project uses RuboCop for Ruby style enforcement\n\n## Development Commands\n\n### Setup\n```bash\nbundle install\n```\n\n### Running Tests\n```bash\n# Run all tests except slow ones (default for PRs)\nbundle exec rspec --tag ~slow\n\n# Run full test suite (includes slow tests, only runs on master)\nbundle exec rspec\n\n# Run specific test file\nbundle exec rspec spec/path/to/file_spec.rb\n\n# Run with coverage\nbundle exec rspec  # Coverage enabled by default via .simplecov\n```\n\n### Code Quality\n```bash\n# Run rubocop\nbundle exec rubocop\n\n# Auto-fix rubocop issues\nbundle exec rubocop -a\n\n# IMPORTANT: Always run rubocop after making code changes\n# Run on specific files being modified:\nbundle exec rubocop -a path/to/file1.rb path/to/file2.rb\n```\n\n### Building\n```bash\n# Build the gem (runs rubocop & rspec automatically)\nbundle exec rake build\n\n# Install gem locally\ngem install pkg/wpscan-*.gem\n```\n\n### Running WPScan Locally\n```bash\n# From source (outside git repo to avoid load path conflicts)\nruby -Ilib bin/wpscan --url https://example.com\n\n# Or after installing as gem\nwpscan --url https://example.com\n```\n\n### Database Operations\n```bash\n# Update local database\nwpscan --update\n\n# The database is stored in $XDG_CACHE_HOME/wpscan/db or ~/.cache/wpscan/db (new installations)\n# or ~/.wpscan/db (existing installations)\n```\n\n## Architecture\n\n### Core Components\n\n**Entry Point:**\n- `bin/wpscan` - CLI executable that chains controllers together\n- Controllers are chained using `<<` operator and executed in order\n\n**Controllers (app/controllers/):**\nControllers orchestrate the scanning process. The `Core` controller (app/controllers/core.rb) is implicitly handled by the scanner framework via `WPScan::Scan.new` and runs before the explicitly chained controllers. The explicit chain in bin/wpscan executes in this order:\n1. `VulnApi` - API token setup for vulnerability data\n2. `CustomDirectories` - Custom wp-content/plugins directory detection\n3. `InterestingFindings` - Header analysis, robots.txt, readme files\n4. `WpVersion` - WordPress version detection\n5. `MainTheme` - Active theme detection\n6. `Enumeration` - Plugins, themes, users, etc (see CLI options)\n7. `PasswordAttack` - Brute force attacks\n8. `Aliases` - Handle legacy CLI options\n\nNote: The `Core` controller handles database updates, WordPress detection, and banner display during the `before_scan` phase.\n\n**Finders (app/finders/):**\nFinders implement detection strategies for various WordPress components. Each finder type has multiple strategies (passive, aggressive, mixed):\n- `WpVersion` - Detects WordPress version\n- `MainTheme` - Detects active theme\n- `Plugins` - Plugin enumeration strategies\n- `Themes` - Theme enumeration strategies\n- `Users` - User enumeration (author ID brute forcing, API endpoints, etc)\n- `InterestingFindings` - Backup files, debug logs, etc\n- `ConfigBackups` - Config backup file detection (wp-config.php backups)\n- `DbExports` - Database export file detection\n- `Medias` - Media/attachment enumeration via brute forcing\n- `Timthumbs` - Timthumb script detection at known locations\n- `Passwords` - Authentication mechanisms (wp-login, XML-RPC)\n\n**Models (app/models/):**\nDomain objects representing WordPress components:\n- `WpItem` - Base class for plugins/themes\n- `Plugin`, `Theme` - Specific WordPress items\n- `WpVersion` - WordPress version with vulnerability info\n- `InterestingFinding` - Security-relevant findings\n- `ConfigBackup` - Detected wp-config.php backup files\n- `DbExport` - Detected database export files\n- `Media` - Media attachments found on the site\n- `Timthumb` - Timthumb script instances\n- `XMLRPC` - XML-RPC interface details\n\n**Database (lib/wpscan/db/):**\n- `Updater` - Syncs local database with WPScan API\n- `VulnApi` - API client for vulnerability data\n- `DynamicFinders` - Auto-generated finders from database metadata\n- `Fingerprints` - Version detection fingerprints\n- Database stored in `$XDG_CACHE_HOME/wpscan/db/` or `~/.cache/wpscan/db/` (new installations) or `~/.wpscan/db/` (existing installations) by default (overridden in specs to `spec/fixtures/db/`)\n\n### Important Patterns\n\n**Scanner framework:**\nThe scanner framework lives under `WPScan::` alongside the WordPress-specific code. Core framework classes — `WPScan::Target`, `WPScan::Browser`, `WPScan::Controller::{Base,Core}`, `WPScan::ParsedCli`, `WPScan::Vulnerability`, `WPScan::Model::{InterestingFinding,XMLRPC}`, etc. — are single unified classes, not split across framework/WordPress layers. WordPress-specific behavior is mixed in via modules (e.g. `WPScan::Target::Platform::WordPress` is included into `WPScan::Target`). Option parsing delegates to the external `opt_parse_validator` gem.\n\n**Dynamic Finders:**\nFinders can be dynamically generated from database metadata (see `lib/wpscan/db/dynamic_finders/`). This allows version detection strategies to be data-driven.\n\n**Slug Classification:**\nWordPress slugs (plugin/theme names) are converted to Ruby class names via `classify_slug` helper (lib/wpscan/helper.rb). Handles edge cases:\n- Slugs starting with digits get prefixed with `D_` (e.g., `123-plugin` becomes `D_123Plugin`)\n- Special characters are converted to underscores\n- Slugs with all non-latin characters become `HexSlug_` followed by hex-encoded bytes\n\n**API Requests Tracking:**\nThe codebase tracks API requests via `WPScan.api_requests` class variable to monitor usage against API limits.\n\n## Testing\n\n### Test Structure\n- Tests use RSpec with WebMock for HTTP stubbing\n- Fixtures in `spec/fixtures/`\n- Shared examples in `spec/shared_examples/`\n- Coverage via SimpleCov (configured in `.simplecov`)\n\n### Key Testing Helpers (spec/spec_helper.rb)\n- `rspec_parsed_options(args)` - Parse CLI arguments\n- `df_expected_all` - Dynamic finder test expectations\n- `vuln_api_data_for(path)` - Load vulnerability API fixtures\n- `redefine_constant(constant, value)` - Override WPScan constants for testing\n\n### Test Tags\n- `--tag ~slow` - Excludes slow tests (default for CI on PRs)\n- Full suite runs only on master pushes\n\n## Common Gotchas\n\n**Active Support Must Be First:**\n`active_support/all` must be required before other gems to avoid encoding issues with JSON (see lib/wpscan.rb:4-6).\n\n**Running Outside Git Repo:**\nWhen using `wpscan` from source, run it outside the git repo to avoid load path conflicts.\n\n**Database Location:**\nTests override `DB_DIR` to `spec/fixtures/db/`. Production uses `$XDG_CACHE_HOME/wpscan/db` or `~/.cache/wpscan/db` (new installations) or `~/.wpscan/db` (existing installations).\n\n**Port Normalization:**\nWebMock adapter has custom port normalization for Typhoeus (spec/spec_helper.rb:63-96) to handle default ports.\n\n## API Integration\n\n**WPScan API:**\n- Requires API token (via `--api-token` or `WPSCAN_API_TOKEN` env var or config file)\n- Free tier: 25 requests/day\n- One request per WordPress version, plugin, and theme detected\n- Response tracking via `Typhoeus.on_complete` hook in lib/wpscan.rb\n\n**Configuration Files:**\nWPScan loads options from (in order):\n1. `$XDG_CONFIG_HOME/wpscan/scan.json` or `$XDG_CONFIG_HOME/wpscan/scan.yml` (if `XDG_CONFIG_HOME` is set)\r\n2. `~/.config/wpscan/scan.json` or `~/.config/wpscan/scan.yml` (if `XDG_CONFIG_HOME` is not set)\r\n3. `~/.wpscan/scan.json` or `~/.wpscan/scan.yml`\n4. `pwd/.wpscan/scan.json` or `pwd/.wpscan/scan.yml`\n\nUse snake_case for CLI options in config (e.g., `api_token`, `max_threads`).\n","category":"root","tokens":2110}]}