coderedirect.com

How to Set Up Cursor for WordPress Development: A Complete Configuration Guide

Written by

wpexpertmax@gmail.com

in

Cursor works fine for WordPress out of the box. It also works much better with about thirty minutes of upfront configuration — and that gap is the difference between AI that generates plausible-looking PHP and AI that generates code you’d actually commit.

This guide walks through the full setup: installation, rules file, project indexing, the settings that actually matter for WordPress work, and a few integrations (MCP servers, WP-CLI tie-ins) that elevate Cursor from a smart editor to a genuine development partner.

If you’ve installed Cursor, opened your WordPress project, and felt like it’s “just VS Code with autocomplete,” this is the article for you.

Prerequisites: A WordPress project (local or remote), basic familiarity with VS Code, and an active Cursor subscription. The free tier works for most of this, but the rules-file features get more useful with the larger context windows on paid plans.

Step 1: Install Cursor and open your WordPress project

Download Cursor from cursor.com and install it. On first launch, it’ll offer to import your VS Code settings and extensions — accept this. Most of the WordPress-relevant extensions you already use (PHP Intelephense, WordPress Snippets, etc.) work in Cursor unchanged.

The first decision is what to open as your project root. Three reasonable choices:

Option A — The full WordPress installation. Open the directory containing wp-config.php, wp-content/, wp-admin/, etc. Cursor will index core, your themes, and your plugins. The AI will know about everything but the index is large and consumes context.

Option B — Just wp-content/. Skip core, index only what you actually edit. This is what I use most of the time.

Option C — A single plugin or theme. Open just the plugin or theme directory you’re working on. Smallest index, fastest context, but the AI doesn’t see the rest of WordPress for reference.

For most workflows, Option B is the right default. Open it once and Cursor will start indexing. You’ll see the indexing progress in the bottom status bar — let it finish before you start prompting, especially on larger projects.

Step 2: Add a .cursorrules file (this is the most important step)

The single highest-leverage thing you can do is add a .cursorrules file at your project root. Cursor reads this file automatically and includes it as context in every AI interaction. Without it, you’re prompting a generic AI. With it, you’re prompting an AI that knows it’s working on WordPress.

Create .cursorrules in your project root and paste this:

# Project context

This is a WordPress project. All generated code must follow WordPress
coding standards and security best practices.

# Security requirements (non-negotiable)

- Escape all output: use esc_html(), esc_attr(), esc_url(), esc_js(),
  or wp_kses() depending on context. Never echo unescaped variables.
- Sanitize all input: use sanitize_text_field(), sanitize_email(),
  sanitize_textarea_field(), or appropriate WP sanitizer for the data type.
- All form submissions must include wp_nonce_field() and verify with
  check_admin_referer() or wp_verify_nonce().
- All AJAX handlers must verify nonces with check_ajax_referer().
- All privileged operations must check capabilities with current_user_can().
- Use $wpdb->prepare() for all direct database queries. Never concatenate
  user input into SQL strings.
- Do not use deprecated functions: mysql_*, create_function, split,
  ereg, eregi, each, or any function deprecated in PHP 8+.

# WordPress conventions

- All user-facing strings must use translation functions: __(),
  _e(), esc_html__(), esc_html_e(), _n(), _x().
- Always include the text domain in translation calls.
- When using hooks, only use hooks that exist in WordPress core or
  the active plugins/themes. If unsure whether a hook exists, ask
  before using it. Never invent hook names.
- Distinguish actions from filters: action callbacks do not return
  values; filter callbacks must return their first argument
  (modified or unmodified).
- Use WordPress HTTP API (wp_remote_get, wp_remote_post) instead
  of cURL or file_get_contents for external requests.
- Use WordPress filesystem API (WP_Filesystem) for file operations
  in plugins, not direct PHP file functions.

# Coding style

- Follow WordPress PHP coding standards (snake_case for functions and
  variables, PascalCase for classes, kebab-case for files).
- Yoda conditions are not required.
- Use spaces inside parentheses for function calls in PHP files.
- Indent with tabs in PHP files, 2 spaces in JS/CSS files.
- Use namespaces for plugin classes (PSR-4 autoloading preferred).

# When generating code

- Before writing code that uses unfamiliar hooks or functions,
  state which hooks/functions you plan to use and confirm they exist.
- Prefer modifying existing files over creating new ones unless
  scaffolding a new plugin or feature.
- When generating a function, generate the docblock with @param,
  @return, and @since tags.
- For database changes, use dbDelta() in plugin activation hooks,
  not direct CREATE TABLE statements.

# Project-specific notes

