DEV Community: Matt Hummel

WordPress 7.2: Release Date, Features, and What to Test

Matt Hummel — Fri, 23 Oct 2026 00:41:18 +0000

WordPress 7.2 is scheduled to ship on December 8, 2026. Beta 1 landed October 20, and the first release candidate follows on November 17.

The headline items are a new default theme called Ipsum, a suggestion mode for Notes, a Secrets API for storing credentials, and form styling in Global Styles. Nothing is locked until RC 1, though. The core team only ships roadmap items that are "reasonably ready."

Release schedule

Milestone	Date	What happens
Beta 1	October 20	Feature freeze, testing starts
Betas 2–4	October 27, November 3, November 10	Bug fixes
RC 1	November 17	Field Guide out, hard string freeze
RC 2–3	November 24, December 1	Final fixes
Dry run	December 7	24-hour code freeze
Release	December 8	WordPress 7.2 ships

Dates come from the official 7.2 release page. The earlier call for volunteers gave a December 8 to 10 window, so a day of slip wouldn't be a surprise. Matt Mullenweg is release lead, David Baumwald handles release coordination, and George Mamadashvili and Peter Wilson are tech leads.

What's new in WordPress 7.2

The full list is in the Roadmap to 7.2. These are the changes most site owners and developers will notice.

Ipsum, the new default theme

Ipsum is a minimal, blank-canvas blog theme, and the first default theme in years without a year in its name. Expect a plainer starting point than Twenty Twenty-Five.

Notes: suggestion mode and reactions

Notes are block-level comments on a draft. Suggestion mode would let editors propose changes the author accepts or rejects, like tracked changes in a word processor. Emoji reactions and a toolbar shortcut for adding a note are planned too. Suggestion mode is still a large change in review, so the smaller Notes updates could ship without it.

Secrets API and application password alerts

Application passwords: you'll get an email when a new one is added to your account. That's a useful tripwire for account takeovers.
Secrets API: a standard place in core to store credentials like API keys, instead of every plugin rolling its own (often plain options). WP-CLI support comes first; a settings screen is planned for 7.3.
Sudo mode (re-entering your password before risky admin actions) is on the list but has no public proposal yet, so it may slip to 7.3.

Form styling in Global Styles

Global Styles gets UI for styling buttons, text inputs, selects, and labels, including hover and focus states. Block settings may also start showing the value a block inherits from Global Styles, with a way to reset an override. That design is still open.

New and updated blocks

Description List: a block for <dl>, <dt>, and <dd> markup. Good for glossaries and spec sheets.
Table of Contents: moves to server-side rendering and is set to become stable.
Icon block: search icons by keyword, not just by label.
Interactivity API: a new data-wp-html directive for rendering trusted markup, plus router fixes.

Admin, accessibility, and performance

Clearer error messages with a copy button.
Admin notices that screen readers announce properly and that can be dismissed with the keyboard.
Automated axe-core accessibility checks in core's test suite.
An "On This Day" dashboard widget, back for another try after being pulled from 7.1.
Admin script and style concatenation replaced with prefetching.

AI work, mostly in the AI plugin

Most AI work this cycle lives in the official AI plugin, not core. The plan adds read-only abilities for media, taxonomies, and comments, and puts the MCP Adapter in the Plugin Directory. MCP (Model Context Protocol) is the standard that lets AI tools talk to your site.

What's not coming in 7.2

Real-time collaboration: left out and being reworked.
React 19: far along, but unlikely to fully land.
Secrets settings screen: planned for 7.3.
Extensible Site Editor: groundwork continues through 7.3.

How to test WordPress 7.2 before release

Use a staging copy, never a live site.

Make a staging copy and take a fresh backup.
Install the WordPress Beta Tester plugin. Go to Tools → Beta Testing, pick the bleeding edge channel and the beta/RC stream, then update from Dashboard → Updates.
Or use WP-CLI on staging: wp core update --version=7.2-beta1
Click through forms, custom blocks, and any admin screens your plugins add.
Check front-end buttons and inputs, since the new form styling touches them.
Report bugs on Core Trac or in the Gutenberg GitHub repo.

Should you update on release day?

Take a full backup first either way, as the official Updating WordPress guide recommends.

Your site	When to update	Why
Personal blog, few plugins	Release week	Low risk, and a backup covers you
Business site you manage	After testing on staging	Forms and checkout are where updates break things
Client sites	After the first point release	Plugins have time to ship fixes
Any site, security release	Right away	Security fixes close known holes

AI assisted with drafting this post. I reviewed and edited it before publishing.

Originally published on matthummel.com.

Why I Built a Claude Code Playbook for WordPress

Matt Hummel — Thu, 15 Oct 2026 02:29:39 +0000

I keep my Claude Code rules for WordPress in one public GitHub repo, and every machine I use pulls it at the start of the next session. I built it because my rules kept drifting between projects and costing tokens I didn't need to spend.

This post covers why I made the AI Dev Standards & Playbook, what's in it, and how it changed the way I work with Claude Code.

TL;DR

One repo holds my coding standards, SEO rules, writing voice, reference docs, slash commands, a reviewer agent and a deploy kit.
Only one rule is always on, and it's under 1 KB. Everything else loads by file path or when a skill is used.
A SessionStart hook pulls main and reinstalls on every new Claude Code session, so one merge updates every machine.
The repo is public and generic. Client facts stay in each project's own CLAUDE.md.
Repo: github.com/matthummel-pa/ai-dev-standards-playbook
Docs: matthummel-pa.github.io/ai-dev-standards-playbook

Why did I build a Claude Code playbook?

Two problems.

My rules lived inside one theme repo, so they didn't follow me to the next client.
They were all always on, so every session paid for every line whether it needed them or not.

When I pulled the rules out of my matthummel.com theme, I had ten always-on rule files. Together they were about 60 KB, loaded into every session. Most of it was WordPress and Sage detail that only matters when I'm editing a PHP or Blade file. Claude Code loads rules at session start, so that 60 KB rode along even when I was writing a blog post.

The fix was to split by trigger. The core rule is now 0.9 KB. The rest only load when Claude touches a matching file or picks a skill. Same standards, a fraction of the context.

What tipped me over was typing the same prompts again and again. Every new session started with me pasting the same security rules, the same accessibility checks and the same "answer first" note. Each of those prompts counted against my credits.

I wanted the rules to already be there, and I wanted the always-on part as small as possible so each session cost less.

How does the playbook load into Claude Code?

Claude Code reads rules, skills and commands from ~/.claude, and a SessionStart hook can run a script before each session. The playbook uses both.

install.sh copies the repo into ~/.claude once and adds the hook. From then on, every new session runs sync.sh, which does a git pull --ff-only and recopies the files. If nothing changed, it prints nothing.

I use copies, not symlinks, on purpose. Symlinks need Developer Mode on Windows, and Claude Code loads ~/.claude/rules/ without an approval prompt when the files are plain copies.

One catch: rules load at session start, so a merge shows up in the session after the one that pulled it. When I want it right away, I run sync.sh by hand and restart.

Here's how the layers fit together:

Layer	Loads	Use it for
`rules/core.md`	Every session	5 to 10 lines that are true everywhere
Path rules (`paths:` in frontmatter)	When Claude reads or edits a matching file	Coding standards per file type
Skills (`SKILL.md`)	Description always; body only when used	Long playbooks: writing, SEO, architecture
Commands (`/pb:…`)	Only when I type them	Repeatable workflows
Project `CLAUDE.md`	Every session in that repo	Project facts, commands, hard no's

What's in the repo?

Eight folders. Here's what each one does and when it loads.

Rules

core.md is the only always-on file. It covers:

