You don't need to know WordPress inside out. You need to know what it is, where your code lives, and a handful of rules Cursor will enforce for you if you ask it to. That's the honest answer. The people who run into trouble with WordPress vibe coding aren't the ones who never learned PHP — they're the ones who started editing the wrong files or skipped security basics and had no idea why things broke. Get those four things right and Cursor handles the rest.
What WordPress actually is (the only version you need)
WordPress is a content management system. At its core it's five moving parts: Posts and Pages (your content), Themes (how everything looks — HTML, CSS, JS), Plugins (added functionality — PHP code), a MySQL database (stores everything), and the Admin Dashboard (the UI for managing it all).
As a vibe coder, you only ever touch two things: your custom theme folder at wp-content/themes/your-theme/ or your custom plugin folder at wp-content/plugins/your-plugin/. That's it. Everything else — wp-admin/, wp-includes/, wp-settings.php, other people's plugins — you leave completely alone. Not because those files are sacred, but because WordPress updates them automatically and anything you wrote there will be wiped. More like a shared rental property than a house you own: your stuff goes in your designated room only.
Once Cursor knows where your code lives, it will write to the right place. Give it the wrong folder and it will write to the wrong place. That's the only reason this matters.
The WordPress concepts Cursor needs you to understand (briefly)
You don't need to memorise these. You need to recognise them when Cursor uses them so you can check its work.
Hooks and filters are how WordPress lets you plug into its events without editing core files. An action hook is a moment WordPress broadcasts — “a post just got saved”, “the page header is about to render” — and you attach your own code to it using add_action(). A filter is similar but it hands you a piece of data and expects you to return it (possibly changed) using add_filter(). Cursor will write both. You just need to know they exist so you understand why your code isn't sitting in a random function — it's deliberately hanging off a WordPress event.
Post types and taxonomies are how WordPress organises content. Posts and Pages are the two built-in post types. You can create custom ones — a Testimonial, a Product, a Recipe. Taxonomies are grouping systems: Categories and Tags are the built-in ones, and you can define custom ones too. Post meta is just extra data attached to any post — a price, a rating, a location field.
Sanitisation and escaping are WordPress's two-step approach to safe data. Sanitisation is cleaning data when it comes in — stripping out anything dangerous from a form field before you store it. Escaping is cleaning data when it goes out — making sure whatever you display in HTML can't accidentally run as code. WordPress has dedicated functions for both: sanitize_text_field() and wp_kses_post() on the way in, esc_html(), esc_attr(), and esc_url() on the way out. Tell Cursor to use them and it will.
Nonces are one-time security tokens WordPress generates for forms. A nonce (“number used once”) proves that a form submission came from your site and not from someone forging a request from elsewhere. wp_nonce_field() adds one to your form. wp_verify_nonce() checks it when the form is submitted. Skip this and your forms are open to cross-site request forgery. It sounds more complicated than it is — Cursor writes the two lines, you just need to know to ask for them.
Now you might be thinking: this is already a lot to hold in my head. It's not, really. You're not memorising syntax. You're building a checklist of words to look for when you review what Cursor writes. Hooks, sanitise, escape, nonce. Four words. If they're there, you're probably okay.
Setting up Cursor for a WordPress project
The practical setup takes about ten minutes and makes every subsequent session faster.
Open your Local WP project folder in Cursor (File > Open Folder, then navigate to your site directory). Cursor will try to index your entire project — which would include thousands of WordPress core files you never need. Stop that by creating a .cursorignore file in the root and excluding the noise:
app/public/wp-content/uploads/
app/public/wp-includes/
app/public/wp-admin/
node_modules/
dist/That tells Cursor to skip the uploads folder, WordPress core, and any build artifacts. Your theme and plugin code indexes fast. Cursor's suggestions become relevant instead of generic.
Then create a .cursor/rules/ folder and add a rules file — a plain-text set of instructions Cursor reads before responding to you. Something like: always use WordPress functions instead of direct database queries, always sanitise inputs and escape outputs, always verify nonces on form submissions, never hardcode URLs (use home_url() and admin_url() instead). You write it once, in plain English. Cursor follows it every session without being reminded.
When you're chatting with Cursor's Agent, use @mentions to point it at specific files: @functions.php, @wp-content/themes/your-theme. Without context, Cursor guesses at what exists. With it, Cursor writes code that fits your actual structure.
What a WordPress vibe coding session actually looks like
You open Cursor. You describe what you want in plain English. “Create a custom form that collects testimonials, stores them as a custom post type, and displays them with pagination.” Cursor writes the post type registration, the form with nonces, the display template, the sanitisation. You didn't write a line.
Then you test it in Local WP before it goes anywhere near a live site. Not because something will necessarily be wrong — Cursor is usually solid — but because testing is the job you kept when you handed off the writing. You don't need to understand every function Cursor chose. You need to know if the feature works.
And if you're not sure what WordPress function to use for something, ask. “What WordPress functions can I use to get all posts of type X?” “How do I check if a user is logged in in WordPress?” Cursor knows. You don't have to. That's the arrangement.
The mistakes that catch beginners out
These come up enough that it's worth running through them before you start rather than discovering them when something breaks.
Using $_POST directly — without sanitising it first — means whatever someone types into your form lands raw in your database. Even if your users are trustworthy, it's a habit that will bite you eventually. Always pass it through sanitize_text_field() or equivalent first.
Querying the database with raw SQL instead of WordPress functions like get_posts() or get_option() is another common one. WordPress has a caching layer and a security wrapper built into its own functions. Skip them and you skip both.
Skipping nonce verification on forms. You build a form, it submits, it works — and the nonce check never made it in. Ask Cursor explicitly: “Add nonce generation and verification to this form.”
Hardcoding URLs. https://mysite.com/wp-admin written directly into a template will break the moment the domain changes, or when you move from local to live. admin_url() and home_url() exist exactly for this.
Not checking permissions before performing an action. current_user_can('edit_posts') is one line. Without it, your form might do things for users who shouldn't have access. Cursor will add this if you ask — or if your rules file tells it to.
None of these are obscure edge cases. Not one. Add them to your rules file once and Cursor handles them every time you start a new feature. That's the whole point of the setup.