[Add notes about your specific project here: PHP version, target WP version,
theme framework, custom architecture decisions, etc.]

That last block matters. Replace the placeholder with project-specific context — your PHP version, your theme framework if any, naming conventions you’ve already established, weird quirks of the codebase. The more honest project context Cursor has, the better its output.

Test it. Open any PHP file in your project, hit Cmd+L (or Ctrl+L) to open the chat, and ask: “What rules are you following for this project?” Cursor should summarize the contents of your .cursorrules file. If it doesn’t, the file isn’t being picked up — check that it’s at the project root and named exactly .cursorrules (with the leading dot).

Step 3: Configure project indexing

Cursor’s chat and agent features rely on its index of your codebase. By default, Cursor indexes everything in your project, which for a WordPress site can include node_modules, vendor, build artifacts, and uploads — all of which waste context budget and slow down responses.

Add a .cursorignore file at your project root with these patterns:

# Dependencies
node_modules/
vendor/
bower_components/

# Build output
dist/
build/
*.min.js
*.min.css
*.map

# WordPress uploads and cache
wp-content/uploads/
wp-content/cache/
wp-content/wflogs/
wp-content/upgrade/
wp-content/backup-db/
wp-content/backups/

# WordPress core (uncomment if you opened the full WP install)
# wp-admin/
# wp-includes/
# wp-*.php

# Local development
.wp-env/
*.sql
*.log

# IDE
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

The wp-content/uploads/ line is the most important one. If you don’t ignore it, Cursor will try to index every image and PDF on your site, which destroys both indexing performance and context relevance.

If you opened the full WordPress install, uncomment the wp-admin/, wp-includes/, and wp-*.php lines. Indexing core is rarely useful — Cursor’s training already includes WordPress core, and re-indexing it locally just dilutes your project context.

After saving .cursorignore, rebuild the index: open Cursor settings (Cmd+,), search for “indexing,” and click “Resync Index” or equivalent.

Step 4: Set up the model and context settings

Cursor lets you choose which AI model to use. The setting that matters most is the default model for the chat panel.

Open settings → Models. For WordPress work specifically, my recommendation:

  • Default chat model: Claude Sonnet 4.6 or whichever recent Claude model is available. Claude handles PHP and WordPress conventions noticeably better than GPT-class models in my testing.
  • Auto-complete (cmd+K) model: Cursor’s faster default model is fine here. The latency matters more than the depth of reasoning for inline edits.

Two other settings worth changing:

Increase context length if your plan supports it. Settings → Models → Long Context (or similar). WordPress projects benefit disproportionately from larger context — there’s a lot of cross-file referencing.

Turn on “Include open files in context.” Settings → Editor. This makes Cursor automatically include the files you have open as context, which is exactly what you want for refactoring tasks.

Step 5: Install WordPress-relevant extensions

Cursor inherits the VS Code extension marketplace. The extensions worth installing for WordPress work:

  • PHP Intelephense — PHP language server. Provides go-to-definition, autocomplete, and inline error detection. Worth the paid license if you’re full-time on PHP.
  • WordPress Snippets by WordPresshooks or similar — autocomplete for WordPress functions and hook names. Also helps Cursor’s autocomplete by surfacing real hook names in your editor context.
  • PHP DocBlocker — generates docblocks with one keystroke.
  • WP Hooks IntelliSense — adds inline hook documentation. Useful both for you and as visible context for Cursor.
  • EditorConfig — if your project has an .editorconfig file, this enforces it.
  • GitLens — better git integration. Cursor uses git context for some features, and GitLens makes it easier to give the AI specific commit ranges to reason about.

After installing PHP Intelephense, point it at your WordPress install so it indexes core function signatures:

  1. Open settings (Cmd+,)
  2. Search for “intelephense.environment.includePaths”
  3. Add the path to your WordPress core directory (e.g., /path/to/wordpress)

This is what unlocks “Intelephense knows that get_post() returns WP_Post|null,” which feeds back into Cursor’s context as docblock hints during generation.

Step 6: Connect MCP servers (optional but powerful)

MCP (Model Context Protocol) servers extend what Cursor’s AI can actually do — beyond reading and editing files in your project. For WordPress development, two MCP integrations are worth setting up:

A WP-CLI MCP server. This lets Cursor execute WP-CLI commands directly. Instead of asking “what plugins are active in this install” and getting a guess, Cursor runs wp plugin list and gets the real answer. There are several community WP-CLI MCP servers; check the Cursor MCP directory or GitHub for current options.