Answer first
Work on a branch
Read before editing
Sanitize and escape
WCAG 2.1 AA
Never invent metrics
Verify versioned APIs against official docs

The other rules load by path:

WordPress rules: *.php, theme.json and block.json
Sage rules: app/, resources/ and vite.config.js
SEO rules: Blade templates and SEO code

Skills

A skill is a folder with a SKILL.md that Claude loads on demand. I have six so far:

doc-references: the official docs for my stack (WordPress Developer Resources, Roots, Tailwind, MDN, the WHATWG HTML spec, W3C and the ARIA APG, web.dev, caniuse, TypeScript, React, Next.js, Node, NestJS) and a rule to check them before writing code against an API I haven't verified that session.
content-writer: my editorial voice and readability rules for posts and site copy.
growth-design: landing page, conversion copy and design review guidance.
portfolio-seo: on-page limits for portfolio and service pages.
geo-blog-post: blog structure for Google AI Overviews and LLM search.
sage-architecture: ACF Pro fields registered in PHP, a Customizer dark-mode default, the Tailwind v4 and theme.json token bridge, and CI/CD for built themes.

Commands, agent and hook

I have five slash commands, namespaced so they never shadow a project's own:

/pb:new-project
/pb:plan
/pb:fix
/pb:review
/pb:ship

The wp-reviewer agent reads a diff against the WordPress Developer Handbook before I open a pull request.

A PostToolUse hook runs PHPCS on every PHP file Claude edits and sends the errors straight back, so Claude fixes them before moving on.

Project template

/pb:new-project drops a kit into a theme repo:

A CLAUDE.md under 2 KB
A .claude/settings.json with safe permissions and a WebFetch allowlist for every doc site in doc-references
A GitHub Actions workflow that builds the theme, swaps it over SSH, runs a health check and rolls back on failure

How do I use the rules and skills?

I don't call them. Claude Code picks them up from what I'm doing and what I type.

Rules watch the files. Each rule has a paths: list in its frontmatter. Open a .php file and the WordPress rules are in context. Open a Blade template and the Sage and SEO rules are there. I never mention them.
Skills watch the prompt. Claude always sees each skill's one-line description and loads the full SKILL.md only when my request matches it. If I say "draft a blog post about X," geo-blog-post and content-writer load. If I say "add an ACF field for the hero," sage-architecture loads. If I ask what wp_insert_post() returns, doc-references loads and Claude fetches the handbook page.
Commands wait for me. /pb:fix add a skip link to the header runs the fix-and-ship workflow. /pb:review runs the reviewer agent on the branch. Nothing happens until I type the slash.

That's why the descriptions matter more than the bodies. A skill with a vague description never loads, and one with a sharp description loads at the right moment. When a skill isn't firing, I fix the description, not the prompt.

How does it help me develop with Claude Code?

Consistency. Every client site gets the same security checks, the same accessibility bar and the same review before a PR. I don't paste rules into a new CLAUDE.md each time.

Fewer stale answers. The doc-references skill tells Claude to fetch the official page before writing against a hook, a Tailwind v4 feature or a Next.js API. The project settings pre-approve those domains, so the fetch never stops for a permission prompt.

Cheaper sessions. The always-on context went from about 60 KB to under 1 KB, and I stopped re-sending the same rules by hand at the start of each session. Smaller prompts, fewer credits.

One place to fix things. When Claude gets something wrong twice, I change the rule once, open a PR, and the fix lands everywhere the next day. The repo's CI checks frontmatter, the core rule's size budget and a blocklist for private details, so I can't merge a client host name by mistake.

What stays out of the repo?

Anything that names a client. Hosts, paths, plugin lists, logins and product catalogs live in each project's CLAUDE.md and .claude/rules/.

The playbook is public, so validate.py scans every file for patterns like application passwords, GitHub tokens and private keys. It fails the build if one shows up.

Should you build your own?

If you use Claude Code on more than one repo, yes. Start smaller than I did:

Put five lines in a core rule.
Move one long checklist into a skill.
Add the sync hook.

You'll know within a week whether it's worth growing. Anthropic's guide on when to use CLAUDE.md, skills, hooks and subagents is a good overview of how the pieces fit together.

Originally published on matthummel.com.

Website Basics for New Developers and Business Owners

Matt Hummel — Tue, 13 Oct 2026 03:54:27 +0000

The website basics are the same whether you build sites or own one: where a site lives and how it changes without breaking. Anyone learning to build sites has to pick these up early. An owner who knows even a little of this gets more out of every developer they hire.

Website basics at a glance

A website is files and a database on a server. People reach it through a domain name.
Before any framework, a new developer needs HTML, CSS, JavaScript, and Git.
Owners should have every account in their own name and know when the last backup ran.
Test changes on a staging site, a private copy of the live one, before visitors see them.

How does a website work?

A website is a set of files and a database on a rented computer, reached through a name you rent. Your browser asks for the name. DNS turns that name into the server's address, and the server sends back the page. On a WordPress site, the server builds each page with PHP before it sends it.

DNS stands for Domain Name System. PHP is the programming language WordPress is written in.

Every site has the same pieces, and each piece has its own account.

Piece	What it is	Where the account lives	Who should own it
Domain	Your address, like example.com	A registrar, the company that sells domain names	The business owner
DNS	The settings that point your domain at your host and your email	Your registrar, your host, or a service like Cloudflare	The business owner
Hosting	The server that stores your site's files and database	A hosting company	The business owner
WordPress	The software that runs your site	Installed on your hosting	The owner, with an Administrator account
Paid themes and plugins	Add-ons with a yearly license	Each vendor's site	The owner, or the developer with the license written down

DNS is the piece people forget. It's also the one that takes email down when it changes by mistake.

This table is the core of it. It's worth being able to explain from memory, whichever side of the project you're on.

What should beginner web developers learn first?

Learn what every site shares before you learn a framework. That means HTML, CSS, JavaScript, Git, how a page travels from server to browser, and how to read an error. After that come the habits clients end up paying for, like security, accessibility, and speed.

I taught myself, and I wrote about it in how I became a self-taught WordPress developer. This is the order I'd follow now.

HTML and CSS. Use the right tag for the job, and learn the box model, flexbox, and grid. Build one full page with no framework.
JavaScript. Learn events, the DOM, and fetch before React or any other library. The DOM is the browser's live copy of your page.
How a request works. Open your browser's developer tools and watch the Network tab. Know what a 404 and a 500 mean.
Git. Get used to small commits and working on a branch, then put your first project on GitHub.
Errors and docs. Read the error message before you search for it. In WordPress, turn on WP_DEBUG_LOG on your local site and read wp-content/debug.log.
Security. Never trust input. In WordPress that means you sanitize what comes in, escape what goes out, and check a nonce and the user's capability before you save anything.
Accessibility. One h1, headings in order, alt text on images, and a page that works with the keyboard alone. The quickest test is to put the mouse away and tab through the page.
Speed. Oversized images are the usual first thing to fix. Test on a real phone, and run your pages through PageSpeed Insights.
Talking to clients. Put the scope in writing, and be honest about what you don't know yet.

A nonce is a short-lived token that proves a request came from your own form.

The one thing I wish I'd learned sooner is to stop studying and start building. I spent way too much time on online courses and tutorials. Once you've learned something, go use it on a real project, or you'll get stuck in a tutorial cycle that never ends.

I'd also learn a few things at a time. You don't need to know everything at once.

What should a business owner understand about their website?

If you build sites, this is the section to send your clients.

You can run a website well without writing code. For an owner, it comes down to knowing what you own and who runs the updates and backups. It also helps to know what your developer needs from you, and how to tell when something's broken.

Own every account

Your domain, hosting, and WordPress login should be in your name, tied to an email you check. If they sit in a past developer's name, or a relative's, you can get locked out of your own site.

Check it in 10 minutes:

Look up your domain at lookup.icann.org. The result names your registrar.
Log in to the registrar. Confirm the contact email is yours and turn on auto-renew.
Log in to your hosting account. Confirm the billing is in your name.
Log in to WordPress and open Users. Confirm your role is Administrator.
Save every login in a password manager.

I've been on the wrong side of this one. I kept a client's domain in my own account. When it came time to transfer it and hand ownership back, it turned into a mess. In the end the client lost the domain altogether. It cost them time, and it cost me a good client relationship.

If you build sites, don't keep a client's domain or hosting in your own account. Have them own it and add you as a user, never a shared password. When the job ends, they remove that user and nothing else changes.

Updates and backups are routine

WordPress, your theme, and your plugins all get updates, and many of them fix security holes. Someone has to run them, so agree on who that is.

A backup is a full copy of your files and database, kept somewhere other than your server. Ask two questions: when was the last backup, and has anyone ever restored one?

Your developer needs things from you

Projects often stall in the first week because the developer is waiting on something. Bring this list to the first meeting:

Logins, or your own user account, for the domain, hosting, and WordPress.
The main thing you want a visitor to do: call, book, buy, or fill out a form.
Your logo files, photos, and the words for each page. If you need the words written, say so early, because it changes the quote.
Two or three sites you like, with a note on what you like about each.
A deadline and a budget range.
One person who makes the final call. Feedback from five people with no tiebreaker stalls a project.

Most of the time, what's missing is the content: photos, logos, and the words for the pages. Always get that collected in one place before the project starts.

If you're on the other side of that meeting, this list makes a good intake form to send ahead of the first call.

Check that your site still works

Once a month, send yourself a message through your own contact form. Then open the site on your phone and run the home page through PageSpeed Insights.

A broken contact form can sit for weeks before anyone notices.

What is a staging site, and why does it matter?

A staging site is a private copy of your website where changes get tested before visitors see them. Updates, new plugins, and design changes go there first. If something breaks, it breaks on the copy. Ask any developer you hire where they test changes. If they say "on the live site," I'd keep looking.

This part applies whether you build the site or own it.

Why it matters this fall

WordPress 7.2 is the next major release. Beta 1 is scheduled for October 20 to 22, 2026, and the final release for December 8 to 10, according to the WordPress Developer Blog.

Security releases don't follow that calendar. WordPress 7.0.2 shipped in July 2026 with a note to update right away. I covered a later one in what's new in WordPress 7.1.3.

With a staging site, you can apply an update like that the same day and know your contact form still works.

How to get one

Many hosts include staging in their plans. Ask your host, or check your hosting dashboard for a button labeled Staging. If your host doesn't offer it, your developer can set one up on a subdomain like staging.example.com.

What a safe update looks like

Back up the live site.
Copy the live site to staging.
Run the updates on staging.
Check the pages that make you money: home, contact form, booking, checkout.
Run the same updates on the live site.
Check those pages again.

I learned how much step 1 matters when I managed a college's website. The backups got messed up, and users lost content edits they had already made. That's why the backup comes first on this list, and why it's worth restoring one now and then to prove it works.

For developers: tell WordPress it's on staging

Set the environment type in wp-config.php on the staging copy only:

// wp-config.php on the staging copy only.
// Place this above the "That's all, stop editing!" line.
// Allowed values: local, development, staging, production.
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Then check it in your theme or plugin before you load anything that belongs on the live site only:

/**
 * Print the analytics tag on the live site only.
 *
 * @return void
 */
function mh_print_analytics_tag() {
    // Returns 'production' when WP_ENVIRONMENT_TYPE is unset or invalid.
    if ( 'production' !== wp_get_environment_type() ) {
        return;
    }

    // Your analytics snippet goes here.
}
add_action( 'wp_head', 'mh_print_analytics_tag' );

The first block labels the copy as staging. The second one skips your analytics tag anywhere the label isn't production, so test visits stay out of your reports.

One catch: a site with no label counts as production. Set local on your own machine too, or your test visits will show up in your reports.

wp_get_environment_type() has been in WordPress since 5.5.0. Also check Settings > Reading on staging and tick "Discourage search engines from indexing this site." That box is only a request, so put staging behind a password or basic auth too.

I tested both snippets on WordPress 7.1.3 and PHP 8.3 in October 2026.

FAQ

Should a beginner learn React or WordPress first?

Learn HTML, CSS, and plain JavaScript first. Both React and WordPress sit on top of them. After that, pick the one that matches the work you want. For small business sites, I'd start with WordPress.

Can my web developer own my domain or hosting for me?

They can manage both, but the accounts should stay in your name. Give your developer their own user, and if you part ways you remove that one user and keep everything else.

Do I need a staging site for a small website?

Yes, if the site brings in bookings, sales, or leads. If the contact form breaks after an update, you may not find out for days. A five-page site with no forms can get by with a good backup.

What if I can't find my logins?

Start at lookup.icann.org to find your registrar. Then use the password reset on each account. If the reset email goes to an address you can't reach, contact the company's support and be ready to prove who you are.

Should I turn on automatic updates in WordPress?

Keep them on for minor releases. WordPress turns those on by default, and they carry security fixes. For major releases like 7.2, and for plugins your site depends on, I'd test on staging first.

Your next step

If you're learning, pick one item from the developer list that you can't explain yet and build something small with it this week.

For owners, the 10-minute ownership check is the place to start.

Which of these did you learn the hard way? Tell me in the comments.

Originally published at matthummel.com.

WordPress MCP Adapter: Connect Claude Code and Cursor to Your Site

Matt Hummel — Sat, 10 Oct 2026 03:44:36 +0000

The WordPress MCP Adapter lets AI tools like Claude Code and Cursor find and run actions on your WordPress site. It takes the abilities you register with the Abilities API and shares them over the Model Context Protocol (MCP).

Here’s the full setup: install the adapter, expose one ability, find the default endpoint, log in with an Application Password, and run a few safety checks.

Already wired an AI tool to a WordPress site? Skip to the end and tell me how it went. I’d like to compare notes.

At a glance

Needs: WordPress 6.9 or newer and PHP 7.4 or newer. WordPress 6.9 includes the Abilities API in core.
Plugin: the official MCP Adapter from the WordPress GitHub organization. The latest release when I wrote this guide was 0.6.1.
Opt in: an ability shows up on the default MCP server when its meta has mcp.public set to true. A broader public flag in meta works too.
Default endpoint: /wp-json/mcp/mcp-adapter-default-server
Login: a WordPress user and an Application Password.
Try it on a local site first. An AI tool gets the same rights as the user you connect it with.

What MCP is, in plain terms

MCP is an open standard that gives AI apps a shared way to connect to outside tools and data. An MCP server lists the tools it offers. An MCP client, like Claude Code or Cursor, reads that list and can call those tools when you ask it to.

WordPress already has its own way to describe actions, called the Abilities API. I covered it in my first Abilities API integration post. Each ability has a name, an input schema, an output schema, a permission check, and a callback. The MCP Adapter takes those abilities and puts them in a form an MCP client can read.

Here’s how one request moves through the stack:

You ask Claude Code or Cursor a question.
The client calls the adapter’s server on your site.
The adapter looks up the matching ability.
WordPress runs that ability’s permission check for the connected user, before any code executes.
The result travels back to the client as structured data.

WordPress MCP Adapter diagram: a WordPress site in the center, connected to a terminal and a code editor, with lock, key, and shield icons for login and permissions

!WordPress MCP Adapter diagram: a WordPress site in the center, connected to a terminal and a code editor, with lock, key, and shield icons for login and permissions

WordPress MCP Adapter diagram: a WordPress site in the center, connected to a terminal and a code editor, with lock, key, and shield icons for login and permissions

The WordPress MCP Adapter sits between your site and AI tools like Claude Code and Cursor.

Step 1: Install the WordPress MCP Adapter

The adapter isn’t in core yet, so you add it yourself. You can install it as a plugin, or bundle it inside your own plugin as a Composer package. For a first test, I’d go with the plugin because it’s simpler.

The Composer route makes sense once you ship a plugin that depends on the adapter. Running composer require wordpress/mcp-adapter installs it alongside your own code, so the adapter travels with your plugin.

To install the plugin:

Download the latest release from the WordPress/mcp-adapter repository.
On a local or staging site, upload it as a plugin.
Activate it, and check that your site runs WordPress 6.9 or newer.

Heads up: the adapter is still under version 1.0, so names and commands may change from one release to the next. Before you copy anything below, read the README for the version you installed.

Step 2: Mark an ability as public for MCP

Registering an ability won’t share it with AI tools by itself. You have to opt in by adding 'mcp' => array( 'public' => true ) inside the ability’s meta array.

That flag shares the ability over MCP and nothing else. The adapter README also describes a broader public flag in meta, which the default server honors too.

Here’s a small example that only reads data. It returns the site name and tagline, and it only runs for users who can edit posts.

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category( 'my-site', array(
        'label'       => 'My Site',
        'description' => 'Abilities for this site.',
    ) );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'my-site/get-site-info', array(
        'label'               => 'Get site info',
        'description'         => 'Returns the site name and tagline.',
        'category'            => 'my-site',
        'output_schema'       => array(
            'type'       => 'object',
            'properties' => array(
                'name'    => array( 'type' => 'string' ),
                'tagline' => array( 'type' => 'string' ),
            ),
        ),
        'execute_callback'    => function () {
            return array(
                'name'    => get_bloginfo( 'name' ),
                'tagline' => get_bloginfo( 'description' ),
            );
        },
        'permission_callback' => function () {
            return current_user_can( 'edit_posts' );
        },
        'meta'                => array(
            'annotations' => array( 'readonly' => true ),
            'mcp'         => array( 'public' => true ),
        ),
    ) );
} );

The readonly annotation tells clients this ability doesn’t change anything. The permission callback runs on every call, even when the request comes from an AI tool.

Step 3: Know the default server endpoint

Once the plugin is on, the adapter sets up a default MCP server. You’ll find it at this path on your site:

https://your-site.local/wp-json/mcp/mcp-adapter-default-server

This server doesn’t list each public ability as its own tool. It offers three general tools:

One finds the public abilities.
One gets details about a single ability.
One runs an ability.

The README calls them mcp-adapter/discover-abilities, mcp-adapter/get-ability-info, and mcp-adapter/execute-ability. So the client finds your ability first, then calls it.

If you’d rather list each ability as its own tool, you can register a custom server. It’s a good thing to try once the default server is working.

Step 4: Create an Application Password

Application Passwords come built into WordPress. They let an outside app log in through the REST API without your main password, and you can revoke each one on its own.

Open the profile page for the user the AI tool will use.
Scroll down to Application Passwords. Type a name like “Cursor local” and click Add.
Copy the password right away. WordPress only shows it once.

Tip: make a separate user for this and give it the lowest role that still passes your permission checks. Don’t connect an AI tool as an admin unless you have a good reason.

Step 5: Connect Cursor and Claude Code

For an HTTP connection, the adapter docs suggest a small proxy package called @automattic/mcp-wordpress-remote. It runs through npx on your computer and takes care of the login for you.

The two connection types suit different setups:

STDIO runs the server through WP-CLI on the same machine as the site. It needs no password and works well for local development.
HTTP goes through the REST API with an Application Password. Use it for staging sites and anything you can’t reach from a terminal.

Cursor

Add this to .cursor/mcp.json in your project, then restart Cursor:

{
  "mcpServers": {
    "wordpress-local": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://your-site.local/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "mcp-user",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}

Claude Code

If WP-CLI works on your local site, you can skip HTTP and use STDIO. This command runs the server through WP-CLI as the user you pick:

claude mcp add wordpress-local -- wp --path=/path/to/site mcp-adapter serve --server=mcp-adapter-default-server --user=mcp-user

You can also give Claude Code the same npx setup that Cursor uses.

Once you’re connected, ask the tool to list the abilities on your site. You should see my-site/get-site-info in the list.

Safety checks before you go further

Start with read-only abilities. Share abilities that only fetch data before you add any that create, edit, or delete.
Keep permission callbacks strict. Never return true for everyone. The callback is what really keeps people out.
Keep passwords out of git. If .cursor/mcp.json holds a password, add it to .gitignore.
Look before you approve. Both tools ask before they run a tool call. Read the input before you say yes.
Test a failed permission check. Get one read-only ability working, then see what happens when the check says no. That test teaches you more about safety than a success does.
Revoke the password when you’re done. Delete the Application Password once you stop testing.
Stay local until you trust it. Don’t point an AI tool at a client’s live site on day one.

FAQ

Is the WordPress MCP Adapter part of WordPress core?

No. WordPress 6.9 includes the Abilities API in core, but the MCP Adapter is a separate plugin you install from GitHub. It’s still under version 1.0, so expect changes between releases.

Do I need WP-CLI to connect Claude Code?

No. WP-CLI gives you a STDIO connection on a local site. Without it, you can use the HTTP endpoint with the npx proxy and an Application Password, the same way Cursor connects.

Can an AI tool change my site through MCP?

Only through abilities you’ve marked as public, and only when the connected user passes each ability’s permission callback. Start with read-only abilities and a user with a low role.

Why doesn’t my ability show up in Cursor or Claude Code?

Check three things first:

The ability’s meta needs the mcp public flag.
The adapter plugin has to be active.
The site has to run WordPress 6.9 or newer.

Then ask the tool to list the abilities again.

Your turn

I’m still early with this setup, and I’d like to hear how yours went.

Have you connected Claude Code or Cursor to a WordPress site yet? Did you go with STDIO or HTTP?
Which ability would you expose first on a real site?
Did a permission check ever block something you expected to work?

Tell me in the comments, including the parts that broke. I read every reply.

Keep reading

I explain how I split work between these tools in my AI workflow for WordPress development. I also wrote about where AI speeds up my WordPress work, and where it doesn’t.

Originally published on matthummel.com.

How I published my first WordPress.org plugin with Cursor, Git, and AI

Matt Hummel — Thu, 24 Sep 2026 01:23:01 +0000

Today I published my first plugin on WordPress.org: TOCguide. It is a Gutenberg Table of Contents block with an optional Reading Guide. No accounts, no tracking, no outside APIs. The listing is live at version 1.6.3.

This is a slightly shorter Dev.to version of a longer write-up on my site. The full notes are here: How I published my first WordPress.org plugin with Cursor, Git, and AI.

Why AI mattered for finishing this

I am a dad of twins. I also have a full-time job and a freelance WordPress side gig. Evenings and weekends are short. Shipping a Plugin Directory product the old way — every PHPCS pass, every readme tweak, every packaging step — would have sat on a list for years.

I used AI tools on purpose: Cursor (including cloud agents on the repo), Grok Bot for site and content work around matthummel.com, and normal Git + GitHub Actions so the machine checks stayed honest. I am not saying AI replaces judgment. I am saying it compressed weeks of typing and rework into hours I actually had.

People are right to be careful with AI. Used poorly, it invents APIs, ships insecure PHP, and fights the WordPress.org guidelines. Used with rules, reviews, and CI, it can raise daily output without lowering the bar. Feedback and pushback are welcome in the comments.

What TOCguide is

TOCguide is a single-purpose block plugin. Display name TOCguide. Slug, folder, text domain, shortcode, and CSS prefix are all tocguide. That one identity mattered for WordPress.org guideline 17 and for long-term support.

Standard TOC: heading levels, nested lists, five Block Styles, sticky/collapse, scroll-spy, smooth scroll offset, auto-insert, [tocguide] shortcode, accessible <nav>
Optional Reading Guide: section previews, density bars, read-time badges, reading progress, author notes, localStorage reactions and citations — all from post content and meta, not remote services
Builder fallbacks for Elementor, Bricks, and HTML-based themes
License: GPLv2 or later. Privacy: no phone-home Docs: matthummel-pa.github.io/tocguide Source: github.com/matthummel-pa/tocguide

The setup in brief

Cursor rules and cloud agents. Under .cursor/rules/ I keep always-on rules for block coding, brand typography, and the WordPress.org Plugin Directory FAQ plus the 18 guidelines. A CLAUDE.md file states the product intent in plain language. Cloud agents handled large slices as pull requests. I still read every PR. The agent drafts. I decide what merges.

Git and GitHub Actions. CI on push and pull request runs lint, build, PHP lint, and PHPCS. Tags like v1.6.2 fire a Release workflow that builds the plugin zip with @wordpress/scripts plugin-zip and attaches it to a GitHub Release. That zip is what goes through SVN to the directory after review.

Block architecture. TOCguide is a dynamic block: block.json (apiVersion 3), save.js returns null, and src/render.php prints the nav. Heading maps live in TOCguide_Headings so render stays thin.
Where Grok Bot fits. Cursor owns the plugin code. Grok Bot owns a different lane for me: site drafts, Rank Math, media, and turning repo facts into readable posts. Same person reviewing both. Different tools for code vs. site content.

An honest take on AI

What helped:

Written rules in the repo so agents follow Gutenberg and WordPress.org constraints
CI as a second reviewer that never gets tired of PHPCS or lint
Cloud agents for packaging and repetitive compliance edits while I was with the kids or on client work What still needs a human:
Product taste (what belongs in free vs later)
Security and escaping reviews
Reading the official guidelines yourself before you argue with a reviewer
Saying no when a suggestion would phone home, load a CDN script, or lock features behind a paywall on .org I am not claiming AI is magic. I am claiming that for a busy parent shipping a first directory plugin, the time cost used to be the blocker — and tooling that respects WordPress standards can change that. If your experience differs, I want to hear it.

Try it

If you build plugins with AI, or you refuse to, leave a comment. What worked, what broke review, what you would never trust an agent with.

— Matt Hummel

WordPress Abilities API integration — A Practical First Integration

Matt Hummel — Fri, 04 Sep 2026 16:32:53 +0000

Introduction

This post walks through a practical WordPress Abilities API integration for developers and product teams. It shows how to declare discoverable, executable abilities (name, schema, callback) so external tools, automation, and AI agents can find and run site functionality. The goal here is to give you a safe, minimal first integration and a straightforward path for promoting and engaging with it once it’s live.

What the Abilities API is and why it matters

The Abilities API was added to WordPress to make site capabilities both machine-readable and executable. It arrived in WordPress 6.9 and provides a standard registry for actions your site can perform. (developer.wordpress.org)

Why it matters: abilities make your site discoverable to integrations, enforce consistent parameter schemas, optionally expose functionality via REST, and give automation and AI tools a predictable way to execute tasks.

Quick overview: register an ability

At the heart of a WordPress Abilities API integration is wp_register_ability(). Use it to declare an ability's name, description, JSON schema for parameters, and the callback that performs the work. This is how you make tasks like "create-draft", "sync-product", or "triage-comment" visible to other systems. (developer.wordpress.org)

Minimal example

add_action( 'wp_abilities_api_init', function() {
  wp_register_ability( 'my-plugin.create_draft', [
    'title'       => 'Create draft post',
    'description' => 'Create a draft post with title and content',
    'meta'        => [ 'show_in_rest' => true ],
    'args'        => [
      'title'   => [ 'type' => 'string' ],
      'content' => [ 'type' => 'string' ],
    ],
    'callback'    => function( $args ) {
      return wp_insert_post( [
        'post_title'   => $args['title'],
        'post_content' => $args['content'],
        'post_status'  => 'draft',
      ] );
    }
  ] );
} );

Setting show_in_rest gives you automatic REST endpoints and makes the ability discoverable through the Abilities REST routes. (developer.wordpress.org)

Discovery, REST endpoints, and authentication

When you expose abilities over the REST surface, external systems can discover what your site can do and what parameters each ability expects. The Abilities REST endpoints follow the same authentication and permission model as the WordPress REST API, so apply least-privilege access when granting remote systems permission to call abilities.

Where to hook and how to structure code

Register abilities on the Abilities API init hooks (for example, wp_abilities_api_init and any category registration hooks) so they’re available for discovery and for adapters that surface them to agents. Hooking in at the right point ensures predictable availability and compatibility with other systems. (make.wordpress.org)

Integrating with AI agents (MCP adapter)

If you want to connect Abilities to AI agents and automation frameworks, look at the WordPress MCP adapter. It maps Abilities into tools and resources that agent frameworks can consume, which helps you build safe, scoped integrations between AI tooling and site functionality. (developer.wordpress.org)

Safety, permissions, and best practices

Keep abilities narrow and purpose-built. Prefer small, least-privilege actions rather than a single admin-level ability that does everything. Log executions with context (ability name, calling actor, parameters) so you can audit activity and respond to misuse. Treat any ability that performs writes as sensitive and require explicit opt-in before exposing it to external agents.

Next steps and resources

1) Build a minimal plugin that registers one read-only and one write ability. 2) Publish the project on GitHub with clear examples and tests. 3) Share the tutorial on DEV.to and a short business summary on LinkedIn; engage with comments and track clicks and leads. Use the Abilities API docs and examples as your primary references while developing. (developer.wordpress.org)

Follow this practical approach and you’ll end up with a discoverable, auditable, and promotable WordPress Abilities API integration that serves both developers and business stakeholders.

Originally published on matthummel.com.

Why I'm Moving Away from Power Platform and Back to Modern WordPress

Matt Hummel — Wed, 02 Sep 2026 05:05:11 +0000

After nearly five years of enterprise Power Platform work, I'm pivoting my content and personal projects back to modern custom WordPress development.

For the last nearly five years, a big part of my day-to-day work revolved
around the Microsoft Power Platform. Over the past few months, I began
writing about it here—sharing practical fixes for canvas app delegation,
complex formulas, SharePoint integrations, and automated flows.

However, the more I documented those enterprise processes, the more I
realized my core passion wasn't in low-code platforms. While internal business
tools solve real corporate problems, my true technical curiosity has always
belonged to full-stack web development.

Because of that, I'm making a deliberate shift: moving away from Power
Platform content and returning to my roots in modern WordPress engineering,
open-web architectures, and custom personal builds.

Here is why I'm making the change—and what I'll be sharing next.

1. Five Years in Managed Ecosystems vs. Open-Web Control

Spending nearly five years inside the Microsoft ecosystem taught me a lot
about rapid enterprise app delivery. But working exclusively within a vendor's
walled garden introduces hard limits on custom execution, data flow, and
long-term platform control.

Returning my focus to custom web development (especially modern setups using
Roots/Sage, Blade templates, Vite, and automated CI/CD pipelines) brings back
the exact aspects of engineering I enjoy most:

Total architectural control over data flow, markup, and application logic.
Direct performance tuning at the code level without vendor-imposed rules.
True open-source independence without licensing shifts or platform lock-in.

2. Modern WordPress Is a Superior Developer Experience

There is a common myth that WordPress development is stuck in the past. In
reality, modern custom theme and plugin development uses a toolchain that
matches top-tier web application engineering:

Clean templating using Blade and modern PHP features.
Instant asset compilation powered by Vite.
Streamlined developer workflows (using tools like Cursor and scoped MCP integrations) that handle repetitive boilerplate, freeing up time for architecture, accessibility, and speed optimizations.

Stepping back into custom WordPress builds reminded me how powerful, clean,
and rewarding web engineering can be when done with modern tools.

3. Building for the Web (Not Just Enterprise Specs)

Internal enterprise tools naturally focus on admin forms, internal workflows,
and corporate data entry. They serve a functional purpose, but they rarely
allow for creative experimentation with modern web APIs, public-facing user
experiences, or open-source software.

I want to spend my energy building and shipping personal web projects, such as:

Lightweight, speed-first custom WordPress plugins.
Modern theme starter stacks.
Full-stack experiments combining external APIs, modern UI, and AI workflows.

What Changes Here

No new Power Platform posts. The tutorials I published over the last few months will remain online for anyone who needs them, but my focus is moving on.
Deep-dive WordPress content. Expect practical guides on custom PHP architectures, Sage/Blade workflows, performance strategies, and modern developer tooling.
Build logs. I’ll be sharing the raw, honest engineering process behind the personal projects and tools I ship.

It took five years in the low-code world to realize how much I missed custom
web development, and I’m excited to be back in my element.

Are you building for the open web or refining your own dev stack right now?
Let's connect in the comments below.

5 Ways my new AI WordPress Workflow Actually Speeds up Development (and what it doesn't)

Matt Hummel — Wed, 02 Sep 2026 04:25:12 +0000

My AI WordPress workflow helps me finish the parts of a custom WordPress build I already know how to check. It does not replace the check.

I use Cursor inside a Sage (Roots) theme repository, ChatGPT and Claude for context/copy passes, n8n for form handling, GitHub Actions to build the theme zip, and Vite for asset compilation. Scaffolding, boilerplate, and first-pass Blade loops come back significantly quicker than they used to. Architecture, testing, and the final yes still sit with me.

Note on context: This post is a tool-by-tool breakdown of strengths, costs, and human steps—not a repeat of my previous workflow essay ("AI for WordPress Development: My Cursor, ChatGPT, n8n & MCP Workflow"). That post covers the loop; this one maps where each tool shines and where it costs.

What “Fast” Actually Means in Custom Dev

"Fast" is easy to sell. In practice, it means something much narrower: less time spent on work that does not require a human rewrite.

I won't claim a 10x multiplier or a shorter calendar on every project, nor that a model "wrote the site." The core benefit is clear: repeatable technical work shrinks, while accountability remains firmly human.

1. Repeatable Work Lessens

Renaming an ACF page field, wiring a new Vite entry point, drafting a standard Blade loop, or filling out a GitHub Actions workflow—these are predictable patterns. AI models excel here because I can immediately verify the output against a pattern I already know.

That accounts for most of the actual speed gain. It is real, but it is also easy to overstate.

2. Judgment Remains with the Developer

Deciding which plugin stays, whether a client editor can safely modify a layout field, catching contrast accessibility failures, or evaluating if a webhook belongs in the stack—that is judgment. Models guess based on statistical likelihood. I still own the call.

If I cannot explain every line at handoff, it does not ship. It's the same quality bar as a traditional build, just with less friction on the boilerplate.

The AI WordPress Tool Matrix

This isn't a tier list or a ranking. Each tool occupies a specific role in the build, incurs a specific trade-off, and demands a non-negotiable human review step.

Tool	Role / Best For	Weak At / Trade-Off	Non-Negotiable Human Step
Cursor	In-repo scaffolding, Blade templates, PHP helpers, refactoring.	Hallucinating WP core APIs or outdated package syntaxes.	Reading diffs line-by-line; testing logic in a real WP environment.
ChatGPT / Claude	Second-pass copy editing, off-repo structural brainstorming, regex.	Lacks direct codebase context; over-uses generic "agency voice."	Validating accuracy, editing tone, stripping unnecessary fluff.
n8n	External form handoff automation and webhook integration.	Silent failures if third-party endpoints rate-limit or change schemas.	Setting up fallback mail handlers (`wp_mail`) and monitoring logs.
Vite	Asset bundling, hot module replacement (HMR), asset compilation.	Requires strict entry point declarations in custom theme setups.	Auditing bundle sizes and verifying compiled output in browser.
GitHub Actions	Automated CI/CD, running Composer, building production zip releases.	Hidden pipeline costs or broken builds due to strict PHP/node mismatches.	Maintaining deployment secrets and controlling production triggers.
MCP (Model Context Protocol)	Giving agents scoped doors to external tools (database, terminal, APIs).	Risk of exposing elevated write access or leaking sensitive credentials.	Keeping scopes hyper-narrow; manually approving write operations.

How I Choose Tools per Task

I start from the job, not the model:

In-repo file edits (Sage/Roots theme): I open Cursor.
Drafting content or working outside the codebase: I use ChatGPT or Claude.
Handling form submissions and external payload routes: That is n8n.
Asset compilation & production releases: That belongs to Vite and GitHub Actions.
Connecting agents to real-time tools: MCP opens only when an agent needs a narrow doorway to an external utility.

A development shop doesn't need all of these active at once. You pick the right tool for the current step, followed immediately by human review.

How a Change Moves from Brief to Release

From a client brief to project handoff, the pipeline is short and predictable. AI models sit exclusively in the middle step—never at the boundaries.

[ Brief ] ──► [ Cursor / AI Draft ] ──► [ Human Review & Diffs ] ──► [ Vite & CI/CD ] ──► [ Production Handoff ]

Brief: A shop note, agency ticket, or custom brief. I write the technical constraints. A model did not take the job.
Cursor: Local scaffolding inside the Sage repository—Blade components, PHP helpers, Tailwind/CSS. ChatGPT/Claude assist with off-repo structural ideas. MCP is enabled only when an agent requires a specific, scoped tool.
Review: I inspect the Git diff. I execute the code on a real local page. Hallucinated APIs, unnecessary plugins, and fluff copy get eliminated here.
Vite & CI: Running npm run build locally, followed by GitHub Actions on push to main. The pipeline runs Composer, compiles assets, packages the production release zip, and tags theme-latest. PHP 8.3 serves as the runtime; WP-CLI remains the administrative interface.
Handoff: Configuring wp-admin fields for client editing, providing clean technical notes, and transferring the Git repository. If I cannot explain a piece of code, it does not get handed off.

Where n8n Sits: n8n is isolated from the theme's core code path. When a user submits a contact form, WordPress POSTs JSON to an n8n webhook. If that webhook fails, a native wp_mail fallback triggers. Automation handles the payload after submission—it does not author the theme.

What I Still Do by Hand

The list of manual tasks remains longer than the automated pipeline by design:

Architecture & Strategy: Deciding overall system structure—and what not to build.
Security & Access: Managing permissions, nonces, and governing what MCP servers can access.
Diff Auditing: Reviewing every single line in a pull request rather than trusting the commit summary.
Field & Cross-Device Testing: Validating themes on live page builds across desktop and mobile viewports.
Copy Tone: Ensuring the copy speaks clearly to clients and agencies without sounding like LLM jargon.
Accessibility (a11y): Verifying color contrast pairs, ARIA labels, semantic HTML hierarchy, and keyboard focus states.
Production Deployment Approval: Giving the final green light for production releases.

Standard VS Code is still part of my setup for times when I want to edit files without AI assistance. Keeping the review muscle sharp is critical.

FAQ

Does AI write the PHP I ship?

It drafts it; I review and ship it. Tools like Cursor, Claude, and ChatGPT help produce boilerplate PHP and initial template logic. However, I read, test, and take ownership of every line that hits production—including Vite pipelines, PHP 8.3 code, and GitHub Actions scripts.

Why is there no "overall winner" in this comparison?

Because they perform completely different functions. Cursor acts as the local code editor, ChatGPT/Claude handle off-repo reasoning, n8n routes form payloads, and GitHub Actions automates deployment zips. Ranking them against each other would be comparing apples to build servers.

Will an AI workflow like this replace a developer?

No. The cost of generating repeatable code dropped, but the cost of technical judgment did not change. Hiring an experienced developer means paying for code architecture, security verification, thorough testing, and long-term maintainability—not the speed of the prompt log.

What about data privacy and vendor lock-in?

Chat interfaces and MCP tools process whatever you pass to them. I mitigate risk by keeping write scopes minimal and removing secrets/keys from prompts. While Cursor, n8n, and GitHub represent distinct third-party dependencies, all code and review processes live inside standard Git repositories that can be migrated at any time.

How does this differ from a full workflow guide?

A workflow guide demonstrates how the ecosystem fits together during an active WordPress build. This post provides an explicit tool-by-tool comparison detailing strengths, trade-offs, and where human intervention remains mandatory.

Originally published on matthummel.com.

AI Website Redesign: 5 Lessons From a Solo Developer

Matt Hummel — Mon, 22 Jun 2026 15:51:15 +0000

I'll be honest with you: my website sat half-finished for a long time. Not because I didn't care about it, but because I'm a full-time Power Platform developer by day and a full-time dad the rest of the time. Between work and a house full of twins (and a cat who thinks he's in charge), "redesign my portfolio" kept sliding to the bottom of the list.

So I did something I'd been curious about for a while. I used AI to help me redesign on my portfolio as a one-person team. This post is the honest version of how that went — why I reached for AI, what it actually did, where it tripped up, and the lessons you can borrow for your own AI website redesign.

Why I used AI (when I'm just one person)

The short answer is time. The longer answer is that a solo dev wears every hat — designer, developer, writer, QA, and SEO person — usually after the kids are asleep.

Here's what pushed me to try it:

Time is my scarcest resource. A full-time job plus parenting doesn't leave long stretches for fiddling with CSS at midnight.
I'm a team of one. There's no designer to hand off to and no senior dev to review my work. AI became my second pair of eyes.
Context-switching is brutal. My day job is Power Platform, not front-end. AI helped me get back up to speed fast instead of relearning everything each time.
I wanted momentum. Small, finished wins beat a perfect plan I never start.

Turns out I'm not alone. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools — up from 76% the year before. AI has quietly become a normal part of how we build.

What AI actually did in the redesign

This wasn't "press a button, get a website." It was more like pair programming with a tireless junior who never gets bored of the fiddly stuff. A few real examples:

Fixed my responsive layouts. My columns refused to stack on mobile. AI found that the grids were styled inline and targeted them the right way, so the parent columns stacked without breaking the child grids.
Built a full-width gradient hero. The brand gradient kept hiding my content. The fix was putting the gradient on the outer row and making the inner column transparent — something I'd have spent an evening guessing at.
Solved a page-speed problem. My site got flagged for slow loading (Largest Contentful Paint). It turned out the slow element was my heading text waiting on a web font, not an image. One font-loading setting fixed it.
Handled the boring-but-important SEO. Meta titles, descriptions, slugs, and indexing — the stuff I always rush — got done properly.

If you want the technical background on that speed metric, Google's own Largest Contentful Paint guide is the clearest explanation out there (aim for 2.5 seconds or less).

5 lessons from my AI website redesign

If you take nothing else from this post, take these.

Diagnose before you fix. My biggest time-saver was making AI prove the cause before changing anything. The "slow page" was a font issue, not an image — guessing would have wasted hours.
Verify on the live page, not the editor. What the editor shows and what visitors actually see are two different things. Always check the real, published page.
Treat AI as a collaborator, not autopilot. I still made the calls. Fittingly, that same Stack Overflow survey found 46% of developers don't fully trust AI output — so review everything.
Make small, reversible changes. One labeled CSS block or one setting at a time. If something breaks, you know exactly what to undo.
Write down what worked. I kept a running playbook of fixes so future-me (or future-you) doesn't solve the same problem twice.

Trust, but verify: I read over everything

This is the part I won't skip, and you shouldn't either. AI is fast, but it's confidently wrong often enough that I treat every result as a draft, not a final answer.

Here's how I check accuracy before anything goes live:

I read every line of code and copy. If I don't understand why a change works, I ask until I do. No black boxes on my own site.
I test the real result. I load the live page and click around at different screen sizes instead of trusting a description of what "should" happen.
I fact-check claims and sources. Stats, links, and "best practices" get verified against primary sources before I publish them.
I sanity-check the SEO. Titles, descriptions, and slugs all get a human read for tone and accuracy, not just a green score.

The goal is simple: AI does the heavy lifting, but I'm accountable for what ships. Reviewing the output is where "using AI" turns into "using AI well."

Prompting is a skill worth practicing

The difference between a frustrating AI session and a productive one usually comes down to the prompt. Vague questions get vague answers. The more context and direction I give, the better the results.

A few habits that leveled up my prompting:

Be specific about the goal. "Make the columns stack on mobile and tablet, but don't change the inner grids" beats "fix the layout."
Give context. I mention the stack (WordPress, Kadence, SiteGround) so the answer fits my actual setup.
Ask for the cause, not just a fix. Telling AI to diagnose first leads to real solutions instead of guesses.
Iterate. I refine in small steps — "now make it responsive," "add padding to the buttons" — instead of demanding everything at once.
Set the standard. I tell it to keep things scannable, on-brand, and reversible so I don't have to redo the output.

Good prompting isn't magic words. It's clear thinking written down — and like any skill, it gets sharper the more you do it.

Troubleshooting: when AI got it wrong

It wasn't all smooth. The recurring snags were easy to fix once I knew them:

"My change didn't apply!" Nine times out of ten it was caching. Purge your cache before deciding a change failed.
Wrong element targeted. AI occasionally styled the wrong box. A quick look at the live page caught it every time.
Logged-in view fooled me. Admins bypass caching and optimizations, so test as a logged-out visitor for the real result.

Common mistakes to avoid

Letting AI publish or change settings without you reviewing first.
Bundling ten changes together, then not knowing which one broke the site.
Trusting the editor preview instead of the live page.
Skipping a backup or revision before a big edit.
Optimizing the thing you assume is slow instead of the thing you measured.

Your AI website redesign checklist

[ ] Write one sentence describing what "done" looks like.
[ ] Ask AI to diagnose and confirm the root cause first.
[ ] Make one small, reversible change at a time.
[ ] Purge the cache after each change.
[ ] Verify on the live page at mobile, tablet, and desktop widths.
[ ] Set your SEO (title, description, slug) before publishing.
[ ] Save what worked to a personal playbook.

The bottom line

AI didn't replace me — it gave a busy solo dev a way to actually finish things. As a full-time developer and full-time dad, that's the difference between a site that's "always almost done" and one that's live, fast, and something I'm proud of.

If you've been putting off your own redesign because there just aren't enough hours, this is your nudge: start small, let AI handle the heavy lifting, and keep your hands on the wheel.

Power Apps Project Planning: 7 Simple Steps to Build Better Apps

Matt Hummel — Fri, 22 May 2026 04:03:08 +0000

Learn Power Apps project planning before building your app. Use this beginner-friendly checklist to plan users, data, workflows, security, ALM, and success metrics.

Starting a new Power Apps project can be exciting.

You have an idea, you open Power Apps Studio, add a screen, connect a list, and start building. That is one of the best parts of Power Apps. You can go from an idea to something working pretty quickly.

But I have also learned that jumping in too fast can create problems later.

Sometimes the app starts simple, then suddenly you need approvals, different user roles, email notifications, admin screens, reports, and a better way to manage the data.

That is when a little planning helps.

You do not need a huge requirements document. Even a simple one-page plan can make the project easier to build, test, and support.

1. Start With the Problem

Before creating screens, write down the actual problem.

Instead of saying:

I need to build a request app.

Try something clearer:

Employees need a simple way to submit equipment requests, managers need to approve them, and admins need one place to track the status.

That one sentence gives the app more direction.

It tells you:

Who is using the app
What they are submitting
Who approves it
What needs to be tracked

A Power App does not need to solve every problem. It just needs to solve one process clearly.

2. Know Who Will Use the App

Next, list the people who will use the app.

Do not just say “users.” Break them into roles.

Role	What they need to do
Employee	Submit a request
Manager	Approve or reject a request
Admin	Review and update records
Leadership	View status or reports

Once you know the roles, it becomes easier to decide what each person should see.

The employee probably does not need the admin screen.

The manager probably only needs items waiting for approval.

The admin may need access to everything.

3. Look at the Current Process

Before building the new app, write down how the process works today.

Example:

Employee fills out a spreadsheet.
Employee emails it to a manager.
Manager replies with approval.
Admin copies the information somewhere else.
Someone manually sends status updates.

Once the current process is written down, the problems become easier to see.

Maybe approvals are getting buried in email.

Maybe people are copying the same data into multiple places.

Maybe nobody knows the current status.

4. Sketch the Future Process

Now write down what the new process should look like.

Example:

Employee submits the request in Power Apps.
The request is saved to SharePoint or Dataverse.
Power Automate sends the approval to the manager.
Manager approves or rejects it.
The request status updates automatically.
Employee gets a notification.
Admins can track everything in one place.

This gives you a simple roadmap before you build.

5. Plan the Data Before the Screens

This is one of the biggest lessons I have learned with Power Apps.

If the data is not planned well, the app gets harder to build.

Before adding too many screens, ask:

What information needs to be saved?
Will I use SharePoint or Dataverse?
What lists or tables do I need?
What should be a dropdown?
What should be a lookup?
Do I need attachments?
Do I need approval history?

For a request app, you might need:

List or table	What it stores
Requests	Main request information
Departments	Department names
Request Types	Dropdown options
Approval History	Approval actions and dates

For simple apps, SharePoint Lists may work fine.

For more structured apps with relationships, security roles, and more business logic, Dataverse may be a better option.

6. Write Down the Flows You Need

Most Power Apps projects eventually need Power Automate.

Even a basic app might need:

An approval email
A Teams message
A status update
A reminder
A confirmation email

I like to list the flows before building them.

Flow	What starts it	What it does
New request notification	A new request is submitted	Emails the manager
Approval update	Manager responds	Updates the request status
Reminder flow	Runs daily	Reminds managers about pending requests
Completion notice	Request is approved	Tells the employee

For each flow, ask:

What starts the flow?
What record does it update?
Who gets the email or message?
What should happen if something goes wrong?

7. Think About Permissions, Testing, and Launch

This part is not as fun as building screens, but it matters.

Before the app goes live, think through:

Can users see only their own records?
Can managers see their team’s records?
Can admins see everything?
Who can edit records?
Who can delete records?
Who will support the app after launch?

Also, have someone else test the app before calling it done.

You know where everything is because you built it. A new user may not.

Ask testers to try simple tasks:

Submit a request
Find the request
Approve or reject something
Check the status
Confirm they received a notification

If they get confused, that is useful feedback.

Helpful Resources

Here are a few resources that can help with Power Apps project planning:

Microsoft Power Apps planning module:

https://learn.microsoft.com/en-us/training/modules/plan-app-project/

Power Apps documentation:

https://learn.microsoft.com/en-us/power-apps/

Power Apps Plan Designer:

https://learn.microsoft.com/en-us/power-apps/maker/plan-designer/plan-designer

Power Platform ALM documentation:

https://learn.microsoft.com/en-us/power-platform/alm/

Power Platform Center of Excellence guidance:

https://learn.microsoft.com/en-us/power-platform/guidance/adoption/coe

Final Thoughts

Power Apps is great because you can build quickly.

But I have learned that a little planning makes the build much smoother.

You do not need to be a Power Platform expert. You do not need a perfect diagram. You do not need a giant requirements document.

You just need to slow down long enough to answer a few basic questions:

What problem am I solving?
Who is using the app?
What data do I need?
What should be automated?
Who can see or edit records?
How will I test it?
Who will support it later?

Start simple. Build the first useful version. Get feedback. Then improve it over time.

How to Debug a Blank Power Apps Gallery

Matt Hummel — Thu, 21 May 2026 01:11:21 +0000

A blank gallery in Power Apps does not always mean your app is broken. Most gallery issues come from one of these areas:

The Items property
A filter returning no records
A dropdown with no selected value
A search box filtering everything out
An empty collection
Delegation limits
Data source or permission issues

Start by Simplifying the Gallery

The first step is to strip the Items property down to just the data source:

'Project Requests'

If records show up, your connection is fine. The problem lives inside your filter logic.

Isolate the Filter

Add your filter back and watch what happens:

Filter(
    'Project Requests',
    Status.Value = "Approved"
)

If the gallery goes blank again, you know the issue is inside the filter itself — not the data source.

Handle Dropdown Filters with an "All" Option

Dropdowns with no selected value can silently filter out everything. Use an "All" fallback to prevent this:

Filter(
    'Project Requests',
    ddStatus.Selected.Value = "All" || Status.Value = ddStatus.Selected.Value
)

This way, when "All" is selected, every record passes through.

Debug Collections with a Count Label

If your gallery is backed by a collection, add a temporary label to check whether it actually loaded:

CountRows(colProjectRequests)

If that returns 0, the collection was never populated — check where Collect() or ClearCollect() is called and whether it runs on app start.

The Core Debugging Principle

Do not try to debug everything at once.

Start with the raw data source
Confirm records appear
Add each filter or condition back one step at a time

Isolating variables is how you find the real problem fast.

Power Apps Filter vs LookUp vs Collections (Quick Guide for Beginners)

Matt Hummel — Sat, 04 Apr 2026 15:18:14 +0000

If you're learning Power Apps, these three come up fast:

Filter
LookUp
Collections

They’re simple on their own — but easy to mix up.

Keep This Straight

Filter → multiple records (table)
LookUp → one record
Collections → stored data in memory

Most issues come from ignoring that.

Where Things Go Wrong

Common mistakes:

Using LookUp when multiple results exist
Using Filter when you only need one record
Storing everything in a collection “just in case”

The app might still work at first… then break later.

Quick Examples

Filter (for lists)
Filter(Requests, Status = "Approved")
LookUp (for one record)
LookUp(Users, Email = User().Email)
Common mistake
Filter(Users, Email = User().Email)

Now you’ve got a table, not a record — which complicates everything later.

Filter + LookUp LookUp( Filter(Orders, Status = "Pending"), OrderID = varOrderID ) Collections ClearCollect(colOrders, Orders)

Use when reusing data — not for everything.

Real Example That Breaks

LookUp(Approvals, Status = "Pending")

Works… until multiple records match.

Better:

Filter(Approvals, Status = "Pending")

Simple Rule

Need a list → Filter
Need one record → LookUp
Need to store data → Collections

Final Thought

Most issues aren’t complicated — just small misunderstandings early on.

And your app will usually still work… until it doesn’t.

🔗 Full Post

[https://bit.ly/filter-lookup]

💬 Question

What’s something confusing you’ve run into with Filter or LookUp?