Cursor Rules for WordPress: Themes, Plugins, and Changes
Cursor rules for WordPress that cover plugin and theme boundaries, output escaping, hook and filter usage, and verification steps, with fenbs retaining the client decisions and approved scope of each change.
Updated 4 min read
Cursor rules for WordPress define where changes belong — theme, child theme, or plugin — how output is escaped, which hooks and filters to use, and what to verify before a change is ready for review. Without them, an assistant edits parent theme files directly, forgets escaping, or reaches for a plugin where a theme function already exists.
fenbs keeps the client decisions that sit behind the code: which features were approved, which plugins are in scope, and which design choices were signed off after review. The rule handles the technical boundaries; fenbs keeps the agreed scope.
What WordPress rules should cover
WordPress development involves more moving parts than a framework with a clean architecture. Parent themes, child themes, plugins, and custom functions all interact. An assistant that does not know the project's structure will add code in the wrong place and create a maintenance problem that is not immediately visible.
- Change location: parent theme, child theme, or specific plugin — where each kind of change belongs.
- Output escaping: the correct escaping function for each output context (
esc_html,esc_attr,esc_url,wp_kses_post). - Hooks and filters: whether to use actions or filters, and the correct priority when order matters.
- Plugin boundaries: which plugins are active, what each handles, and when to create a new one.
- Verification: the checks required before a change is ready for client review.
Theme and child theme boundaries
Editing a parent theme directly means every update to that theme overwrites the changes. A child theme is the correct place for any customization. An assistant that does not know the project's child theme will sometimes add code to the parent because it is the first file it opens. A rule that states this boundary clearly prevents the mistake.
Version control also benefits from this separation. When the parent theme and the child theme are both in the repository, a diff of the child theme shows exactly what the project has customized. A developer joining the project can read the child theme and understand the modifications without diffing against the upstream theme version. That clarity is lost when changes are scattered across the parent.
Some WordPress projects use a plugin for all custom functionality rather than the theme's functions.php. The rule should name that plugin and tell the assistant to add custom hooks, shortcodes, and functions there. That keeps the theme clean and the custom code portable.
--- description: WordPress theme and plugin conventions globs: "**/*.php,**/*.css,**/*.js,functions.php,style.css" alwaysApply: false --- ## Change location - Never edit the parent theme; all theme overrides go in the child theme (`wp-content/themes/client-child/`). - Custom functions belong in the site plugin (`wp-content/plugins/client-custom/`), not in functions.php. ## Output escaping - Escape all output: use `esc_html()` for plain text, `esc_attr()` for attributes, `esc_url()` for URLs. - For content that allows HTML, use `wp_kses_post()` with the allowed tags array. - Never use `echo $variable` without escaping. ## Hooks and filters - Use `add_action` and `add_filter` in the site plugin, not in theme template files. - Prefix all custom hooks with the project prefix: `client_`. - Use a priority of 10 unless order is explicitly required; document any other priority. ## Plugins - Check existing plugins before suggesting a new one for a feature. - Any new plugin requires approval; record it as a decision in fenbs before installation. ## Verification - Test in a local WordPress environment before marking a task done. - Check that the change works with the current theme, active plugins, and PHP version.
Output escaping
Unescaped output is one of the most common WordPress security vulnerabilities. An assistant that writes echo $post_title instead of echo esc_html($post_title) creates a cross-site scripting risk. The correct escaping function depends on the output context: esc_html for text nodes, esc_attr for HTML attributes, esc_url for link destinations.
Late escaping is the rule in WordPress: escape at the point of output, not when data is stored or passed between functions. An assistant that escapes data when saving it may store the escaped version in the database, which causes double-escaping on display. The rule should make clear that esc_html and its siblings belong around each echo statement, not in the sanitization step.
A rule that lists all four common escaping functions and names the context for each removes the need for the assistant to decide. When the output context is clear in the rule, the assistant applies the right function automatically rather than guessing or omitting it. For WordPress security guidance, see the WordPress Plugin Handbook on data validation (opens in a new tab).
Approved scope and client decisions
WordPress projects for clients often have a defined scope: which templates to modify, which plugins are in use, and which features were approved in the contract. An assistant that does not know this scope may add a feature the client did not request or modify a template that was deliberately left unchanged.
This is particularly important for client work, where scope creep is both common and costly. An assistant that adds a feature the client did not request wastes development time and may introduce testing surface that was not budgeted. A rule that names the current scope — or points to where it is recorded — keeps the assistant aligned with the project deliverables.
Recording the approved scope as tasks and decisions in fenbs gives the assistant the information it needs to stay within bounds. Before adding a new feature, it reads the project context and sees whether that feature is in scope. If it is not, it asks rather than proceeding.
Keep client-approved scope and plugin decisions in fenbs
Record the approved scope as tasks in fenbs: which templates are in scope, which plugins are approved, and which design changes were signed off. When a client approves an exception to the standard plugin policy or requests a specific hook approach, record it as a Decision. The assistant reads those decisions before planning work, so it stays within the agreed scope without having to ask every session. fenbs does not access the WordPress admin panel; it keeps the decisions that define the project.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to set up WordPress rules with fenbs
- Create a free account and add the WordPress project.
- Record the project scope in fenbs: active plugins, approved features, the child theme location, and any client decisions about design or functionality.
- Place the
.cursor/rules/wordpress.mdcfile at the project root and adjust the child theme path, plugin path, and prefix to match the project. - Connect Cursor via Integrations and ask it to read the project context before starting any theme or plugin work.
- Before ending a session, record which tasks are complete, what was tested, and any new plugin or scope decision that came up.
For connecting WordPress-specific tools to your AI workflow, see WordPress MCP. For more rule patterns, see cursor rules examples and cursor rules for AI projects. For managing multiple rule files, see cursor rules hierarchy and cursor rules library.