A MySQL/database MCP server. Lets Cursor inspect your database schema and run safe read queries. Especially useful when working with custom tables or trying to understand a schema you didn’t design.

To add an MCP server in Cursor:

  1. Open settings → MCP
  2. Click “Add new MCP server”
  3. Paste the server’s configuration (each server’s docs will provide this)
  4. Restart Cursor

Once connected, Cursor’s chat will list the MCP server’s tools as available actions. You’ll see them being invoked when relevant.

Don’t connect MCP servers to production databases. Use a local or staging environment. The point of these integrations is to let the AI poke around freely; you don’t want freely-poking-around on a live site.

Step 7: Test your setup with a real task

Configuration is meaningless without testing. Run this benchmark on your newly-configured Cursor:

Test prompt: “Create a small WordPress plugin called ‘Reading Time Estimator’ that adds an estimated reading time above the content of every single post. Use a filter on the_content. Include a settings page under Settings where the admin can configure words-per-minute (default 200). Follow all WordPress security and coding standards from the project rules.”

A well-configured Cursor should produce:

  • A main plugin file with a proper plugin header
  • A settings page registered under Settings → Reading Time
  • Settings registered with register_setting() and a sanitization callback
  • The settings page using wp_nonce_field() and verifying the nonce
  • Output escaped with esc_html() and esc_attr()
  • The reading time hooked into the_content via add_filter
  • Translation-ready strings using __() with a text domain
  • A check for current_user_can('manage_options') on the settings page

If the generated code is missing more than one of those, your .cursorrules isn’t being applied or the rules need more specific language. Iterate on the rules file until the test passes cleanly.

A few configuration patterns I’ve found useful

Per-plugin rules files. If you’re maintaining multiple plugins in the same project root, you can put a .cursorrules file inside each plugin directory with plugin-specific notes. Cursor uses the most specific rules file for the file you’re currently editing.

CLAUDE.md as a fallback. If you also use Claude Code occasionally, keep a CLAUDE.md file with similar content. Some teams symlink the two so they stay in sync. The rules content is roughly portable between tools.

Project notes file. Beyond .cursorrules, I keep a NOTES.md at the project root with architecture decisions, gotchas, and “we tried this and it didn’t work” history. When starting a complex Cursor session, I paste relevant sections of this into the chat. The rules file handles defaults; the notes file handles specifics.

Snippet files for common prompts. I keep a prompts/ directory in my projects with markdown files like security-review.md, refactor-to-oop.md, add-settings-page.md. Each is a tested prompt I can paste into Cursor when I need that task done. Saves rewriting the same prompts every project.

Common setup problems and fixes

“Cursor isn’t picking up my .cursorrules file.” Check that it’s at the project root (where you opened the project), not in a subdirectory. Filename must be exactly .cursorrules with a leading dot. Restart Cursor after creating it.

“The AI keeps generating insecure code despite the rules.” Your rules file is being read but the AI is ignoring parts of it. Solution: make the rules more explicit and shorter. Long rules files get partially ignored. Also try restating the most critical rules in the prompt itself for high-stakes tasks.

“Indexing is slow.” Check .cursorignore is set up. Most slowness is from indexing node_modules, vendor, or wp-content/uploads.

“Cursor doesn’t recognize WordPress functions.” Install PHP Intelephense and configure its includePaths to point at your WordPress core directory. This is the most common fix.

“Generated code uses outdated patterns.” Your rules file probably doesn’t ban them explicitly. Add specific bans: “Do not use query_posts(). Use WP_Query instead.” Specificity beats generality in rules files.

“I’m hitting context limits on larger refactors.” This is when you switch to Claude Code. Cursor is editor-bound; for tasks that span many files, a terminal-based agent handles the context budget better. See How to set up Claude Code for a WordPress project.

What good Cursor output looks like

After all this configuration, you should be getting WordPress code that needs light review rather than rewriting. Specifically:

  • Hook names are real (you can grep for them in core or in your active plugins)
  • Output is escaped, input is sanitized
  • Forms have nonces, AJAX handlers verify them
  • Database queries use prepare()
  • User-facing strings are wrapped in translation functions
  • Privileged operations check capabilities
  • Code follows your project’s existing patterns rather than generic ones

You should still review every line. AI-generated code with good configuration is closer to “junior developer who knows WordPress” output than to “drop-in production code.” That’s an enormous productivity gain, but it’s not autopilot.

This article covers Cursor specifically. For the broader picture of how Cursor fits into a WordPress development workflow:

Last updated: April 28, 2026. Cursor’s settings UI changes occasionally — if a setting name in this article doesn’t match what you see, check Cursor’s release notes for the current location.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts