DEV Community: WPVibes

How to Save Contact Form 7 Submissions to Google Sheets

WPVibes — Thu, 20 Aug 2026 12:36:12 +0000

Every Contact Form 7 submission lives in exactly one place: your inbox. If that email lands in spam, or your SMTP setup breaks for a day, that submission is gone. There's no second copy anywhere, because Contact Form 7 was never built to store data at all.

This guide fixes both problems at once. Form Vibes Pro connects Contact Form 7 to Google Sheets automatically, and saves every submission to your WordPress database at the same time. No automation platform, no per-task limits, and no more relying on a single email that might not arrive.

Does Contact Form 7 Save Submissions Anywhere on Its Own?

No. Contact Form 7 sends every submission by email and nothing else. There's no entries table in your WordPress dashboard, no export button, and no built-in backup if that email fails to arrive.

This is intentional. Contact Form 7 was designed to be lightweight, and email-only delivery is part of that design. But it means the only record of a submission is whatever lands in an inbox. A spam filter, a broken SMTP connection, or someone accidentally deleting an email can permanently erase a lead with no way to recover it.

This is exactly the gap Form Vibes closes. Every submission gets saved to your WordPress database the moment it comes in, and from there it can also sync straight to a Google Sheet.

Is Google Sheets Sync a Free or Pro Feature?

Google Sheets sync is a Form Vibes Pro feature. Here's what's relevant to this guide:

Feature	Free	Pro
Save Contact Form 7 entries to WordPress database	Yes	Yes
Export to CSV	Yes (up to 1,000 rows)	Yes (unlimited)
Sync to Google Sheets	No	Yes
Filter which submissions get synced	No	Yes

How to Connect Contact Form 7 to Google Sheets

To keep this concrete, we'll set this up for a simple RSVP form with four fields: your-name, your-email, your-event-date, and your-guest-count. Your own form's field names will be different, but the steps are the same.

Create Your Google API Credentials

Google requires API credentials, so Form Vibes can communicate securely with your Google account. These consist of a Client ID and a Client Secret, generated in Google Cloud Console. The full credential creation process is covered in a dedicated guide. Follow that guide to generate your Client ID and Client Secret, then return here to continue.

Connect Form Vibes to Google Sheets

Go to Form Vibes > Settings > Google Sheet in your WordPress admin. Paste your Client ID and Client Secret into their respective fields. Click Authenticate and sign in with your Google account when prompted. After approving the requested permissions, the connection status updates to show the account as connected.

💡
During authentication, Google shows an "App is not verified" warning. This is expected for a self-configured OAuth connection, and Google's own documentation confirms this is normal for unverified apps. Click Show Advanced, then Go to App, and approve all requested permissions. The connection completes normally.

Set Up the Google Sheets Connection for Your CF7 Form

With your Google account connected, go to Form Vibes > Export Profiles and click Add New. Under Type, select Google Sheet instead of Local Download. This tells Form Vibes to push submissions to a spreadsheet rather than generate a downloadable file.

Choose the Form, Spreadsheet, and Worksheet

On the Data Source tab, select your RSVP form from the Form dropdown. Since Contact Form 7 doesn't have a visual field builder, this dropdown lists the form's admin title, such as "Event RSVP Form," not the individual field tags. Forms appear here once they've received at least one submission.

Choose the Google Spreadsheet where data should be sent. If the spreadsheet you need does not appear, check that the connected Google account has access to it. To create a new spreadsheet directly from Form Vibes, click the plus icon next to the spreadsheet selector.

Select the specific worksheet, or tab, within the spreadsheet. Create a new one using the plus icon if needed.

Then, you will be asked to map the columns to your Google Sheet. Click the "Click here" option to start mapping the columns.

If you want to use custom column headers in the sheet, you can enter the desired names here and map them to the corresponding form fields. For example, you can set the column header Name and map it to the your-name form field.

The Data Filter section lets you sync only the submissions that match specific conditions, instead of sending every submission to Google Sheets. This step is optional. Skip it if you want every RSVP synced.

Map Your Fields on the Columns Mapping Tab

Switch to the Columns Mapping tab. If you want to change the default column mapping or assign a specific form field to a particular spreadsheet column, you can do it here.

After that, map each spreadsheet column to the appropriate Contact Form 7 field. Click Publish to save and activate the connection.

What Happens After Someone Submits Your Contact Form 7 Form?

Once the connection is published, no further action is needed. When a guest submits the RSVP form, Form Vibes saves their name, email, event date, and guest count to your WordPress database, and immediately pushes a new row with those same details to the connected Google Spreadsheet.

The row appears within moments. Anyone with access to the spreadsheet can see the new RSVP without logging into WordPress. Where before this data only existed in an email you might never open, it now lives in two places at once.

Why Aren't Contact Form 7 Submissions Reaching Google Sheets?

The most common cause with Contact Form 7 specifically is a field name mismatch, since CF7 tags are typed by hand rather than picked from a visual list. Beyond that, submissions can also fail to sync because a form isn't yet listed in the dropdown, the connected account can't access the spreadsheet, there's a redirect URI mismatch, or the Google Sheets and Drive APIs aren't enabled. Submit a test RSVP from the frontend first, then check the causes below.

Data is appearing in the wrong columns, or not at all. Open the Export Profile and compare each mapped field against the actual tag names in your Contact Form 7 form editor. A field written as your-eventdate in the form but mapped as your-event-date in Form Vibes will fail silently. Retype the mapping to match exactly.

The Contact Form 7 form is not showing in the Form dropdown. Confirm Contact Form 7 is active. Then confirm the form has received at least one submission on the frontend since Form Vibes was activated. Form Vibes only lists forms that have already received at least one submission.

Spreadsheet is not showing in the dropdown. Check that the Google account connected in Form Vibes Settings has access to the spreadsheet. If the spreadsheet is owned by a different Google account, share it with the connected account before trying again.

Redirect URI mismatch error. The redirect URI entered in your Google Cloud Console app settings must match exactly the one Form Vibes provides. Open your Google Cloud Console project, navigate to OAuth credentials, and verify the redirect URI matches the one shown in Form Vibes Settings.

Google Sheets and Drive APIs are not enabled. Both APIs must be enabled inside your Google Cloud Console project. If sync silently fails and the field mapping checks out, this is usually the cause.

App verification warning during authentication. This is expected for self-configured OAuth apps and does not indicate a problem. Click Show Advanced, then Go to App, and approve all permissions.

Why Form Vibes for Contact Form 7 and Google Sheets?

It starts you from zero, not from a smoother sync. Some plugins improve on a feature Contact Form 7 already has. Contact Form 7 has nothing to improve on here. It has no entries table and no storage of any kind, so Form Vibes is the entire foundation, not an upgrade to one.
Every submission is also saved to your WordPress database. So a temporary Google API hiccup, or a sync that hasn't run yet, never means the data is lost. It's already sitting in WordPress.
One plugin for nine form builders. If you use Contact Form 7 alongside Elementor Forms or WPForms, one Form Vibes install handles all of them. No second connector plugin, no second Google configuration. Setting up Elementor forms with Google Sheets works exactly the same way.
Notes, submission status, analytics, and a role manager included, none of which Contact Form 7 has on its own.

Conclusion

Contact Form 7 was built to be lightweight, and that means it stores nothing on its own. One missed email is the only thing standing between a submission and losing it for good. Form Vibes Pro closes that gap completely: every entry is saved to your WordPress database and synced to Google Sheets automatically, so a single inbox is never the only record you have.

Frequently Asked Questions

Does Contact Form 7 have a built-in Google Sheets integration?

No. Contact Form 7 sends submissions by email only and has no built-in database, export option, or Google Sheets connection. A plugin like Form Vibes Pro is required to sync submissions to a spreadsheet.

Do I need Form Vibes Pro to connect Contact Form 7 to Google Sheets?

Yes. The Google Sheets integration is a Form Vibes Pro feature. The free version still saves every Contact Form 7 submission to your WordPress database and lets you export to CSV on demand. The automatic real-time push to Google Sheets is the Pro upgrade.

What if my Contact Form 7 field names don't match my sheet's column headers?

Nothing will sync correctly until they match. Since Contact Form 7 fields are typed manually rather than chosen from a visual list, open the Export Profile's Columns Mapping tab and compare each field tag against your actual form editor. Fields like your-event-date and your-eventdate look similar but won't map to each other automatically.

Can I sync multiple Contact Form 7 forms to different Google Sheets?

Yes. Set up one Export Profile per Contact Form 7 form, and point each one to its own spreadsheet or its own worksheet inside the same spreadsheet. There's no limit on how many forms you can connect.

Can I filter which Contact Form 7 submissions get sent to Google Sheets?

Yes. The Data Filter section supports Equal, Not Equal, Contain, and Not Contain conditions, and lets you choose whether any or all conditions must match. Filtered-out submissions still get saved to your WordPress database; the filter only affects what reaches Sheets.

Does the same integration work with my other form plugins?

Yes. The Google Sheets sync in Form Vibes Pro works with Elementor Forms, WPForms, Gravity Forms, Ninja Forms, WS Form, Bricks Builder forms, Beaver Builder forms, and Everest Forms, alongside Contact Form 7. One plugin, one Google connection, all your forms.

What's New in WordPress 7.1: Tab Block, Responsive Design, Pseudo States, and much more

WPVibes — Mon, 17 Aug 2026 06:31:09 +0000

WordPress 7.1 comes out on August 19, 2026. It's the second major WordPress release this year. Instead of one headline feature, this release focuses on improving the entire editing experience: responsive design controls, interactive state styling, better media handling, new blocks, editor usability improvements, and a few developer-focused APIs.

Whether you're a site owner, content creator, theme developer, or plugin developer, WordPress 7.1 has something that makes building and managing your site faster and more flexible.

This guide walks through every major feature coming in WordPress 7.1, what it does, and why it matters.

How Does WordPress 7.1 Change the Way You Design Pages?

WordPress 7.1 lets you style how a block looks on different screen sizes and how it reacts to a mouse or keyboard, directly in the editor, without writing a line of CSS. This is the headline feature of the release.

Responsive Styling Comes to the Block Editor

WordPress 7.1 introduces responsive styling directly inside the editor, allowing you to customize how blocks look across different screen sizes without writing CSS.

Depending on the block, you'll be able to configure different values for typography, spacing, layout, dimensions, and other design settings across various screen sizes. This gives much greater control over how your content appears on different devices while keeping the editing experience visual and intuitive.

To use it, select a block, then click the view icon. Choose responsive styling, then pick the device you want to design for: desktop, tablet, or phone. You can make a heading larger on desktop and smaller on mobile, all from the same panel.

💡
Tips: If you're exploring modern WordPress editing capabilities, check out our guide on PHP-only blocks in WordPress 7.0 to see how block development is becoming simpler for developers.

Style Every State Without CSS

Until now, changing how a button or link looks on hover meant writing custom CSS. WordPress 7.1 adds visual controls for these interactive pseudo states, so you can style them directly in the editor.

You can switch between states(Hover, Focus, Focus-Visible, and Active) and set a different color, border, background, shadow, or typography for each one. This makes it easier to build engaging interfaces while also improving accessibility.

A new "State" option lets you set a different style for when someone hovers over a button, tabs into it with a keyboard, or clicks it. The preview updates live as you work.

💡
Notes: Hover and focus control is only available on the Button block and the Navigation Link block.

What's New With the Notes Feature in WordPress 7.1?

Notes in WordPress 7.1 lets you leave feedback on a specific piece of text instead of an entire block, so a comment no longer needs a Slack message to explain which sentence it's about. The feature first appeared in WordPress 6.9, and this release makes it genuinely usable for day-to-day editorial work.

You can now attach a note to a specific selection of text instead of an entire block, so feedback points at exactly the phrase you mean. Notes support rich formatting: bold (Ctrl/⌘ + B), italics (Ctrl/⌘ + I), links (Ctrl/⌘ + K), and emojis, so a note can actually explain itself instead of reading like a plain-text scrap.

Type "@" inside a note and a list of your site's users pops up, letting you tag a specific collaborator, who then gets an email notification linking straight back to the post.

You can also leave more than one note on the same block, which matters if two different people are commenting on two different things in the same paragraph. Long notes collapse by default with a "Show more" toggle, so a detailed note doesn't take over the sidebar.

How Does Client-Side Media Processing Speed Up Your Uploads?

With client-side media processing, WordPress 7.1 moves image processing out of your server and into the browser. Previously, when you uploaded an image, your server had to generate every thumbnail size, handle format conversion, and fix rotation using PHP. Now the browser does that work instead, using a fast, established image library called libvips running right inside your browser, and sends the finished files to WordPress.

The practical upshot: fewer failed uploads on large image files, since you won't hit your host's PHP memory limit mid-upload. Your server also does less work overall, since it's no longer generating every thumbnail size itself. And because the browser's processing produces better-compresse

Two upload types get a real, visible improvement:

Animated GIFs you upload are automatically converted into lightweight video files (using the same kind of technology your browser already uses to play video), so a GIF that used to weigh down your page loads much lighter without you doing anything differently.
HEIC photos, the default format iPhones use, are automatically converted to JPG before upload. You no longer need a plugin just to make iPhone photos work on your site.

Alongside this, the Media Library grid now scrolls infinitely by default instead of paginating, so you can keep scrolling through your library instead of clicking "next page" repeatedly. If you'd rather have the old paginated view back, there's a toggle for it in your user profile settings.

What New Blocks Does WordPress 7.1 Add?

WordPress 7.1 adds two brand new blocks.

Tabs Block

The Tabs block organizes content into clickable panels, letting a visitor click between sections instead of scrolling through a long page. It's a natural fit for FAQs, product comparisons, or any content with a handful of parallel options.

Each tab panel can hold any other block inside it, not just text. You can drop in images, buttons, columns, galleries, or even another Tabs block, so a tab isn't limited to a paragraph.

The tabs themselves are fully styleable. You can set the color, typography, and spacing for the tab buttons, and control the overall look of the tab panel separately, so the whole block can match your site's design.

Playlist Block

The Playlist block lets you embed a simple audio playlist, complete with a waveform visualization that shows the shape of each track. It supports whatever audio file types WordPress already accepts.

The playlist itself has several toggles you can turn on or off: showing the tracklist, artist names, track numbers, track duration, tracklist images, and whether the track image appears on the play button. You can also set the track order to ascending or descending.

Each track has its own settings: artist, album, title, and a track image, so every song in the playlist can show proper metadata and cover art instead of a generic placeholder.

On the styling side, the block has its own controls for the block and the waveform background, and their shape, so the playlist can match your site's design rather than looking like a generic embed.

What's New for the Icon Block in WordPress 7.1?

WordPress 7.1 opens up the Icon block to icon sets beyond WordPress's own defaults, and gives the Icon block itself a few small but useful upgrades.

Custom SVG Icons API

One of the biggest developer-focused additions in WordPress 7.1 is the new Custom SVG Icons API.

Previously, developers who wanted custom icons often had to register them using JavaScript, build custom icon libraries, or depend on third-party solutions. WordPress now provides an official API for registering and managing SVG icon collections.

Developers can register icons individually or as complete collections and make them available throughout the Block Editor. Once registered, these icons can be used in custom blocks, plugins, themes, and the Icon Block itself.

If you build WordPress plugins and want the full technical walkthrough, including a working example plugin, see our complete guide on registering custom SVG icons in WordPress 7.1.

Icon Block Toolbar Improvements

The Icon block itself picked up a few smaller improvements too: newly inserted Icon blocks now start with a default icon instead of an empty placeholder, and the toolbar has new controls to flip an icon horizontally or vertically, or rotate it 90 degrees at a time.

What Else Changed in the WordPress Admin?

A handful of smaller changes add up to a more consistent day-to-day experience.

The admin toolbar now appears inside the post editor and the Site Editor for the first time. Previously, opening either editor made the toolbar disappear entirely, and the only way back to the dashboard was clicking the "W" logo in the editor's own toolbar, which didn't read as a back button to most people.

WordPress 7.1 fixes both problems: the editor toolbar now has a proper back button (a left-pointing chevron), and the admin toolbar itself shows your site's icon.

The Site Editor sidebar finally matches whatever admin color scheme you've chosen in your profile, instead of always defaulting to black regardless of your preference.

There's also a new Identity section under Design in the Site Editor, grouping your site title, tagline, logo, and icon in one place instead of scattering them across Settings and templates.

What Other Small Improvements Should You Know About?

A few smaller design tools rounded out this release. None of these are big enough for their own section, but they're worth knowing about.

Text-shadow support: You can now add a text shadow through Global Styles. It's an early implementation, currently only configurable through theme.json rather than a visual control, so it's more useful to theme developers than to someone editing a single post today.
Background gradients: Several blocks (Group, Accordion, Pullquote, Post Content, and Quote) now support background gradients by default, controllable right in the block settings.
Minimum width: Blocks can now have a minimum width set, alongside the existing height and width controls.

What Developer Experience Improvements Does WordPress 7.1 Bring?

Beyond visual improvements, WordPress 7.1 introduces several enhancements aimed at developers.

Better Block Bindings

Block Bindings already let you connect a block's content, like a Heading, Paragraph, or Button, to a dynamic data source such as a custom field, without writing rendering code. WordPress 7.1 extends that same capability to list items, so a bullet or numbered list can pull from a data source too.

Expanded Abilities API

The Abilities API, which lets WordPress expose specific actions to AI tools and other integrations, picks up better filtering, validation, and a clearer way to mark an ability as publicly available.

If you're building AI-connected features or automations on top of WordPress, this makes those integrations more reliable and easier to control. See our Abilities API + MCP guide for the full guide.

Final Thoughts

WordPress 7.1 is a design and collaboration release: responsive styling and hover states without touching CSS, Notes that finally feel built for teams, faster image handling for supported browsers, and two genuinely useful new blocks. None of it demands a relearning curve, but the responsive and interactive styling controls alone are worth exploring the moment you update.

Keep an eye on your usual update workflow: back up first, test on staging if you run custom blocks or older plugins, then roll it out.

Frequently Asked Questions

When will WordPress 7.1 be released?

WordPress 7.1 is scheduled for release on August 19, 2026. If you're running a production website, it's a good idea to test the update on a staging site first, especially if you use custom themes or plugins.

Does WordPress 7.1 support real-time, multi-person editing?

No. WordPress 7.1 focuses on asynchronous collaboration through the upgraded Notes feature. Two people editing the same post at the same time, Google Docs style, is not part of this release.

What is the Custom SVG Icons API in WordPress 7.1?

The Custom SVG Icons API is a new developer feature that provides a standardized way to register and manage custom SVG icon collections. Developers can register individual icons or entire icon libraries and use them throughout the Block Editor.

Does WordPress 7.1 require a new minimum PHP version?

WordPress 7.1 doesn't introduce a new PHP requirement beyond what WordPress 7.0 already set. If your site runs comfortably on 7.0, it will run on 7.1.

Custom SVG Icons: An Exciting WordPress 7.1 Feature

WPVibes — Thu, 13 Aug 2026 06:35:51 +0000

For years, adding a custom icon to the block editor meant reaching for JavaScript, a build step, or a workaround that only half-worked. WordPress 7.1 is about to change that.

A new public API for custom SVG icons is landing in the next release. You'll be able to register your own icons, group them into named collections, and have them show up in the core/icon block picker, render server-side in PHP, and appear over the REST API, all from a plugin, with no JavaScript build step at all.

This guide walks through building a small plugin called wpvibes-custom-icons that registers a collection, adds icons two different ways (inline SVG and file paths), and shows how to use those icons in the block editor, in PHP templates, and as custom block icons. The complete plugin is on GitHub.

WordPress 7.1 releases on August 19, 2026. The code below matches what's expected to ship on release day, and we'll come back and verify every detail against the final build once it's out.

What You'll Build

A wpvibes-custom-icons plugin with a registered icon collection called wpvibes
Three ready-to-use icons: a heart (registered inline), a star, and a bookmark (both registered from .svg files)
A bulk registration pattern that reads every SVG file from a folder and registers each one automatically
A practical shortcode for inserting any registered icon into post content
Real integration with our PHP-only blocks guide, using a custom icon as a block icon

Prerequisites

WordPress 7.1 or later (7.1 RC works for development)
A few SVG icon files (or use the ones provided below)
Local development environment (LocalWP, WordPress Studio, wp-env)
Basic PHP knowledge

Step 1: Understand the API in Three Minutes

WordPress 7.1's custom icons API has three main functions and one organizing concept.

The functions:

wp_register_icon_collection( $name, $args ): register a named group of icons
wp_register_icon( $name, $args ): register a single icon
wp_get_icon( $name, $args ): render an icon's SVG in PHP (returns the SVG string)

The organizing concept: collections. Every icon belongs to a collection. The collection name becomes a prefix for every icon inside it, which is what makes core/plus different from wpvibes/plus. This keeps custom icons from colliding with core icons or with other plugins.

Two ways to provide the SVG when registering:

content: the SVG markup as a string, embedded directly in PHP
file_path: an absolute path to an .svg file on disk

Use one or the other per icon, not both. Inline content is handy for one or two icons; file_path scales better for a folder of many.

That's the API. Now let's build with it.

Step 2: Set Up the Plugin and Register the Collection

While building this, one thing became clear quickly: the collection has to be registered before you can add icons to it. If you try to register an icon whose collection doesn't exist yet, the icon silently fails to appear in the picker.

Create a folder inside wp-content/plugins/:

wpvibes-custom-icons/
├── wpvibes-custom-icons.php
└── icons/
    ├── star.svg
    └── bookmark.svg

Create wpvibes-custom-icons.php with the plugin header and the collection registration:

<?php
/**
 * Plugin Name: WPVibes Custom Icons
 * Description: Register custom SVG icons for WordPress 7.1+.
 * Version:     1.0.0
 * Author:      WPVibes
 * Requires at least: 7.1
 * Requires PHP: 7.4
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

define( 'WPVIBES_ICONS_PATH', plugin_dir_path( __FILE__ ) );

/**
 * Step 1: Register the icon collection.
 */
add_action( 'init', 'wpvibes_register_icon_collection' );

function wpvibes_register_icon_collection() {

    wp_register_icon_collection(
        'wpvibes',
        array(
            'label' => __( 'WPVibes', 'wpvibes-icons' ),
        )
    );
}

The collection name (wpvibes) becomes the prefix for every icon that follows: wpvibes/heart, wpvibes/star, and so on. The label is what shows up as a section heading in the icon picker.

Activate the plugin from Plugins → Installed Plugins. Nothing to see yet, since collections don't render until they contain icons.

Step 3: Register Icons Two Ways

WordPress supports two ways to register an icon. This step uses both: the inline content method for the heart icon, and the file_path method for star and bookmark.

3.1: Register an inline icon with content

The heart SVG lives directly in the PHP file. Useful when there's just one or two icons and you don't want extra files.

Add this to wpvibes-custom-icons.php:

/**
 * Step 2: Register icons using inline SVG content.
 */
add_action( 'init', 'wpvibes_register_inline_icons', 20 );

function wpvibes_register_inline_icons() {

    wp_register_icon(
        'wpvibes/heart',
        array(
            'label'   => __( 'Heart', 'wpvibes-icons' ),
            'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M20.84 4.61a5.5 5.5 0 0 0-7.78 0L12 5.67l-1.06-1.06a5.5 5.5 0 0 0-7.78 7.78l1.06 1.06L12 21.23l7.78-7.78 1.06-1.06a5.5 5.5 0 0 0 0-7.78z"/></svg>',
        )
    );
}

How the code flows:

The action hooks into init at priority 20, which is later than the collection registration (default priority 10), so the collection exists before the icon tries to join it.
The icon name wpvibes/heart follows the pattern collection/icon-slug.
The label shows in the icon picker; content holds the SVG markup.
The SVG uses stroke="currentColor" so the icon inherits color from surrounding text, with no hardcoded fill.

3.2: Register icons from `.svg` files

For icons stored on disk, use file_path instead. Save these two files in the icons/ folder:

icons/star.svg:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
    <polygon points="12 2 15.09 8.26 22 9.27 17 14.14 18.18 21.02 12 17.77 5.82 21.02 7 14.14 2 9.27 8.91 8.26 12 2"/>
</svg>

icons/bookmark.svg:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
    <path d="M19 21l-7-5-7 5V5a2 2 0 0 1 2-2h10a2 2 0 0 1 2 2z"/>
</svg>

Now register both from PHP:

/**
 * Step 3: Register icons from .svg files.
 */
add_action( 'init', 'wpvibes_register_file_icons', 20 );

function wpvibes_register_file_icons() {

    wp_register_icon(
        'wpvibes/star',
        array(
            'label'     => __( 'Star', 'wpvibes-icons' ),
            'file_path' => WPVIBES_ICONS_PATH . 'icons/star.svg',
        )
    );

    wp_register_icon(
        'wpvibes/bookmark',
        array(
            'label'     => __( 'Bookmark', 'wpvibes-icons' ),
            'file_path' => WPVIBES_ICONS_PATH . 'icons/bookmark.svg',
        )
    );
}

Same registration function, same collection. Only content becomes file_path. WordPress reads the file on demand.

Now open the core/icon block in the editor. The picker shows a new WPVibes section with Heart, Star, and Bookmark. Insert any of them.

💡
Notes: If an icon doesn't appear, the most common cause is registering the icon before the collection exists. Make sure the collection is registered first (default priority), and the icons are registered after (priority 20 in the examples above).

Step 4: Register a Whole Folder of Icons (Bulk Pattern)

For a real icon library, registering one icon at a time doesn't scale. Nobody writes 30 wp_register_icon() calls by hand. The practical pattern: drop SVGs into a folder, and let PHP auto-register everything on the next request.

Replace the individual wpvibes_register_file_icons() function with this bulk version:

add_action( 'init', 'wpvibes_register_all_file_icons', 20 );

function wpvibes_register_all_file_icons() {

    $icons_dir = WPVIBES_ICONS_PATH . 'icons/';
    $svg_files = glob( $icons_dir . '*.svg' );

    if ( empty( $svg_files ) ) {
        return;
    }

    foreach ( $svg_files as $file_path ) {

        $slug  = basename( $file_path, '.svg' );
        $label = ucwords( str_replace( '-', ' ', $slug ) );

        wp_register_icon(
            'wpvibes/' . $slug,
            array(
                'label'     => $label,
                'file_path' => $file_path,
            )
        );
    }
}

Code flow in plain words:

glob( $icons_dir . '*.svg' ) returns every .svg file in the folder.
basename( $file_path, '.svg' ) takes just the filename without extension, so advanced-button.svg becomes advanced-button.
ucwords( str_replace( '-', ' ', $slug ) ) turns the slug into a readable label: advanced-button becomes "Advanced Button" for the picker.
The loop registers each icon under the wpvibes/ collection.

Drop any new SVG into the icons/ folder, refresh the editor, and it appears in the picker. No code changes needed.

This is the pattern used to register the WPVibes icon library. The same six lines register the entire icon set: heart (registered inline earlier), star, bookmark, and any additional icons dropped into the folder.

Step 5: Use the Icons in Three Places

Once icons are registered, three places automatically get access to them. Here's each one with a small example.

5.1: In the core/icon block

The core/icon block picker automatically shows every registered collection. Users insert the block, pick a WPVibes icon, and it renders on the frontend. No extra code needed.

Icons also appear at the REST endpoint /wp-json/wp/v2/icons (with a companion /wp-json/wp/v2/icon-collections endpoint for collections), for any external tool that reads WordPress data.

5.2: In PHP via wp_get_icon()

The wp_get_icon() function returns an icon's SVG as a string. The simplest form:

echo wp_get_icon( 'wpvibes/heart' );

For real templates, pass a second argument to control size, class, and accessibility:

echo wp_get_icon(
    'wpvibes/star',
    array(
        'size'  => 32,
        'class' => 'featured-icon',
        'label' => __( 'Featured', 'wpvibes-icons' ),
    )
);

size sets the SVG's width and height in pixels
class adds a CSS class to the SVG element
label sets aria-label for screen readers

A practical shortcode example. Here's a small [wpvibes_icon] shortcode that lets anyone drop an icon into post content:

add_shortcode( 'wpvibes_icon', 'wpvibes_icon_shortcode' );

function wpvibes_icon_shortcode( $atts ) {

    $atts = shortcode_atts(
        array(
            'name'  => 'heart',
            'text'  => '',
            'size'  => 24,
            'class' => '',
        ),
        $atts
    );

    $icon = wp_get_icon(
        'wpvibes/' . sanitize_key( $atts['name'] ),
        array(
            'size'  => absint( $atts['size'] ),
            'class' => sanitize_html_class( $atts['class'] ),
        )
    );

    if ( ! $icon ) {
        return '';
    }

    return sprintf(
        '<span class="wpvibes-icon-inline">%s %s</span>',
        $icon,
        esc_html( $atts['text'] )
    );
}

Use it inside any post, page, or widget:

[wpvibes_icon name="heart" text="Hello World"]

[wpvibes_icon name="star" text="Featured post" size="32"]

[wpvibes_icon name="bookmark" text="Save for later" size="20"]

The icon appears next to the text, sized to whatever the size attribute says. Because the SVG uses currentColor, the icon picks up the surrounding text color automatically.

5.3: As a custom block icon in register_block_type()

Custom icons can replace the default Dashicon in any block registration. In our PHP-only blocks guide, block icons look like this:

'icon' => 'warning',   // Uses a Dashicon

With WordPress 7.1 custom icons, that becomes:

'icon' => 'wpvibes/star',   // Uses a registered custom icon

The block inserter now shows the branded WPVibes icon instead of a generic Dashicon. This works for both JavaScript-registered blocks and PHP-only blocks.

Same registration function, three consumer contexts. This "register once, use everywhere" pattern is the same architecture used by WordPress's Abilities API, a good sign that WordPress is heading toward a genuinely consistent developer story across its foundational APIs.

Step 6: Style Custom Icons with CSS

Custom icons look native by default, but real integration means they adapt to their surroundings: inheriting text color, scaling with font size, changing appearance on hover.

The class argument passed through wp_get_icon() (shown in Step 5.2) already covers the standard case of adding a CSS hook to the SVG. This section covers what to do with that hook, plus patterns that work everywhere the icon appears, including in the block editor where the class argument isn't in play.

6.1: Use currentColor for color inheritance

The single most important pattern in SVG design: use stroke="currentColor" (or fill="currentColor") instead of hardcoded colors.

<!-- ❌ Hardcoded color: icon always red -->
<svg viewBox="0 0 24 24" 
stroke="#dc2626" 
stroke-width="2">    

<path d="..."/></svg>

With currentColor, an icon inside red text renders red. Inside a dark theme, it renders dark. Inside a link, it matches the link color. The SVG behaves like text.

This is why the icons in our library ship without hardcoded colors. It's the difference between an icon that fits any theme and one that clashes with half of them.

6.2: Override color when a specific color is needed

Sometimes an icon must be a specific color regardless of surroundings, like a brand mark or a status indicator. Use CSS to force it:

.featured-icon {
    color: #f59e0b;   /* Amber, regardless of surrounding text */
}

Because the SVG uses currentColor, setting color on the SVG (via the class from Step 5.2) cascades into its stroke or fill. The icon renders amber even inside dark text.

6.3: Size and hover states

For icons rendered through the shortcode or wp_get_icon(), the size argument handles pixel sizing directly. For CSS-controlled sizing or hover states:

.wpvibes-icon-inline svg {
    transition: transform 0.15s ease-in-out;
}

.wpvibes-icon-inline:hover svg {
    transform: scale(1.1);
}

6.4: When to use CSS classes vs. the `size` argument

Use size in wp_get_icon() for one-off cases where the exact pixel size matters and there's no reason to write CSS.
Use CSS classes (via the class argument, or on the wrapper element) when the icon appears in many places and should stay consistent, or when styling depends on state (hover, focus, active) or context (inside a link, inside a heading).

For the shortcode example in Step 5.2, both approaches work. Small tweaks per shortcode use the size attribute; site-wide consistency uses CSS on .wpvibes-icon-inline svg.

Step 7: Remove Icons and Collections

WordPress 7.1 ships two matching functions for unregistering: one for a single icon, one for a whole collection.

7.1: Remove a single icon

Useful during development, or when a plugin update drops an icon:

wp_unregister_icon( 'wpvibes/bookmark' );

The icon disappears from the picker on the next request. Any post that already inserted this icon in a core/icon block will render empty (WordPress doesn't rewrite post content).

7.2: Remove the entire collection on deactivation

When the plugin is deactivated, all its icons should stop appearing in the picker. Unregistering the collection removes every icon inside it in one call:

register_deactivation_hook( __FILE__, 'wpvibes_unregister_icons' );

function wpvibes_unregister_icons() {

    wp_unregister_icon_collection( 'wpvibes' );
}

No need to loop through individual icons. The collection cleanup handles it all.

Get the Full Plugin

The complete wpvibes-custom-icons plugin, with sample SVGs, README, and the full bulk registration pattern, is on GitHub.

How Custom Icons Fit the Bigger Picture

WordPress 7.1's custom icons follow the same architectural pattern as the Abilities API and the PHP-only blocks guide covered earlier: register once, use everywhere. The core/icon block reads from the registry, wp_get_icon() reads from the same registry in PHP, and the REST API exposes it to external tools including AI agents.

WordPress is deliberately building foundational APIs, abilities, icons, block bindings, that follow the same register-once, discoverable-everywhere pattern. Plugin authors who invest in these APIs get their code integrated into the editor, the REST layer, and any tool built on the WordPress data model. Icons look like a small feature on the surface. Underneath, they're another piece of a much bigger shift in how WordPress plugins get built.

Wrapping Up

This is a small API on paper, but it quietly closes a gap plugin developers have worked around for years. Register a collection, add icons inline or from files, and use them across the block editor, PHP templates, and REST, all without touching JavaScript. The bulk pattern with glob() scales from three icons to three hundred without changing the code.

The takeaways:

Collections come first: icons attach to collections, not the other way around
Two registration methods: content for inline, file_path for icons on disk. Both work in the same collection.
Bulk registration beats per-icon calls: glob() over a folder registers unlimited icons in six lines
wp_get_icon( $name, $args ) accepts size, class, and label: a proper templating function, not just an SVG dump
currentColor in SVGs is the pattern to follow: icons that adapt to their surroundings look native everywhere
The same registration serves editor + PHP + REST: one function call, three consumer contexts

Custom icons complete the story for custom blocks. Combined with the PHP-only blocks guide, a plugin can now register blocks, register their icons, and ship a completely branded editor experience without a build step. Once WordPress 7.1 ships on August 19, this is genuinely one of the releases worth updating for.

Frequently Asked Questions

Do I have to register a collection before registering icons?

Yes. Icons must belong to an existing collection, or they silently fail to appear in the picker. Register the collection at default priority on init, then register icons at a higher priority (like 20) so they run after.

Can I mix inline content icons and file_path icons in the same collection?

Yes. Each wp_register_icon() call is independent. Use content for one or two icons, file_path for the rest. WordPress treats them the same once registered.

Do custom icons work as block icons in register_block_type()?

Yes. Pass the registered icon name (like 'wpvibes/star') to the icon key in register_block_type(). The block inserter shows the custom SVG instead of a Dashicon. Works for JavaScript-registered blocks and PHP-only blocks.

Does wp_get_icon() return the icon as HTML, or as a string?

wp_get_icon() returns the SVG as a string, so you can echo it directly or wrap it in your own HTML. The second $args array accepts size, class, label (for aria-label), and title.

What SVG attributes should I remove before registering an icon?

Remove hardcoded fill and stroke colors, width and height attributes on the root <svg> (leave the viewBox), and any <style> blocks or scripts. Keep viewBox and structural attributes. Use currentColor for any color reference.

Can I register icons from a theme instead of a plugin?

Yes. The same wp_register_icon() call works from a theme's functions.php using get_stylesheet_directory() for the file path. The trade-off is that icons registered from a theme disappear when the theme changes.

What happens if two collections have the same icon name?

Collections namespace icon names, so wpvibes/heart and myplugin/heart coexist without conflict. The full name including the collection prefix is what makes each unique.

Does WordPress sanitize SVGs on registration?

WordPress does not modify the SVG content on registration. The exact string you provide (or file contents you reference) is what gets served. Sanitize SVGs yourself before shipping: remove scripts, external references, and anything unnecessary.

PHP-Only Blocks in WordPress 7.0: The Developer's Complete Guide

WPVibes — Thu, 06 Aug 2026 06:05:10 +0000

For the first time in eight years, you can register real Gutenberg blocks using only PHP - no React, no npm, no Webpack, no build step. Just a plugin file, register_block_type(), and a new autoRegister flag introduced in WordPress 7.0.

This guide walks you through building a complete plugin with two production-ready blocks - a Notice block and a Category Display block - from setup to shipping. The complete plugin, including all CSS and helper files, is on GitHub. Everything you need to follow along is in this article; everything you need to ship is in the repository.

A quick clarification before we start: Server-rendered Gutenberg blocks have existed for years, but until now they always required a JavaScript layer using ServerSideRender to scaffold the block in the editor - even though the actual rendering happened in PHP. You still needed block.json, an edit.js file, and a build step. WordPress 7.0's autoRegister => true flag removes that JavaScript ceremony entirely.

We'll cover architecture and comparisons at the end. First, let's build.

Who Is This Guide For?

WordPress developers comfortable with PHP who want to build blocks without a JavaScript build pipeline. Basic knowledge of register_block_type() helps but isn't required - this guide explains each step.

What Will You Build?

Notice Block: Title, description, and four skin variants (Alert, Warning, Success, Info)
Category Display Block: Show post categories in Grid, List, or Compact layout, with optional images (via ACF if installed, plugin placeholder if not), post counts, and recent post lists

Prerequisites

WordPress 7.0 or later
Local development environment (LocalWP, WordPress Studio, wp-env, or similar)
Code editor
Basic PHP knowledge
Optional: Advanced Custom Fields - the Category Display block supports ACF images if available and falls back to a placeholder otherwise

💡
Tips: Test all changes on a local or staging site first. WordPress 7.0 is recent and PHP-only blocks are a new API - verify everything before shipping to production.

Step 1: Set Up the Plugin

The plugin contains both blocks, organized cleanly so more blocks can be added later without refactoring.

1.1 - File structure

Create this folder inside wp-content/plugins/:

wpvibes-blocks/
├── wpvibes-blocks.php
├── includes/
│   └── class-blocks-loader.php
├── blocks/
│   ├── class-notice-block.php
│   └── class-category-display-block.php
└── assets/
    ├── notice.css
    ├── category-display.css
    └── images/
        └── category-placeholder.png

Why this structure?

The main plugin file loads everything. The loader class registers all blocks in one loop. Each block lives in its own file. Each block's CSS lives in its own file too. Adding a new block later means creating one new class file, adding one line to the loader, and registering one stylesheet. This pattern scales - a plugin with 20 blocks stays maintainable; a single 5,000-line file does not.

1.2 - The main plugin file

Create wpvibes-blocks.php:

<?php
/**
 * Plugin Name: WPVibes Blocks
 * Description: PHP-only Gutenberg blocks — Notice and Category Display.
 * Version:     1.0.0
 * Author:      WPVibes
 * Requires at least: 7.0
 * Requires PHP: 7.4
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

define( 'WPVIBES_BLOCKS_VERSION', '1.0.0' );
define( 'WPVIBES_BLOCKS_PATH', plugin_dir_path( __FILE__ ) );
define( 'WPVIBES_BLOCKS_URL', plugin_dir_url( __FILE__ ) );

require_once WPVIBES_BLOCKS_PATH . 'blocks/class-notice-block.php';
require_once WPVIBES_BLOCKS_PATH . 'blocks/class-category-display-block.php';

require_once WPVIBES_BLOCKS_PATH . 'includes/class-blocks-loader.php';
WPVibes_Blocks_Loader::init();

The main file wires things together. Nothing more.

1.3 - The loader

Create includes/class-blocks-loader.php:

<?php
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

class WPVibes_Blocks_Loader {

    private static $block_classes = array(
        'WPVibes_Notice_Block',
        'WPVibes_Category_Display_Block',
    );

    public static function init() {

        add_action( 'init', array( __CLASS__, 'register_styles' ), 5 );
        add_action( 'init', array( __CLASS__, 'register_all_blocks' ), 10 );
    }

    public static function register_styles() {

        wp_register_style(
            'wpvibes-notice',
            WPVIBES_BLOCKS_URL . 'assets/notice.css',
            array(),
            WPVIBES_BLOCKS_VERSION
        );

        wp_register_style(
            'wpvibes-category-display',
            WPVIBES_BLOCKS_URL . 'assets/category-display.css',
            array(),
            WPVIBES_BLOCKS_VERSION
        );
    }

    public static function register_all_blocks() {

        foreach ( self::$block_classes as $class_name ) {

            if ( ! class_exists( $class_name ) ) {
                continue;
            }

            $block = new $class_name();
            $block->register();
        }
    }
}

Activate the plugin from Plugins → Installed Plugins. Nothing visible yet - the blocks come next.

Step 2: Build the Notice Block

The Notice block shows a message with a title, description, and one of four skin options (Alert, Warning, Success, Info). It's the simpler of the two blocks - a good starting point for learning the API.

2.1 - Create the block class

Create blocks/class-notice-block.php:

<?php
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

class WPVibes_Notice_Block {

    public function register() {

        register_block_type(
            'wpvibes/notice',
            array(
                'title'           => __( 'Notice', 'wpvibes-blocks' ),
                'description'     => __( 'A notice or callout with 4 skins.', 'wpvibes-blocks' ),
                'category'        => 'text',
                'icon'            => 'warning',
                'style'           => 'wpvibes-notice',
                'editor_style'    => 'wpvibes-notice',
                'attributes'      => $this->get_attributes(),
                'supports'        => $this->get_supports(),
                'render_callback' => array( $this, 'render' ),
            )
        );
    }

    // Attribute, supports, and render methods below

Two keys worth pointing out:

style and editor_style - attach the stylesheet registered in the loader (same handle for both). WordPress loads it only when the block is used.
render_callback - the PHP function that returns the block's HTML.

2.2 - Define the attributes

Add this method to the class:

public function get_attributes() {

        return array(

            'title' => array(
                'type'    => 'string',
                'default' => 'Important notice',
                'label'   => __( 'Title', 'wpvibes-blocks' ),
            ),

            'description' => array(
                'type'    => 'string',
                'default' => 'Add your notice message here.',
                'label'   => __( 'Description', 'wpvibes-blocks' ),
            ),

            'skin' => array(
                'type'    => 'string',
                'enum'    => array( 'Alert', 'Warning', 'Success', 'Info' ),
                'default' => 'Info',
                'label'   => __( 'Skin', 'wpvibes-blocks' ),
            ),
        );
    }

Three attributes:

title - a string, so WordPress auto-generates a text input in the sidebar.
description - same, another text input.
skin - string with enum, so WordPress auto-generates a dropdown with exactly those four options.

The label key controls what the user sees. Without it, WordPress derives a label from the attribute name.

2.3 - Add block supports

public function get_supports() {

        return array(
            'autoRegister' => true,
            'color'        => array( 'text' => true, 'background' => true ),
            'spacing'      => array( 'padding' => true, 'margin' => true ),
            'border'       => array( 'color' => true, 'radius' => true, 'style' => true, 'width' => true ),
        );
    }

Two things happen here:

autoRegister => true - the flag that tells WordPress to register this block from PHP alone, without JavaScript scaffolding.
color, spacing, border - turn on native design panels in the sidebar. Users get Color, Spacing, and Border controls automatically.

2.4 - Write the render callback

public function render( $attributes ) {

        $skin_class = 'wpvibes-notice--' . strtolower( $attributes['skin'] );

        $wrapper = get_block_wrapper_attributes(
            array(
                'class' => 'wpvibes-notice ' . $skin_class,
                'role'  => 'alert',
            )
        );

        $title = ! empty( $attributes['title'] )
            ? '<h4 class="wpvibes-notice__title">' . esc_html( $attributes['title'] ) . '</h4>'
            : '';

        $description = ! empty( $attributes['description'] )
            ? '<p class="wpvibes-notice__description">' . esc_html( $attributes['description'] ) . '</p>'
            : '';

        return sprintf(
            '<div %1$s><div class="wpvibes-notice__icon"></div><div class="wpvibes-notice__content">%2$s%3$s</div></div>',
            $wrapper,
            $title,
            $description
        );
    }
}

Key points:

get_block_wrapper_attributes() returns HTML attributes carrying every design choice the user made - color, background, padding, border. Always use it.
esc_html() on all user-provided content. Standard WordPress escaping.
BEM naming - wpvibes-notice (base) plus wpvibes-notice--alert (variant). Predictable CSS.

2.5 - Add the CSS

.wpvibes-notice {
    display: flex;
    align-items: flex-start;
    gap: 12px;
    padding: 16px 20px;
    border-left: 4px solid currentColor;
    border-radius: 4px;
}

.wpvibes-notice--alert   { background: #fee2e2; color: #991b1b; border-left-color: #dc2626; }
.wpvibes-notice--warning { background: #fef3c7; color: #92400e; border-left-color: #f59e0b; }
.wpvibes-notice--success { background: #d1fae5; color: #065f46; border-left-color: #10b981; }
.wpvibes-notice--info    { background: #dbeafe; color: #1e3a8a; border-left-color: #3b82f6; }

💡
Notes: The full CSS (icon circles, title and description typography, hover states) is in the plugin repository at assets/notice.css. Copy the complete file into the plugin's assets/ folder before testing.

2.6 - See it working

Create a new page or post
Click + in the block inserter and search for Notice
Try each skin from the sidebar dropdown
Adjust the native Color and Padding controls

The first PHP-only block is done. No JavaScript. No build step. No block.json.

💡
Notes: The complete file for reference is at blocks/class-notice-block.php.

Step 3: Build the Category Display Block

The Category Display block shows post categories in Grid, List, or Compact layout. For each category: name, post count, an image (from ACF if installed, plugin placeholder otherwise), and a list of recent posts.

This block covers all four supported attribute types - string, integer, boolean, and enum - in one useful example.

3.1 - Create the block class

Create blocks/class-category-display-block.php:

<?php
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

class WPVibes_Category_Display_Block {

    public function register() {

        register_block_type(
            'wpvibes/category-display',
            array(
                'title'           => __( 'Category Display', 'wpvibes-blocks' ),
                'description'     => __( 'Display categories with post count, image, and recent posts.', 'wpvibes-blocks' ),
                'category'        => 'widgets',
                'icon'            => 'category',
                'style'           => 'wpvibes-category-display',
                'editor_style'    => 'wpvibes-category-display',
                'attributes'      => $this->get_attributes(),
                'supports'        => $this->get_supports(),
                'render_callback' => array( $this, 'render' ),
            )
        );
    }

    // Attributes, supports, and render methods below

3.2 - Define the attributes (all 4 types)

public function get_attributes() {

        return array(

            // ENUM — dropdown
            'layout' => array(
                'type'    => 'string',
                'enum'    => array( 'Grid', 'List', 'Compact' ),
                'default' => 'Grid',
                'label'   => __( 'Layout', 'wpvibes-blocks' ),
            ),

            // INTEGER — number input with min/max
            'columns' => array(
                'type'    => 'integer',
                'default' => 3,
                'minimum' => 2,
                'maximum' => 4,
                'label'   => __( 'Columns (Grid only)', 'wpvibes-blocks' ),
            ),

            // INTEGER
            'postCount' => array(
                'type'    => 'integer',
                'default' => 5,
                'minimum' => 1,
                'maximum' => 20,
                'label'   => __( 'Posts per Category', 'wpvibes-blocks' ),
            ),

            // STRING — text input (ACF field key)
            'acfFieldKey' => array(
                'type'    => 'string',
                'default' => 'term_featured_image',
                'label'   => __( 'ACF Image Field Key', 'wpvibes-blocks' ),
            ),

            // ENUM — dropdown
            'orderBy' => array(
                'type'    => 'string',
                'enum'    => array( 'Name', 'Post Count', 'Slug' ),
                'default' => 'Name',
                'label'   => __( 'Order By', 'wpvibes-blocks' ),
            ),

            // BOOLEAN — toggle
            'showImage' => array(
                'type'    => 'boolean',
                'default' => true,
                'label'   => __( 'Show Image', 'wpvibes-blocks' ),
            ),

            // BOOLEAN
            'showPostCount' => array(
                'type'    => 'boolean',
                'default' => true,
                'label'   => __( 'Show Post Count', 'wpvibes-blocks' ),
            ),

            // BOOLEAN
            'showRecentPosts' => array(
                'type'    => 'boolean',
                'default' => true,
                'label'   => __( 'Show Recent Posts', 'wpvibes-blocks' ),
            ),

            // BOOLEAN
            'hideEmpty' => array(
                'type'    => 'boolean',
                'default' => true,
                'label'   => __( 'Hide Empty Categories', 'wpvibes-blocks' ),
            ),
        );
    }

What each attribute type teaches:

layout and orderBy - string with enum. WordPress auto-generates dropdowns with exactly those choices.
columns and postCount - integers with minimum and maximum. WordPress auto-generates number inputs that enforce the ranges.
acfFieldKey - a plain string. Text input where the user types the ACF field name.
showImage, showPostCount, showRecentPosts, hideEmpty - booleans. Each becomes a toggle switch in the sidebar.

That's every attribute type WordPress 7.0 auto-generates a control for.

3.3 - Block supports

public function get_supports() {

        return array(
            'autoRegister' => true,
            'align'        => array( 'wide', 'full' ),
            'color'        => array( 'text' => true, 'background' => true ),
            'spacing'      => array( 'padding' => true, 'margin' => true ),
            'border'       => array( 'color' => true, 'radius' => true, 'width' => true, 'style' => true ),
        );
    }

Same as the Notice block, with align added so users can center or full-width the block.

3.4 - Write the render callback

public function render( $attributes ) {

        $order_by_map = array(
            'Name'       => 'name',
            'Post Count' => 'count',
            'Slug'       => 'slug',
        );

        $categories = get_categories(
            array(
                'hide_empty' => ! empty( $attributes['hideEmpty'] ),
                'orderby'    => $order_by_map[ $attributes['orderBy'] ] ?? 'name',
                'order'      => 'ASC',
            )
        );

        if ( empty( $categories ) ) {
            return '<p>' . esc_html__( 'No categories to display.', 'wpvibes-blocks' ) . '</p>';
        }

        $layout       = strtolower( $attributes['layout'] );
        $layout_class = 'wpvibes-category-display--' . $layout;

        $columns_class = ( 'grid' === $layout )
            ? ' wpvibes-category-display--cols-' . absint( $attributes['columns'] )
            : '';

        $wrapper = get_block_wrapper_attributes(
            array(
                'class' => 'wpvibes-category-display ' . $layout_class . $columns_class,
            )
        );

        $items_html = '';

        foreach ( $categories as $category ) {
            $items_html .= $this->render_category_item( $category, $attributes );
        }

        return sprintf(
            '<div %1$s>%2$s</div>',
            $wrapper,
            $items_html
        );
    }

What the render callback does:

Queries categories using the hideEmpty and orderBy attributes
Handles empty state with a friendly message
Builds layout classes - wpvibes-category-display--grid plus wpvibes-category-display--cols-3 for column-based grids
Loops through categories and renders each via a helper method

3.5 - Render a single category

private function render_category_item( $category, $attributes ) {

        $image_html = '';
        if ( ! empty( $attributes['showImage'] ) ) {
            $image_url  = $this->get_category_image_url( $category, $attributes['acfFieldKey'] );
            $image_html = sprintf(
                '<div class="wpvibes-category-display__image"><img src="%s" alt="%s" loading="lazy"></div>',
                esc_url( $image_url ),
                esc_attr( $category->name )
            );
        }

        $count_html = '';
        if ( ! empty( $attributes['showPostCount'] ) ) {
            $count_html = sprintf(
                '<span class="wpvibes-category-display__count">%s</span>',
                sprintf(
                    esc_html( _n( '%d post', '%d posts', $category->count, 'wpvibes-blocks' ) ),
                    (int) $category->count
                )
            );
        }

        $posts_html = '';
        if ( ! empty( $attributes['showRecentPosts'] ) && $category->count > 0 ) {

            $recent_posts = get_posts(
                array(
                    'category'       => $category->term_id,
                    'posts_per_page' => absint( $attributes['postCount'] ),
                    'orderby'        => 'date',
                    'order'          => 'DESC',
                )
            );

            if ( ! empty( $recent_posts ) ) {

                $posts_html .= '<ul class="wpvibes-category-display__posts">';

                foreach ( $recent_posts as $post ) {
                    $posts_html .= sprintf(
                        '<li><a href="%s">%s</a></li>',
                        esc_url( get_permalink( $post ) ),
                        esc_html( get_the_title( $post ) )
                    );
                }

                $posts_html .= '</ul>';
            }
        }

        return sprintf(
            '<div class="wpvibes-category-display__item">%1$s<div class="wpvibes-category-display__content"><h3 class="wpvibes-category-display__name"><a href="%2$s">%3$s</a></h3>%4$s%5$s</div></div>',
            $image_html,
            esc_url( get_category_link( $category ) ),
            esc_html( $category->name ),
            $count_html,
            $posts_html
        );
    }

Each part (image, count, recent posts) is built conditionally based on the toggles. If a toggle is off, that part's HTML variable stays empty and contributes nothing to the final output.

3.6 - The ACF image with fallback

The Category Display block uses an ACF image if the site has ACF installed and the field is set. If not, it falls back to a placeholder from the plugin's own assets folder:

private function get_category_image_url( $category, $acf_field_key ) {

        // Check if ACF is active AND a field key is provided.
        if ( function_exists( 'get_field' ) && ! empty( $acf_field_key ) ) {

            // ACF term meta uses 'category_' . term_id as the object ID.
            $acf_image = get_field( $acf_field_key, 'category_' . $category->term_id );

            if ( $acf_image ) {

                // ACF image field can return an array, an ID, or a URL string
                // depending on the "Return Format" setting.
                if ( is_array( $acf_image ) && ! empty( $acf_image['url'] ) ) {
                    return $acf_image['url'];
                }

                if ( is_string( $acf_image ) ) {
                    return $acf_image;
                }

                if ( is_numeric( $acf_image ) ) {
                    $url = wp_get_attachment_image_url( $acf_image, 'medium' );
                    if ( $url ) {
                        return $url;
                    }
                }
            }
        }

        // Fallback: plugin's placeholder image.
        return WPVIBES_BLOCKS_URL . 'assets/images/category-placeholder.png';
    }
}

Three things this pattern teaches:

function_exists() before using an external plugin's function - always. Never assume ACF (or any plugin) is active.
The ACF term meta prefix - ACF stores term meta under category_ + term_id. This trips up many developers.
Handling ACF's different return formats - ACF image fields can return an array, an ID, or a URL, depending on the "Return Format" setting. The code should handle at least the two common ones.

3.7 - Add the CSS

Create assets/category-display.css with the base structure:

.wpvibes-category-display {
    display: grid;
    gap: 24px;
}

.wpvibes-category-display--grid {
    grid-template-columns: repeat(3, 1fr);
}

.wpvibes-category-display--grid.wpvibes-category-display--cols-2 { grid-template-columns: repeat(2, 1fr); }
.wpvibes-category-display--grid.wpvibes-category-display--cols-4 { grid-template-columns: repeat(4, 1fr); }

.wpvibes-category-display--list    { grid-template-columns: 1fr; }
.wpvibes-category-display--compact { grid-template-columns: 1fr; gap: 0; }

💡
Important: The full CSS (card styling, hover states, image aspect ratios, list-layout flex rules, compact-layout borders, and mobile responsiveness) is in the plugin repository at assets/category-display.css. Copy the complete file into the plugin's assets/ folder before testing.

3.8 - Add a placeholder image

Place any image at assets/images/category-placeholder.png - an 800×450 image works well. The plugin repository includes one; a custom branded placeholder also works.

3.9 - See it working

Assign a few posts to different categories
Insert the Category Display block
In the sidebar, try:

*   Each layout (Grid, List, Compact)

*   Different column counts (2, 3, 4) while in Grid layout

*   Toggling Show Image, Show Post Count, Show Recent Posts

*   Changing Posts per Category

Two production-ready PHP-only blocks - one simple, one covering the full API - done.

💡
Notes: The complete file for reference is at blocks/class-category-display-block.php.

Debugging Tips

When something breaks during development, enable WordPress debug logging in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then check wp-content/debug.log after triggering the issue. Nine times out of ten, a PHP error during registration is the culprit — and it will be in the log with a line number.

For attribute-level debugging (checking what's being passed to the render callback), add temporary error_log() calls at the top of the render function:

error_log( 'Notice block attributes: ' . print_r( $attributes, true ) );

Remove these before shipping.

Get the Full Plugin

The complete plugin - with all CSS, placeholder image, and README - is on GitHub.

How PHP-Only Blocks Work Under the Hood

Now that the plugin builds, here's what actually happens when a PHP-only block is registered and rendered.

Before WordPress 7.0

Building a server-rendered block required these files, at minimum:

my-plugin/
├── src/block/
│   ├── block.json
│   ├── edit.js
│   └── index.js
├── package.json
└── my-plugin.php

The edit.js typically looked like this:

import { ServerSideRender } from "@wordpress/editor";

export default function edit( props ) {
    return (
        <ServerSideRender
            block={ props.name }
            attributes={ props.attributes }
        />
    );
}

A JavaScript component whose only job was to say "please render this on the server." Then npm install, run a build, and hope everything worked.

With WordPress 7.0

WordPress 7.0 adds one flag: autoRegister => true. When set, WordPress:

Takes the block registration from PHP
Adds it to a JavaScript global in the editor settings
The editor picks it up and uses ServerSideRender internally for the preview
When a user changes an attribute, the editor calls the REST API, which runs the PHP render_callback, and swaps in the new HTML

Zero JavaScript written. WordPress handles the ceremony.

The runtime flow

User changes an attribute in the sidebar
        ↓
Editor sends REST API request
        ↓
WordPress runs render_callback in PHP
        ↓
render_callback returns HTML string
        ↓
Editor swaps HTML into the block preview

This is why every attribute change causes a small delay - there's always a server round-trip. That's the deliberate trade-off: no client-side complexity, but no live reactivity either.

Auto-generated inspector controls

WordPress inspects the attributes array and generates sidebar controls automatically:

Attribute definition	Generated control
`type: 'string'`	Text input
`type: 'string'` + `enum: [...]`	Dropdown (SelectControl)
`type: 'integer'` with `minimum` / `maximum`	Number input with enforced range
type: 'boolean'	Toggle switch

Controls are not generated for object and array types, or for attribute names that conflict with reserved block-supports names like style.

When Should You Use PHP-Only Blocks?

An honest decision table:

Use PHP-only blocks when	Use JavaScript-registered blocks when
Block is display-only (notice, category grid, author box)	Block needs InnerBlocks (nested blocks)
Content comes from server data (users, posts, terms, APIs)	Inline rich-text editing is required
Replacing a legacy shortcode	Editor experience needs live client-side reactivity
Avoiding a JavaScript build pipeline	Interactivity API is needed for state management
Simple enough that a server round-trip on each change is acceptable	Real-time visual manipulation (drag handles, instant previews) is essential

Both approaches are first-class WordPress citizens. PHP-only blocks aren't a downgrade -they're a shortcut for a specific class of blocks that never needed JavaScript in the first place.

What Are the Limitations of PHP-Only Blocks?

Deliberate scope decisions, not bugs. Knowing them helps pick the right approach.

Limitation	Impact	Status
No InnerBlocks / nested blocks	Can't build columns, accordions, sections	No timeline announced
Only 4 attribute types (string, integer, boolean, enum)	No media picker, rich text, date picker	DataForm being extended to PHP-only blocks in 7.1
Block Bindings limited in 7.0	Custom fields, post meta bindings need workarounds	ACF and Meta Box become native binding sources in 7.1
Server round-trip on every attribute change	Preview feels less responsive than JS blocks	By design - the trade-off for zero JavaScript
Custom `style` attribute conflicts with supports	Must rename to `skin`, `variant`, etc.	Reserved namespace, not a bug

Frequently Asked Questions

Can PHP-only blocks contain InnerBlocks?

No. PHP-only blocks cannot contain nested blocks. For layouts like columns, accordions, or sections that wrap other blocks, use the traditional JavaScript block registration path.

Do PHP-only blocks work with the Interactivity API?

Not directly. The Interactivity API is designed for client-side state and reactivity, which PHP-only blocks don't provide. For blocks needing state (toggles, tabs, live filtering), JavaScript block registration is the correct choice.

Which attribute types get auto-generated controls?

Four types: string (text input), string with enum (dropdown), integer with minimum/maximum (number input), and boolean (toggle). Types like object and array do not generate controls.

Why is my custom style attribute causing errors?

WordPress reserves the style attribute name when block supports for color, spacing, or typography are enabled. Rename any custom attribute called style to something like skin, variant, or theme.

Does the editor preview update in real time?

No. Each attribute change triggers a REST API call to the PHP render_callback, then the editor swaps in the returned HTML. There's a small delay on every change - this is the trade-off for not writing JavaScript.

Can I use wp_enqueue_block_style() for PHP-only block CSS?

Not reliably. wp_enqueue_block_style() works for JavaScript-registered blocks but doesn't always fire for PHP-only blocks in the editor. Use wp_register_style() with the style and editor_style keys inside register_block_type() instead - the pattern shown in this guide.

What happens in the editor if the render callback throws an error?

The block shows "Error loading block" in the editor preview. Check wp-content/debug.log for the PHP error - the line number points directly to the issue.

Do PHP-only blocks support WordPress block themes and Full Site Editing?

Yes. PHP-only blocks work in block themes, templates, template parts, and the Site Editor. WordPress 7.1 enforces iframe mode for block themes - the examples in this guide use current APIs, so no changes are needed.

Wrapping Up

Building the WPVibes Blocks plugin has covered:

autoRegister => true is the entire "new API." Everything else is standard register_block_type().

The style and editor_style keys with wp_register_style() are the right way to attach CSS to a PHP-only block — cleaner and correctly loading in both editor and frontend.

get_block_wrapper_attributes() carries all block-supports styles into the render output. Always use it.

Auto-generated sidebar controls work well within their limits - string, integer, boolean, enum.

Server round-trip on every attribute change is the trade-off - keep render callbacks fast.

One file per block scales. Adding a new block later is one new file, one line in the loader.

How to Connect Elementor Form Submissions to Google Sheets

WPVibes — Mon, 03 Aug 2026 10:23:40 +0000

If you want to send your Elementor form to Google Sheets automatically, Elementor Pro doesn't offer a built-in way to do it. Most guides send you to Zapier, or a single-purpose connector plugin that only does one thing.

Form Vibes Pro connects Elementor forms to Google Sheets natively, from inside WordPress. No automation platform. No per-task limits. Every new Elementor submission lands in your spreadsheet automatically.

This guide walks through the complete setup, from Google API credentials to your first synced entry.

What Does This Setup Give You?

Once this is set up, every Elementor submission appears in Google Sheets within seconds, with no manual export needed. Your team or client can see leads live without needing WordPress access. Every entry is also saved to your WordPress database as a backup, so nothing depends on Google alone.

Elementor Pro doesn't give you a way to send form data anywhere but email. Form Vibes Pro adds the missing Google Sheets connection, plus a full submission dashboard inside WordPress.

Is Google Sheets Sync a Free or Pro Feature?

Google Sheets sync is a Form Vibes Pro feature. Here's what's relevant to this guide:

Feature	Free	Pro
Save Elementor entries to WordPress database	Yes	Yes
Export to CSV on demand	Yes (up to 1,000 rows)	Yes (unlimited)
Automatic sync to Google Sheets	No	Yes
Filter which submissions get synced	No	Yes

See full Pro feature list.

Elementor Submissions vs Google Sheets Sync: Which Should You Use?

Elementor Pro has a native Submissions screen inside WordPress. Use it for quick in-dashboard checks. Use Google Sheets sync when submissions need to reach people or tools outside WordPress in real time, such as sales teams, clients, external dashboards, or backup workflows.

How to Connect Elementor Form Submissions to Google Sheets

Setup has three parts: create Google API credentials, connect Form Vibes to your Google account, then set up the Google Sheets connection for your Elementor form.

Create Your Google API Credentials

Google requires API credentials so Form Vibes can communicate securely with your Google account. These consist of a Client ID and a Client Secret, generated in Google Cloud Console. The full credential creation process is covered in a dedicated guide. Follow that guide to generate your Client ID and Client Secret, then return here to continue.

Connect Form Vibes to Google Sheets

Go to Form Vibes > Settings > Google Sheet in your WordPress admin. Paste your Client ID and Client Secret into their respective fields. Click Authenticate and sign in with your Google account when prompted. After approving the requested permissions, the connection status updates to show the account as connected.

💡
Tip: During authentication, Google shows an "App is not verified" warning. This is expected for a self-configured OAuth connection. Click Show Advanced, then Go to App, and approve all requested permissions. The connection completes normally.

Set Up the Google Sheets Connection for Your Elementor Form

With your Google account connected, go to Form Vibes > Export Profiles and click Add New. Under Type, select Google Sheet instead of Local Download. This tells Form Vibes to push submissions to a spreadsheet rather than generate a downloadable file.

Configure the Export Profile Settings:

From the form dropdown, select the Elementor form whose submissions you want to send to Google Sheets. Forms appear here once they've received at least one submission (see the troubleshooting section below if your form isn't listed yet).

Select the specific worksheet, or tab, within the spreadsheet. Create a new one using the plus icon if needed.

The Data Filter section lets you sync only the submissions that match specific conditions, instead of sending every submission to Google Sheets. To filter, choose whether any condition must be met (OR) or all conditions must be met (AND). Then, for each condition, select the form field to check, choose a match type of Equal, Not Equal, Contain, or Not Contain, and enter the value to match against. Click Add New Condition to stack additional rules.

Map Your Fields and Publish:

Map each Elementor form field to its corresponding spreadsheet column. If your Elementor form has a Name field and your sheet has a Name column, connect them here. Repeat for every field you want to appear in the spreadsheet. Click Publish to save and activate the connection.

💡
Important: The Export Profile must be in Published status for submissions to sync automatically. One left in Draft will not push any data to the spreadsheet. Always confirm it is published before sending a test submission.

What Happens After Someone Submits Your Elementor Form?

Once the connection is published, no further action is needed. When a visitor submits your Elementor form, Form Vibes captures the submission, saves it to your WordPress database, and immediately pushes a new row to the connected Google Spreadsheet. Each Elementor form field appears in the column it was mapped to during setup.

The submission appears in the sheet within moments. Anyone with access to the spreadsheet can see the new row without logging into WordPress. The spreadsheet keeps updating automatically with every new Elementor submission from that point forward.

Why Aren't Elementor Submissions Reaching Google Sheets?

Elementor submissions usually fail to reach Google Sheets because of one of six issues: a form not yet listed in the dropdown, a spreadsheet the connected account can't access, a redirect URI mismatch, a disabled Google API, an unpublished sync setup, or a column mapping that's fallen out of date. Submit a test entry from the frontend of your Elementor form first, then check the causes below.

The Elementor form is not showing in the Form dropdown. Confirm Elementor Pro is active. Then confirm the form has received at least one submission on the frontend since Form Vibes was activated. Form Vibes only lists forms that have already received at least one submission, so a form with zero submissions will not appear in the dropdown yet.

App verification warning during authentication. This is expected for self-configured OAuth apps. Click Show Advanced, then Go to App, and approve all permissions. The warning does not indicate a problem with the connection.

Data is appearing in the wrong columns. Open the Export Profile and review the column mapping section. Update the field-to-column pairings if your sheet headers or Elementor form field names have changed since it was last saved.

Google Sheets and Drive APIs are not enabled. Both APIs must be enabled inside your Google Cloud Console project. If sync silently fails, this is the second most common cause after a redirect URI mismatch.

Conclusion

Form Vibes Pro connects Elementor forms to Google Sheets natively, without a third-party automation platform. Set up the Google API credentials once, connect your Google account, configure the sync for your form, and every new submission lands in your spreadsheet automatically.

Every submission is also saved to your own WordPress database. So if you use other form plugins alongside Elementor, all your submissions live in one dashboard with the same Google Sheets sync, CSV export, filtering, and analytics.

Frequently Asked Questions

Does Elementor Pro have a built-in Google Sheets integration?

No. Elementor Pro Forms include native actions for database, email, webhooks, and a handful of marketing tools, but Google Sheets is not one of them. To sync Elementor submissions to Google Sheets you need a plugin like Form Vibes Pro.

Do I need Form Vibes Pro to connect Elementor forms to Google Sheets?

Yes. The Google Sheets integration is a Form Vibes Pro feature. The free version still saves every Elementor submission to your WordPress database and lets you export to CSV on demand. The automatic real-time push to a Google Spreadsheet is the Pro upgrade.

Can I sync multiple Elementor forms to different Google Sheets?

Yes. Set up one sync connection per Elementor form, and point each one to its own spreadsheet or its own worksheet inside the same spreadsheet. There is no limit on how many Elementor forms you can connect.

Does the same integration work with my other form plugins?

Yes. The Google Sheets sync in Form Vibes Pro works with Contact Form 7, WPForms, Gravity Forms, Ninja Forms, WS Form, Bricks Builder forms, Beaver Builder forms, and Everest Forms. One plugin, one Google connection, all your forms.

WordPress Abilities API + MCP: The Developer's Complete Guide

WPVibes — Tue, 28 Jul 2026 05:34:11 +0000

AI tools like Claude, Cursor, and ChatGPT can now interact directly with your WordPress site, but only if your site knows how to describe what it can do.

That's exactly what the WordPress Abilities API solves.

It lets developers expose WordPress functionality as reusable, self-describing abilities that can be used by PHP, JavaScript, the REST API, and AI tools through the Model Context Protocol (MCP).

Here's what this guide walks you through:

Understand what the Abilities API is, in simple words
Create your first custom ability, step by step: Get Posts by Post Type
Test that ability two different ways
Connect it to Claude Desktop using the official MCP Adapter
Build two more real abilities: one that adds missing descriptions to tags and categories, and one that gives you a full site health report.

Every piece of code in this guide is real and tested. Let's start from zero.

What Is the WordPress Abilities API?

The WordPress Abilities API is a feature introduced in WordPress 6.9 that gives plugins, themes, and WordPress core a standard way to describe what they can do.

Before understanding the API, let's first understand what an ability is.

Think of an ability as a single action that your WordPress site can perform. For example, getting a list of posts, publishing a page, generating a maintenance report, or updating a WooCommerce product. These actions already exist in WordPress, but until now, there wasn't a standard way to describe them so that other plugins, applications, or AI tools could easily discover and use them.

The Abilities API solves this problem by letting developers register each action as an ability. Along with the code that performs the action, you also describe what the ability does, what information it needs, what it returns, and who is allowed to execute it.

Every ability includes a few basic pieces of information:

Part	What it is	In our example
Name	A unique identifier for the ability	wpvibes/get-posts
Description	Explains what the ability does	Returns a list of posts filtered by post type, status, and limit
Input	The information the ability needs	post_type, status, and limit
Output	The information the ability returns	A list of posts with ID, title, status, date, and link
Permission	Who is allowed to run the ability	Users who can edit posts

For example, suppose you create an ability called wpvibes/get-posts. Instead of another plugin or AI tool needing to understand your plugin's internal code, it simply looks at the ability's definition to learn what inputs it accepts, what output it returns, and whether the current user has permission to run it.

The actual PHP code that performs the work still lives inside your plugin. The Abilities API simply provides a standard way to describe that functionality so it can be discovered and used consistently across WordPress.

Now that you understand what an ability is and what information it contains, let's build one from scratch.

Prerequisites

Before writing any code, make sure you have:

WordPress 6.9 or later (the Abilities API has been in core since 6.9; 7.0+ is recommended)
A local development site (LocalWP, WordPress Studio, or similar)
WP-CLI installed and working (needed for testing and for the Claude connection later)
Claude Desktop installed (the free plan is sufficient for this guide)
A code editor and basic PHP knowledge

💡
Notes: Do everything in this guide on a local or staging site first, never directly on a live production site. The MCP Adapter is still a young project (v0.5.0 at the time of writing) and is evolving quickly. Always check the official documentation if something looks different from what's shown here.

With those ready, there's one more thing to set up before writing any actual ability code: a place for that code to live.

Create a Plugin for Your Code

All the code in this guide lives inside one small custom plugin. Here's how to set it up:

Create a new folder and file at wp-content/plugins/wpvibes-abilities/wpvibes-abilities.php.
Paste in this basic plugin header:

<?php
/**
 * Plugin Name: WPVibes Abilities Demo
 * Description: Custom abilities for the Abilities API tutorial.
 * Version:     1.0.0
 * Author:      WPVibes
 */

// Exit if accessed directly.
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

Activate the plugin from wp-admin → Plugins.
It does nothing yet, we'll add abilities to it one at a time.

💡
Important: Never put ability registration code directly in your theme's functions.php on a real project. Abilities are functionality, not design, they belong in a plugin, so they keep working even if the theme changes.

Step 1: Create Your First Ability, "Get Posts by Post Type"

Now that you understand what an ability is, it's time to create one. In this step, we'll build a simple wpvibes/get-posts ability that returns a list of posts based on the post type, status, and limit you specify.

Step 1.1: Register an ability category

Every ability belongs to a category, this helps tools group and display abilities. Add this to wpvibes-abilities.php:

/**
 * Step 1.1: Register a category for our abilities.
 */
add_action( 'wp_abilities_api_categories_init', 'wpvibes_register_ability_category' );

function wpvibes_register_ability_category() {
    wp_register_ability_category(
        'wpvibes-tools',
        array(
            'label'       => __( 'WPVibes Tools', 'wpvibes-abilities' ),
            'description' => __( 'Demo abilities from the WPVibes tutorial.', 'wpvibes-abilities' ),
        )
    );
}

💡
Notes: Categories are registered on their own hook (wp_abilities_api_categories_init), while abilities are registered on a different one (wp_abilities_api_init). Mixing these two up is one of the most common first-time mistakes. If your ability doesn't appear anywhere, check the hooks first.

Step 1.2: Register the ability

With the category in place, you can now register your first ability. Register the wpvibes/get-posts ability by adding the following code below your category registration.

/**
 * Step 1.2: Register the "Get Posts" ability.
 */
add_action( 'wp_abilities_api_init', 'wpvibes_register_get_posts_ability' );

function wpvibes_register_get_posts_ability() {

    wp_register_ability(
        'wpvibes/get-posts',
        array(
            'label'       => __( 'Get Posts', 'wpvibes-abilities' ),
            'description' => __( 'Returns a list of posts filtered by post type, status, and limit.', 'wpvibes-abilities' ),
            'category'    => 'wpvibes-tools',

            // What data this ability ACCEPTS.
            'input_schema'  => array(
                'type'       => 'object',
                'properties' => array(
                    'post_type' => array(
                        'type'        => 'string',
                        'description' => 'The post type to fetch. Example: post, page, product.',
                        'default'     => 'post',
                    ),
                    'status'    => array(
                        'type'        => 'string',
                        'description' => 'Post status to filter by.',
                        'enum'        => array( 'publish', 'draft', 'pending', 'future' ),
                        'default'     => 'publish',
                    ),
                    'limit'     => array(
                        'type'        => 'integer',
                        'description' => 'How many posts to return (1-20).',
                        'default'     => 5,
                        'minimum'     => 1,
                        'maximum'     => 20,
                    ),
                ),
            ),

            // What data this ability RETURNS.
            'output_schema' => array(
                'type'  => 'array',
                'items' => array(
                    'type'       => 'object',
                    'properties' => array(
                        'id'     => array( 'type' => 'integer' ),
                        'title'  => array( 'type' => 'string' ),
                        'status' => array( 'type' => 'string' ),
                        'date'   => array( 'type' => 'string' ),
                        'link'   => array( 'type' => 'string' ),
                    ),
                ),
            ),

            // The actual logic.
            'execute_callback'    => 'wpvibes_get_posts_callback',

            // Who can run it.
            'permission_callback' => function () {
                return current_user_can( 'edit_posts' );
            },

            // Make it visible to AI agents through MCP (used later in this guide).
            'meta'        => array(
                'mcp' => array(
                    'public' => true,
                ),
            ),
        )
    );
}

Understanding the Registration

Although the registration looks long, most of it is simply describing the ability.

The important parts are:

'wpvibes/get-posts': the unique name. Always use your own namespace (your plugin or company name) so it never conflicts with other plugins.
input_schema: this is JSON Schema format. It tells any consumer, human, tool, or AI, "you can send me post_type, status, and limit, and here are the rules for each." Notice the enum for status, the AI now knows exactly which values are valid, without guessing.
output_schema: describes what comes back. This lets AI tools understand your response without any extra explanation.
permission_callback: the security gate. Here we require the edit_posts capability, so only users who can edit posts may run this ability.
meta.mcp.public => true: this single line is what will later make the ability visible to Claude through the MCP Adapter.

💡
Important: Never use 'permission_callback' => '__return_true' in production code. Every ability must have a real permission check. When AI agents can discover and call your abilities, the permission callback is your main line of defense.

Step 1.3: Write the execute callback

Registering an ability only describes what it does.

The actual work happens inside the execute callback.

Whenever someone runs wpvibes/get-posts, WordPress calls this function automatically. It receives the validated input from the schema, performs the requested task, and returns the result.

Add the following function below your ability registration.

/**
 * Step 1.3: The logic that runs when the ability is executed.
 *
 * @param array $input Validated input from the schema.
 * @return array|WP_Error
 */
function wpvibes_get_posts_callback( $input ) {

    // Sanitize inputs (yes, even though the schema already validates them).
    $post_type = isset( $input['post_type'] ) ? sanitize_key( $input['post_type'] ) : 'post';
    $status    = isset( $input['status'] ) ? sanitize_key( $input['status'] ) : 'publish';
    $limit     = isset( $input['limit'] ) ? absint( $input['limit'] ) : 5;

    // Check the post type actually exists on this site.
    if ( ! post_type_exists( $post_type ) ) {
        return new WP_Error(
            'invalid_post_type',
            sprintf( 'The post type "%s" does not exist on this site.', $post_type )
        );
    }

    $posts = get_posts(
        array(
            'post_type'      => $post_type,
            'post_status'    => $status,
            'posts_per_page' => min( $limit, 20 ),
        )
    );

    // Build the response to match our output schema.
    $results = array();

    foreach ( $posts as $post ) {
        $results[] = array(
            'id'     => $post->ID,
            'title'  => get_the_title( $post ),
            'status' => $post->post_status,
            'date'   => get_the_date( 'Y-m-d', $post ),
            'link'   => get_permalink( $post ),
        );
    }

    return $results;
}

What This Callback Does

Sanitize inputs anyway. The schema validates types, but defense in depth is a WordPress best practice.
Validate important conditions. Before querying posts, we check that the requested post type actually exists.
Perform the requested task. We call get_posts() using the values supplied by the user.
Return structured data. Instead of returning raw WordPress objects, we build a clean response that matches the output_schema we defined earlier.

If something goes wrong, return an WP_Error object instead of an empty response. This gives applications and AI tools a clear explanation of what failed.

Congratulations! You've successfully created and registered your first WordPress ability. Before we connect it to Claude, it's a good idea to verify that everything works correctly. We'll test the ability in two ways:

Using PHP with WP-CLI to confirm the ability executes correctly.
Using the official WordPress AI plugin to test it through a visual interface.

Once both tests are successful, we'll connect the ability to Claude using the MCP Adapter.

Step 2: Test the Ability with the AI Plugin

WP-CLI is fast and convenient for developers, but sometimes it's easier to test an ability visually.

The official AI plugin in WordPress includes an Abilities Explorer that lets you discover registered abilities, provide input values, and view the response, all from within the WordPress admin area.

Go to Plugins → Add New.
Search for AI, then install and activate the plugin.
Open Settings → AI.
Turn on Enable AI at the top of the page.
Open the Admin Experiments tab and enable the Abilities Explorer feature.

Test Your Ability

Go to Tools → Abilities Explorer.
Find your wpvibes/get-posts ability and click Test.

Click Invoke Ability.
The Result section displays the data returned by your ability.

If everything is configured correctly, you should see the same output you received when testing with WP-CLI.

Step 3: Test the Ability with PHP (WP-CLI)

Before connecting any AI, always test the ability directly. If something breaks later during MCP setup, this test tells you whether the problem is in your ability or in the connection.

The fastest way is WP-CLI. Run this from your site's folder.

wp eval '
$ability = wp_get_ability( "wpvibes/get-posts" );
if ( ! $ability ) { echo "Ability not found!"; exit; }
$result = $ability->execute( array( "post_type" => "post", "limit" => 3 ) );
if ( is_wp_error( $result ) ) {
    echo "Error: " . $result->get_error_message();
} else {
    print_r( $result );
}
' --user=admin

Here, ' --user=[your-user-name].

You should see an array of your latest 3 posts with their IDs, titles, and links

You can also execute the same ability anywhere in your own plugin or theme code:

add_action( 'admin_init', function () {

    $ability = wp_get_ability( 'wpvibes/get-posts' );

    if ( $ability ) {
        $result = $ability->execute(
            array(
                'post_type' => 'page',
                'limit' => 5,
            )
        );

        echo '<pre>';
        print_r( $result );
        echo '</pre>';
        exit;
    }
} );

💡
Tips: Always check the result with is_wp_error( $result ). A WP_Error object is truthy in PHP, so a simple if ( $result ) check will pass even when the ability failed. This is one of the most common bugs when working with abilities.

This "PHP first" test also shows the first real use case: any plugin can now call any other plugin's abilities through one standard interface, with permissions checked automatically. No hard-coded function names, no tight coupling.

Step 4: Connect Your Ability to MCP(Claude) with the MCP Adapter

So far, you've created and tested your ability inside WordPress. Now it's time to make it available to an AI assistant.

To do that, we'll use the official WordPress MCP Adapter. Before setting it up, let's quickly understand how everything fits together.

What Is the MCP Adapter?

The Model Context Protocol (MCP) is an open standard that lets AI applications communicate with external systems.

The WordPress MCP Adapter is an official plugin that acts as a bridge between your WordPress site and AI clients.

Instead of talking directly to your plugin, Claude communicates with the MCP Adapter. The adapter discovers all abilities you've registered with the Abilities API and exposes them as tools that Claude can use.

The overall flow looks like this.

Claude Desktop
   ↓ Sends the request
MCP Adapter
   ↓ Connects Claude to WordPress
Abilities API
   ↓ Finds and validates the ability
wpvibes/get-posts
   ↓ Runs the callback and returns posts

Step 4.1: Install the MCP Adapter

The adapter isn't in the plugin directory yet. Install it from GitHub:

Go to the MCP Adapter releases page
Download the latest mcp-adapter.zip
In wp-admin: Plugins → Add New → Upload Plugin → upload the zip → Activate

Verify it's working with WP-CLI

wp mcp-adapter list

You should see at least one server listed, the default one: mcp-adapter-default-server.

💡
Notes: Only abilities with meta.mcp.public => true are exposed through the MCP Adapter. This prevents private abilities from becoming available accidentally.

Step 4.2: Connect Claude Desktop to your site

Open Claude Desktop's configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the following configuration:

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

Replace the following values with your own:

WP_API_URL: Replace your-site.com with your own site's actual address.
WP_API_USERNAME: A WordPress user with permission to execute the ability.
WP_API_PASSWORD: An Application Password for that user.

New to Application Passwords? Jump to the walkthrough at the end of this guide.

Save the file and fully restart Claude Desktop (quit and reopen, not just close the window).

💡
Important: Claude runs abilities as whichever user's credentials you provided above. Your permission callbacks are checked against that exact user. This is also why permission callbacks matter so much, they're enforced on every single call, even from AI.

Step 4.3: Run Your Ability From Claude

Open a new chat in Claude Desktop. If everything is configured correctly, your WordPress server appears in the available tools list.

Now ask Claude:

"Show me my five latest draft posts."

Claude will:

Discover the available abilities.
Select wpvibes/get-posts.
Fill in the required input values.
Ask for your approval.
Execute the ability.
Display the returned posts.

Try a few more:

"How many pages does my site have?"
"List my latest WooCommerce products" (if you have a product post type)
"Do I have any posts scheduled for the future?"

Notice something important: you never told Claude how to use your ability. The input schema did all the explaining. This is why we spent time writing good descriptions and schemas in Step 1, they aren't just documentation, they're instructions that AI reads and follows.

NOTE (security, read this twice):

Never paste API credentials directly into an AI chat prompt. Credentials belong in the configuration file, where the MCP client handles them, the AI model itself never needs to see them.
Use HTTPS only for remote connections.
Create a dedicated user with only the capabilities your abilities need, don't use your main admin account.
Start with read-only abilities (like our Get Posts example). Add write or delete abilities only after you're comfortable with how everything works.
Application Passwords require "pretty" permalinks. If the MCP URL returns a 404, check Settings → Permalinks isn't set to "Plain."

Two More Real-World Abilities

Now that you know the full method, here are two more abilities to add to the same plugin. The steps are the same as Example 1, so we'll only explain what's different in each one.

Example 2: Add Missing Descriptions to Tags and Categories

Most WordPress sites accumulate tags and categories over time, but descriptions often get skipped when they're created quickly. This matters more than it looks, category and tag archive pages often display that description publicly, and a missing one is a small but real SEO and content-quality gap. This example is also safe to try, since editing a description can always be changed again, nothing gets permanently deleted.

This example uses two abilities together: one that finds the problem, and one that fixes it.

Ability 2a: Find tags/categories with no description

What this code does

This ability only looks, it never changes anything. It checks whichever taxonomy you tell it to (tags or categories), goes through every single term in it, and picks out only the ones where description is empty. It hands back a simple list, just the ID, name, and taxonomy for each one. Since nothing gets written or deleted here, Claude will run this one immediately without hesitation, exactly like the read-only get-posts example from earlier in this guide.

add_action( 'wp_abilities_api_init', 'wpvibes_register_list_terms_without_description_ability' );

function wpvibes_register_list_terms_without_description_ability() {

    wp_register_ability(
        'wpvibes/list-terms-without-description',
        array(
            'label'       => __( 'List Tags/Categories Without a Description', 'wpvibes-abilities' ),
            'description' => __( 'Returns a list of tags or categories that currently have no description set.', 'wpvibes-abilities' ),
            'category'    => 'wpvibes-tools',

            'input_schema'  => array(
                'type'       => 'object',
                'properties' => array(
                    'taxonomy' => array(
                        'type'        => 'string',
                        'description' => 'Which taxonomy to check.',
                        'enum'        => array( 'category', 'post_tag' ),
                        'default'     => 'category',
                    ),
                ),
            ),

            'output_schema' => array(
                'type'  => 'array',
                'items' => array(
                    'type'       => 'object',
                    'properties' => array(
                        'id'       => array( 'type' => 'integer' ),
                        'name'     => array( 'type' => 'string' ),
                        'taxonomy' => array( 'type' => 'string' ),
                    ),
                ),
            ),

            'execute_callback'    => 'wpvibes_list_terms_without_description_callback',

            'permission_callback' => function () {
                return current_user_can( 'manage_categories' );
            },

            'meta' => array(
                'mcp' => array( 'public' => true ),
            ),
        )
    );
}

function wpvibes_list_terms_without_description_callback( $input ) {

    $taxonomy = isset( $input['taxonomy'] ) ? sanitize_key( $input['taxonomy'] ) : 'category';

    $terms = get_terms(
        array(
            'taxonomy'   => $taxonomy,
            'hide_empty' => false,
        )
    );

    if ( is_wp_error( $terms ) ) {
        return new WP_Error( 'invalid_taxonomy', 'That taxonomy does not exist.' );
    }

    $results = array();

    foreach ( $terms as $term ) {
        // Only include terms with an empty or missing description.
        if ( empty( $term->description ) ) {
            $results[] = array(
                'id'       => $term->term_id,
                'name'     => $term->name,
                'taxonomy' => $term->taxonomy,
            );
        }
    }

    return $results;
}

Ability 2b: Save a new description for one tag or category

This ability handles one term at a time, and it needs three pieces of information to run: which term (term_id), which taxonomy it belongs to, and the new description text to save. It first double-checks that the term actually exists, so it doesn't fail halfway through with a confusing error. Then it hands the new description off to WordPress's own built-in function, wp_update_term()which saves just that one field. The term's name, its slug, everything else about it stays exactly as it was. Because this only changes a piece of text, and text can always be changed again.

add_action( 'wp_abilities_api_init', 'wpvibes_register_update_term_description_ability' );

function wpvibes_register_update_term_description_ability() {

    wp_register_ability(
        'wpvibes/update-term-description',
        array(
            'label'       => __( 'Update Tag/Category Description', 'wpvibes-abilities' ),
            'description' => __( 'Sets or updates the description for a specific tag or category.', 'wpvibes-abilities' ),
            'category'    => 'wpvibes-tools',

            'input_schema'  => array(
                'type'       => 'object',
                'properties' => array(
                    'term_id'     => array(
                        'type'        => 'integer',
                        'description' => 'The ID of the tag or category to update.',
                    ),
                    'taxonomy'    => array(
                        'type'        => 'string',
                        'description' => 'Which taxonomy this term belongs to.',
                        'enum'        => array( 'category', 'post_tag' ),
                    ),
                    'description' => array(
                        'type'        => 'string',
                        'description' => 'The new description text to set.',
                    ),
                ),
                'required'   => array( 'term_id', 'taxonomy', 'description' ),
            ),

            'output_schema' => array(
                'type'       => 'object',
                'properties' => array(
                    'term_id'         => array( 'type' => 'integer' ),
                    'new_description' => array( 'type' => 'string' ),
                ),
            ),

            'execute_callback'    => 'wpvibes_update_term_description_callback',

            'permission_callback' => function () {
                return current_user_can( 'manage_categories' );
            },

            'meta' => array(
                'mcp' => array( 'public' => true ),
            ),
        )
    );
}

function wpvibes_update_term_description_callback( $input ) {

    $term_id     = absint( $input['term_id'] );
    $taxonomy    = sanitize_key( $input['taxonomy'] );
    $description = sanitize_textarea_field( $input['description'] );

    $term = get_term( $term_id, $taxonomy );

    if ( ! $term || is_wp_error( $term ) ) {
        return new WP_Error( 'term_not_found', 'That tag or category does not exist.' );
    }

    $result = wp_update_term(
        $term_id,
        $taxonomy,
        array( 'description' => $description )
    );

    if ( is_wp_error( $result ) ) {
        return $result;
    }

    return array(
        'term_id'         => $term_id,
        'new_description' => $description,
    );
}

How you'd actually use it

Ask Claude: "Which of my categories and tags don't have a description?" Claude runs Ability 2a and shows you the list.
Ask Claude: "Write good descriptions for those and add them." Claude writes a description for each one itself, then runs Ability 2b once per category/tag to save it.

💡
Tips: This is a safe one to try for real. If a description comes out wrong, just ask Claude to write it again with different wording. Nothing here is permanent.

Example 2: Site Maintenance Report (read-only, admin-only)

Imagine asking Claude every Monday morning: "Give me my site's status report," and getting back pending updates, moderation queue, and health flags in one answer, instead of clicking through five admin screens.

add_action( 'wp_abilities_api_init', 'wpvibes_register_maintenance_report_ability' );

function wpvibes_register_maintenance_report_ability() {

    wp_register_ability(
        'wpvibes/maintenance-report',
        array(
            'label'       => __( 'Site Maintenance Report', 'wpvibes-abilities' ),
            'description' => __( 'Returns a status report: versions, pending updates, comment queues, and basic health flags.', 'wpvibes-abilities' ),
            'category'    => 'wpvibes-tools',

            // No input needed — an empty object schema.
            'input_schema'  => array(
                'type'       => 'object',
                'properties' => new stdClass(),
            ),

            'output_schema' => array(
                'type'       => 'object',
                'properties' => array(
                    'environment' => array( 'type' => 'object' ),
                    'updates'     => array( 'type' => 'object' ),
                    'content'     => array( 'type' => 'object' ),
                    'health'      => array( 'type' => 'object' ),
                ),
            ),

            'execute_callback'    => 'wpvibes_maintenance_report_callback',

            // Stricter permission: admins only.
            'permission_callback' => function () {
                return current_user_can( 'manage_options' );
            },

            'meta' => array(
                'mcp' => array( 'public' => true ),
            ),
        )
    );
}

function wpvibes_maintenance_report_callback( $input ) {

    // Update counts need these includes outside of wp-admin context.
    require_once ABSPATH . 'wp-admin/includes/update.php';
    require_once ABSPATH . 'wp-admin/includes/plugin.php';

    $update_data    = wp_get_update_data();
    $comment_counts = wp_count_comments();
    $theme          = wp_get_theme();

    return array(
        'environment' => array(
            'wordpress_version' => get_bloginfo( 'version' ),
            'php_version'       => PHP_VERSION,
            'active_theme'      => $theme->get( 'Name' ) . ' ' . $theme->get( 'Version' ),
            'site_url'          => home_url(),
        ),
        'updates' => array(
            'total_pending'  => (int) $update_data['counts']['total'],
            'plugin_updates' => (int) $update_data['counts']['plugins'],
            'theme_updates'  => (int) $update_data['counts']['themes'],
            'core_update'    => (bool) $update_data['counts']['wordpress'],
        ),
        'content' => array(
            'comments_awaiting_moderation' => (int) $comment_counts->moderated,
            'spam_comments_in_queue'       => (int) $comment_counts->spam,
            'draft_posts'                  => (int) wp_count_posts()->draft,
            'scheduled_posts'              => (int) wp_count_posts()->future,
        ),
        'health' => array(
            'https_active'  => is_ssl(),
            'debug_mode_on' => defined( 'WP_DEBUG' ) && WP_DEBUG,
        ),
    );
}

What's new here:

Stricter permission: manage_options (admins only). Version and update information is reconnaissance data; never expose it to low-privilege users.
Structured output: we return grouped data (environment, updates, content, health), not a pre-formatted text report. This gives AI clients the flexibility to present the information however they choose
Keep callbacks fast: we deliberately skip expensive checks like folder sizes or database size. AI agents may call abilities often; a slow ability makes every conversation slow.

Once registered, you can ask Claude:

"Give me my site's maintenance report and tell me what needs attention."

Claude calls the ability, analyzes the returned data, and explains what requires attention, for example, outdated plugins, a growing spam queue, or debug mode being enabled.

Conclusion

You've now built your first WordPress ability, tested it, and connected it to Claude using the official MCP Adapter. From here, you can apply the same pattern to expose any WordPress functionality as a secure, reusable ability that works seamlessly with AI tools

FAQ on WordPress Abilities API

What is the WordPress Abilities API?

It's a core WordPress feature, added in version 6.9, that lets your site describe its capabilities in a standard format. Plugins, external tools, and AI agents can then discover and safely use those capabilities without custom, one-off integration code.

Do I need to understand MCP to use the Abilities API?

No. You can register and use abilities entirely in PHP, or expose them over the REST API, without touching MCP at all. MCP is only needed if you specifically want an AI agent like Claude to discover and call your ability.

Can I use an ability without connecting it to any AI tool?

Yes. Abilities work from PHP, the REST API, and JavaScript, independent of AI. Many abilities are built purely so other plugins or your own code can call them through one consistent, permission-checked interface.

Is the MCP Adapter part of WordPress core?

No, it's a separate official plugin. WordPress deliberately keeps it outside core so abilities remain protocol-independent. If MCP is ever replaced by something newer, your registered abilities keep working unchanged.

What's the difference between an ability and a REST API endpoint?

A REST endpoint is one specific way to reach functionality over HTTP. An ability is broader: register it once, and it becomes callable from PHP, REST, JavaScript, and MCP, all from a single definition.

Do abilities only work with Claude, or other AI tools too?

Any MCP-aware AI client works, including Claude Desktop, Claude Code, Cursor, and VS Code. The ability itself doesn't know or care which AI is calling it, that's the whole point of the standard.

Useful resources

Abilities API: official Common APIs Handbook entry
MCP Adapter on GitHub: docs, releases, and transport guides
Model Context Protocol specification

How to Create a WordPress Application Password

Go to Users → Profile (or Users → All Users → click your name).
Scroll to Application Passwords.
Type a name for it, something like "Claude MCP," so you remember what it's for.
Click Add New Application Password.
Copy the generated password immediately. WordPress shows it only once. If you lose it, you'll need to generate a new one.
Use this password, not your regular login password, wherever the guide asks for WP_API_PASSWORD.

Complete Guide to WordPress Patterns: Synced, Unsynced, and Partial Sync

WPVibes — Thu, 23 Jul 2026 06:31:01 +0000

If you've ever wondered what the difference is between synced and unsynced WordPress patterns, the short answer is simple: synced patterns update everywhere, while unsynced patterns only affect the copy you're editing.

But that's only part of the story. WordPress also supports Pattern Overrides, a feature that enables partial sync. It lets you keep a pattern's design and structure synced across your site while allowing specific content, such as text or images, to be edited independently in each instance.

In this guide, you'll learn how synced and unsynced patterns work, how Pattern Overrides enable partial sync, when to use each approach, and how to build reusable patterns step by step.

What Are Patterns in WordPress?

A pattern is a saved group of blocks you can insert anywhere on your site without rebuilding it from scratch. Think of it as a template for a recurring piece of content: a call-to-action, a pricing table, or a notice box.

Every pattern you create in WordPress falls into one of two categories, and WordPress asks you to choose which one the moment you save it. Getting that choice right up front saves you from a rebuild later.

What Is a Synced Pattern in WordPress?

A synced pattern stays identical everywhere it's used. Edit it in one place, and that edit applies to every instance across your site automatically. This is the feature formerly known as a reusable block, renamed to synced patterns starting in WordPress 6.3, and it behaves the same way it always did: one source, many locations, always matching.

Synced patterns make sense for anything that needs to stay consistent no matter where it appears: business hours, a newsletter signup bar, a standard disclaimer, or a footer contact block. Update the phone number once, and it's correct everywhere it's used.

How Do You Create a Synced Pattern?

Let's build a real example together: a CTA box, the kind you'd use to promote a plugin or product at the end of a post.

Step 1: Start a new pattern

If you're starting fresh instead, go through the Appearance menu:

If you use a block theme:

Go to Appearance > Editor > Patterns.
Click Add pattern, then Create pattern.

If you use a classic theme:

Go to Appearance > Design > Patterns.
Click Add pattern, then Create pattern.

Step 2: Name it and keep Synced on

Type a name, like "Plugin CTA - Standard."
Choose a category if you want one. This is optional.
Keep the Synced option turned on.
Click Create.

Step 3: Add blocks and design your pattern

WordPress opens a blank canvas. This is where you actually build the pattern, and you can add any block you like here, not just the ones in this example.

Add a Group block. This holds the CTA together.
Add your product logo, then insert a Heading block with a clear CTA, such as “Choose the Right Plan for You.
Add a Paragraph block right below it for a short description, like "Manage everything from one dashboard."
Add a Button block below that, with text like "View Pricing" and "Download Free", and a link to a product page.
Select the Group block, open Styles in the right panel, and add a background color and some padding, so it stands out as a promotional box.

Step 4: Save the pattern

Click Save in the top right corner. Your CTA pattern now exists.

Step 5: Add it to a page so you can see it

Open any post or page.
Click the + button (block inserter) in the top left.
Click the Patterns tab, then My Patterns.
Click your CTA pattern. It gets added at your cursor.
Click Save or Update. Your CTA now shows on the page, with a small purple icon marking it as synced.

Step 6: See the sync in action

Open your pattern again from Appearance > Editor > My Patterns, and change the background color or button style.

Go back to the page you just updated. The change has appeared there too, automatically, with no extra step. That's what "synced" actually means in practice.

What Are Pattern Overrides (Partial Sync)?

Here's the catch with a synced pattern: if you insert the same CTA on ten different posts, every single one promotes the exact same product, since editing it anywhere changes it everywhere. But usually, you want the box design locked while the heading, description, and button change depending on what you're promoting. That's exactly what overrides solve.

An override marks one specific block inside a synced pattern as editable per instance. Everything else, the background color and padding, stays locked and synced. Only the content in the marked block can change from post to post.

How Do You Enable Overrides on a Synced Pattern?

Let's make the button inside our CTA editable on each page, both its text and its link, while keeping the box design locked everywhere.

Open your CTA pattern for editing (Appearance > Editor > My Patterns, then click on it).
Select the Button block inside it.
In the block settings panel, open the Advanced section.
Turn on Enable overrides, and give it a name like "CTA Button."
Click Save.

Now open any page where you've added this CTA. Click directly into the button and change its text, then update its link to point to a different product. Only that page's button changes. The background color and padding stay exactly the same everywhere else, since only the button was marked as an override, not the styling.

What Is an Unsynced Pattern in WordPress?

An unsynced pattern is a starting point, not a shared source. Once you insert it into a page or post, its text, links, and images are ready to edit right away, no extra steps needed. Editing one instance never affects any other place you've used the same pattern.

Unsynced patterns are the better choice when you want a consistent layout but different content each time.

Take an info box: you might use the same background color and border across dozens of posts, but each one flags something different, a warning on one post, a quick tip on another, a "last updated" note on a third. Editing one shouldn't change the message on any of the others.

How Do You Create an Unsynced Pattern?

The steps are almost identical to creating a synced pattern. This time, let's build an info box, since that's the example where each instance usually needs to say something different.

Step 1: Start a new pattern

Same as before, either from a page directly or through the Appearance menu (see Step 1 in the synced section above).

Step 2: Name it and turn Synced off

Type a name, like "Info Box - Flexible."
Choose a category if you want one.
Turn the Synced option off this time.
Click Create.

Step 3: Add blocks and design your pattern

WordPress opens a blank canvas, same as before.

Add a Group block. This holds everything together.
Inside the Group block, add a icon and Paragraph block, and type your message.
Select the Group block, open Styles in the right panel, and set a background color, some padding, and a left border. This is what makes it look like a proper info box instead of a plain paragraph.

Step 4: Save the pattern

Click Save.

Step 5: Add it to a page so you can see it

Open any post or page.
Click the + button (block inserter).
Click Patterns, then My Patterns.
Click your info box pattern to insert it.
Click Save or Update. It shows up on the page. There's no purple icon this time, since it isn't synced.
Click directly into the message text and change it. This works immediately, no extra step.

Step 6: Add it to a second page with different text

Repeat the same steps on another page, and type a completely different message. Both pages now show the same design, but different text, and neither page affects the other.

Right now, this info box just shows a message. But say one page needs a "Learn More" link added right below the text, without changing the box everywhere else. That means adding a whole new block, not just changing text, so simple editing won't do it. Here's where Detach comes in.

How Do You Detach a Pattern?

Detach unlocks full editing on one specific instance of a pattern, so you can add or remove blocks, something that plain text edits and Overrides can't do.

Back to our info box example: you want to add a "Learn More" button right below the message, on just one page.

Select the inserted info box pattern on that page.
Open the three-dot menu in the block toolbar.
Choose Detach.

Add a new Button block right below the message, type "Learn More," and link it wherever it should go.

That one page now shows the message plus a button. Every other page using this same info box pattern still shows just the message, completely untouched.

This works the same way on a synced pattern, with one difference worth knowing. On an unsynced pattern like this info box, Detach is only needed for structural changes like this, since text was already editable without it.

On a synced pattern like our CTA, nothing is editable directly at all, so Detach breaks the entire instance free at once, styling included, not just its content.

What's the Real Difference Between Synced and Unsynced Patterns?

The core difference between synced and unsynced patterns in WordPress comes down to one question: does an edit apply everywhere, or only to the instance you're editing? Synced patterns apply everywhere. Unsynced patterns apply only locally.

	Synced Pattern	Unsynced Pattern
Editing behavior	Updates every instance at once	Updates only the instance you're editing
Best for	Content that must stay identical (footers, CTAs, disclaimers)	Reusable layouts with changing content (info boxes, testimonials)
Text edits	Need Overrides enabled first	Work immediately, no extra step
Block-level changes (add/remove)	Need Detach	Need Detach
Library icon	Purple icon in the pattern list	No special icon
Best for	Shared content	Reusable layouts

When Should You Use Synced vs Unsynced Patterns?

Use a synced pattern when every page should show the exact same thing, like our CTA box. Use an unsynced pattern when each page needs different content in the same design, like our info box.

If most of a pattern should stay locked but one small piece needs to change, reach for Overrides instead. If you need to add or remove a block on just one page, use Detach, on either pattern type.

FAQs on Synced and Unsynced WordPress Patterns

What is the difference between a synced and unsynced pattern in WordPress?

A synced pattern updates every instance across your site when you edit it. An unsynced pattern stays independent, so edits only affect the one instance you're working on.

Can I convert an unsynced pattern to a synced pattern?

Not directly, but Duplicate gives you a shortcut, it asks the sync setting again on the copy. Or build a new pattern from scratch and choose Synced.

How do pattern overrides work in WordPress?

Overrides let you mark one block inside a synced pattern as editable per instance. The rest of the pattern, including layout and styling, stays synced and locked everywhere else.

Do I need to detach an unsynced pattern just to edit its text?

No. Text, links, and images inside an unsynced pattern are editable the moment you insert it. Detach is only needed if you want to add or remove blocks.

What's a real-world example of when to use a synced pattern versus an unsynced pattern?

A CTA promoting the same offer everywhere is a good synced pattern. An info box with a different note on each post is a better fit for an unsynced pattern.

Conclusion

Synced patterns keep things consistent, unsynced patterns keep things flexible, overrides let you edit content while keeping design locked, and Detach gives you full control over one instance when you truly need it. The CTA box and info box built above are small examples, but the same approach applies to nearly any repeating component on a WordPress site.

Once reusable components like this are in place, the next challenge is usually keeping the surrounding content accurate over time, since sections can quietly go stale long after a post is published. That's the exact problem Content Lifecycle Manager is built to solve, helping you track what needs a second look and when, so your site doesn't just look consistent, it stays accurate too.

Your Form Submissions Don't Have to Stay Locked in a Dashboard

WPVibes — Wed, 22 Jul 2026 07:41:02 +0000

Form submissions have a default destiny: land in a database, sit in an admin panel, get checked manually whenever someone remembers to look. That's fine for basic contact form enquiries. It's a missed opportunity for anything where the data itself has value beyond just being stored.

A few situations where this shows up clearly:

Someone's running event registrations and wants a live sign-up counter on the landing page - the kind that builds its own social proof as the number climbs. Someone else is collecting business or member listings through a form and needs a searchable directory, without spinning up a whole separate directory plugin just for that. Or a team needs to check incoming submissions without anyone getting a WordPress login.

All three of these are the same underlying need: taking form data that's normally backend-only and putting it somewhere visible — on an actual page, updating itself, with zero manual maintenance.

So how do you actually put form data on a page?

Normally, this requires custom development — querying a form plugin's database tables, building a template, handling pagination and filtering yourself. Not a huge lift for a developer, but not something most site owners can do themselves either.

Form Vibes Pro has a feature called Data Profiles that handles this without any of that. Point it at a form, configure what to show and how to filter it, and it generates a shortcode (or an Elementor widget, if that's your builder) that renders live data anywhere on a page.

Two display types cover most use cases:
Table — rows and columns, configurable per-column visibility and labels, optional pagination, and an optional live search bar so visitors can find a specific entry themselves rather than scrolling through everything.

Counter — a single number reflecting how many entries match a given filter, with an optional message wrapped around it using dynamic tags (entry count, form name, plugin name). This is the registration-counter use case in its simplest form.

Both pull directly from the Form Vibes database at render time — no caching lag, no manual refresh. A new submission shows up on the page the same way it shows up in the admin.

Filtering matters more than it sounds like it would

The actual configuration worth paying attention to is the filtering layer, since that's what turns "dump all submissions on a page" into something genuinely useful.

Filters work off form field values with a condition operator (contains, equals, etc.), and multiple conditions can be stacked with AND/OR logic. So a directory page can be scoped to "Category equals Web Design AND Status equals Approved" rather than showing every submission that's ever come in, including test entries and rejected listings.

For a table specifically, there's also a separate row-expand option — click a row, see the full submission detail without needing every field crammed into the visible columns. Useful when a form has more fields than reasonably fit in a table view but the extra detail is still worth surfacing on demand.

The internal-team-access angle

One use case worth calling out specifically: giving a team visibility into submissions without WordPress login access at all.

Combine a Data Profile table with WordPress's built-in page password feature, and you get a clean, searchable, password-gated view of submission data that anyone with the password can check — no WordPress account, no admin panel exposure, nothing beyond what's on that one page.

This is a genuinely underused pattern. Client-facing or team-facing dashboards usually get built as custom internal tools; this gets most of the value from two built-in features stacked together. There's a full walkthrough of this specific setup here: sharing form submissions with clients.

One honest limitation

Data Profiles is Pro-only - not available on Form Vibes' free tier. Worth knowing before building a workflow around it, though for anything client-facing or public-facing, the alternative is usually custom development anyway, so the comparison point isn't really "free vs paid," it's "paid feature vs hiring someone to build the same thing from scratch."

Stop Exporting Everything Just to Filter It Afterward

WPVibes — Mon, 06 Jul 2026 06:10:16 +0000

The default workflow for getting specific form submission data out of WordPress looks like this: export everything, open the spreadsheet, delete the rows you don't need, keep what you actually wanted.

It works. But it means doing manual cleanup every single time. And if the same export is needed again next week — same form, same filters, same fields - the entire process repeats from scratch.

There's a better approach: filter before exporting, not after.

The two export options in Form Vibes

Form Vibes has two ways to get submission data out of WordPress, and understanding which one fits which situation saves a lot of repetitive work.

Quick Export is free and available on every plan. Click the button in the submissions toolbar, and all entries for the currently selected form download as a CSV immediately. No configuration, no setup. Up to 1,000 entries per export. Good for one-off backups or full dataset downloads where you genuinely need everything.

Export Profiles are a Pro feature and solve a different problem: recurring exports where the same configuration gets used again and again. Instead of downloading everything and filtering afterward, an Export Profile lets you define exactly what you want - which form, which date range, which field values to filter by, which columns to include - save that configuration once, and re-run it in one click any time you need it.

How Export Profiles actually work

The setup only needs to happen once per report or workflow. When creating a new Export Profile, four things get configured.

Profile Type

Choose between two output options:
Local Download — exports submissions as a CSV file that downloads directly to your computer on demand.

Google Sheets — connects to a Google Spreadsheet via OAuth and pushes every new submission automatically in real time. Once set up, no manual export step is needed at all.

Data Source

This is where you define exactly which submissions to include:

Form — select which form to pull submissions from
Date Range — choose a preset (Last Week, Last Month, Last Quarter) or set a custom window
Status — filter submissions by their current status: Read, Unread, or Spam
Filter Conditions — the most useful part. Add conditions based on any field value: select a field, choose a condition type (equals, contains, not equal, not contain), enter the value, and stack multiple conditions with AND or OR logic between them

So something like "Status equals Read AND Country equals USA AND Registration Type contains Paid" runs automatically every time the profile is used — no manual spreadsheet filtering afterward.

Fields
Choose which columns to include in the exported file. Toggle off anything that isn't needed for that specific export. A finance export might include Name, Email, Amount, and Date. A marketing export from the same form might include Name, Email, and Source only. Two profiles, two field selections, both in one click.

Profile Name
Worth being specific - "Monthly Contact Form Leads" or "Weekly Paid Registrations — USA" is far more useful than "Export 1" when the profiles list grows.

Once published, the profile appears in the Export Profiles list. Click Export Data, confirm, and the file downloads based on saved settings. An export history inside each profile keeps a record of every previously generated file so past exports can be re-downloaded without running the export again.

When this actually matters

The filter-before-export approach pays off most noticeably in two situations.

Recurring reports. If the same subset of data gets exported on a regular schedule — weekly leads, monthly paid registrations, quarterly support requests — setting it up once as a saved profile and running it in one click each time removes the repetitive configuration work entirely.

Different subsets for different people. Sales needs qualified leads. Marketing needs newsletter signups. Finance needs paid registrations. Support needs open requests. One form, four different export configurations, all saved and runnable independently without any of them having to touch settings.

One honest limitation

Export Profiles are a Form Vibes Pro feature. The free Quick Export covers one-off full exports cleanly, but saved configurations with field-level filtering require Pro. Worth knowing upfront before building a workflow around it.

Why Form Submission Analytics Matters More Than a List of Entries

WPVibes — Thu, 02 Jul 2026 05:46:49 +0000

A contact form goes live. Submissions start coming in. Everything looks fine.

But ask a more specific question - is this form doing better or worse than it was three months ago? - and most people genuinely can't answer it without manually counting entries across two different date ranges. A flat list of submissions tells you that something happened. It doesn't tell you the shape of what's happening over time.

This is a gap in almost every form plugin's native entry view: storage without trend data.

What trend data actually catches that a list doesn't

There are three patterns worth knowing how to spot, because each one means something different and calls for a different response.

A sudden drop. Steady submissions, then a sharp fall in a single week or month. This usually means something broke - a plugin update touched the form, the page moved to a new URL, or a layout change pushed the form out of place. The fastest way to confirm: submit a test entry yourself. If it goes through cleanly, the drop is likely traffic-related, not a form issue. If it doesn't submit correctly, that's the problem, found in under a minute instead of days of guessing.

A slow decline. No single bad week, just a gradual downward trend over weeks or months. This usually points to something upstream of the form itself - less traffic reaching the page, content on the page going stale, or something about the form discouraging completion. Looking at the trend week by week, rather than day by day, makes it easier to pin down roughly when the decline started, which helps connect it to whatever changed around that time.

An unrepeated spike. One period - a week, a month - significantly outperforms the baseline, then things return to normal. This is actually good news if you catch it: something drove a burst of traffic to the form. A campaign, a post that got shared, a backlink. Drilling into daily granularity for that window usually reveals exactly which day or days it happened, which makes it possible to figure out what worked and try to repeat it.

None of these three patterns are visible from a list of individual entries. They only show up when submissions are aggregated over time and visualized.

So how do you actually check this?

Most form plugins don't give you a trend view out of the box - just the entry list described earlier. Getting an aggregated view usually means exporting submissions and building the chart manually, or installing something that does the aggregation for you.

Form Vibes is a free WordPress plugin that captures submissions into the database and includes a built-in Analytics dashboard for exactly this. It works across every supported form plugin - Contact Form 7, WPForms, Gravity Forms, Elementor, and others with no separate setup per form, and capture starts automatically the moment the plugin is active.

Analytics lives in two places:
The Analytics page, found at Form Vibes → Analytics, has three controls: a date range picker, a form dropdown (showing total entry count for that form at a glance), and a time filter to group submissions By Day, By Week, or By Month.

Two chart types are available - bar and line, switchable from the same toolbar, and the last view (date range, form, chart type) is remembered automatically the next time the page is opened.

The dashboard widget, enabled from Form Vibes → Settings, sits on the main WordPress admin screen - the first page seen on login. It shows a form dropdown, date range, time filter, a line chart, a total submission count, and an expandable breakdown of entries per form, all without navigating away from the dashboard.

Both are available on the free plan with no Pro upgrade required.

Two chart types, two different questions

Bar charts and line charts of the same data answer slightly different questions, and it's worth being deliberate about which one to reach for.

A bar chart is for period-to-period comparison - was this month better than last month, did a specific campaign move the number. Each bar is a discrete answer to "how many in this window."

A line chart is for direction - is the overall trajectory up, down, or flat. A line makes a slow decline visible in a way a row of bars sometimes doesn't, because the eye naturally reads a slope.

Switching between daily, weekly, and monthly granularity changes what each chart type is good for too. Monthly view is for spotting the big picture across a quarter or more. Daily view is for pinpointing exactly when something changed once you already suspect something did.

One honest limitation worth knowing upfront

Submission analytics measures submissions, not visits. It will tell you that 40 people filled out the form this month versus 60 last month. It will not tell you how many people loaded the page and left without submitting - that's a different metric (conversion rate) that requires pairing form analytics with actual page-view data from something like GA4.

This matters because a drop in submissions has two very different possible causes: fewer people are reaching the form, or the same number of people are reaching it but fewer are completing it. Submission-only analytics can't distinguish between those two on its own - it just tells you the volume changed and roughly when, which is still the necessary first signal even without the full picture.

Two Ways to Give a Client Access to Their Form Data Without a WordPress Login

WPVibes — Mon, 29 Jun 2026 06:30:06 +0000

A client asks to see their form submissions. The solution is usually one of two things: create them a WordPress account, or export the data and email it over.

Both have real downsides. A WordPress login even on a restricted role exposes the dashboard, plugin notices, update alerts, and a dozen things that have nothing to do with their actual request. Non-technical clients end up generating support questions just from being inside an interface they don't need to be in.

Manual exports solve the access problem but create a different one: every time a new submission comes in, you're back to exporting and sending a file. It's not hard, but it's a task that never really ends, and "is this the latest version?" becomes a recurring question on both sides.

There's a cleaner way to handle this that avoids both problems entirely.

Option 1 - A dedicated page the client can bookmark

Instead of WordPress access, give the client a single URL that shows only their submissions, live, with no login required.

The setup, generalized: create a filtered view of the form data scoped to that specific client or form, render it as a table on a normal WordPress page, hide any internal-only fields (IP address, user agent, raw submission IDs - nothing a client needs to see), and publish the page.

Share the URL directly with the client rather than linking it from your site's navigation. The page stays publicly accessible to anyone with the link, so treat the URL itself as the access control.

Option 2 - Sync to a Google Sheet and share it as Viewer

If the client already lives in spreadsheets, skip the custom page entirely and sync submissions directly to a Google Sheet.

The setup: connect a Google account, configure an export that maps form fields to spreadsheet columns, and point it at a specific tab. Every new submission pushes into the sheet automatically from that point forward.

Share the sheet with the client's email and set their permission to Viewer, not Editor - this is the part worth getting right. Viewer access means they can read, sort, and filter the data on their end without any risk of someone accidentally deleting or overwriting a row.

Which one actually fits your situation

Go with the dedicated page when: you want something that looks like part of your site rather than a raw spreadsheet, the client isn't comfortable in Sheets, you need tight control over exactly which fields are visible, or you want built-in search for a high-volume form.

Go with Google Sheets when: the client already works in spreadsheets daily, you want to set it up once and never touch it again, or the client needs to do their own filtering/sorting/sharing without depending on you for anything beyond initial setup.

Nothing stops you from running both at once for the same form - one as the primary client-facing view, the other as an internal backup or reporting source. They operate independently.

What this looks like in practice

Both of these are built into Form Vibes Pro - the page-based view is called a Data Profile, and the spreadsheet sync is a Google Sheets Export Profile. Neither requires touching code or setting up a separate integration tool; both are configured from inside WordPress and connect to forms from any of the major form plugins.

How to Build a Form Submission Review Workflow for Your WordPress Team

WPVibes — Thu, 25 Jun 2026 08:33:55 +0000

When a form submission arrives, someone on the team needs to review it, act on it, and make sure nothing falls through. If the current process is "it lands in an inbox and whoever sees it first deals with it" - the failure modes are predictable. Leads get missed. The same entry gets followed up twice. A client asks why nobody responded and there is no record of what happened.

This is not a tooling problem specific to any one form plugin. It exists with Contact Form 7, WPForms, Gravity Forms, or any other builder, because form plugins are built to collect data, not to manage it as a team. The submissions screen in most of them is a flat list with no workflow layer on top.

Here is what a proper team submission workflow needs, and how to build one inside WordPress.

What breaks without a team workflow

No visibility into what has been handled. Every submission looks identical whether it arrived five minutes ago or was actioned three days ago. Team members have no way to tell without opening each entry individually or asking a colleague directly.

No way to leave context for the next person. If you call a lead back and leave a voicemail, that context lives in your memory or a separate note-taking tool - disconnected from the actual submission record. The next person who opens that entry has no idea what already happened.

No record of who changed what. If a field value gets edited, there is no audit trail showing who made the change or when. For any site where more than one person edits data, this is a real accountability gap.

No controlled access for different people. A junior team member reviewing submissions probably should not have delete access. A client wanting to see their own leads should not have full WordPress admin. Without a permission system specific to submission data, it is all-or-nothing access for everyone.

Building the workflow piece by piece

Status tracking for at-a-glance visibility
Every new submission should arrive in a default "needs review" state, visually distinct from entries that have already been actioned. As team members work through submissions, they update the state - read, unread, or flagged as irrelevant.

The practical value of this is that anyone on the team can filter to "unread" or "pending" and immediately see exactly what needs attention, without having to ask a colleague or scroll through entries that have already been handled. For a two-person team reviewing daily enquiries, this single change removes the recurring "did you see this one?" message entirely.

Internal notes attached to each entry
Status alone tells you whether something has been actioned. It does not tell you what was done. A note field attached directly to each submission solves this - "Called back, left voicemail, following up Friday", "Quote sent, awaiting response", "Duplicate of an earlier entry, do not action again."

The notes should be completely internal, never visible to the person who submitted the form, and timestamped so the sequence of actions is clear when multiple people are involved.

Role-based access control
Not everyone working with submission data needs the same permissions. A useful framework breaks access into four tiers:

View-only access for clients who need to see their own leads without any ability to change or delete data
Review access for junior team members - view entries, add notes, update status, but no export or delete
Full working access for account managers - everything above plus export capability
Complete access for senior team members or administrators Define these tiers once per role and they apply automatically to every user assigned that role.

An audit trail for every action
Every edit to a submission and every export action should be logged automatically - who made the change, what was altered, and when. This matters in two specific situations: when a submission appears to have been edited and you need to know what the original value was, and when an export was run and you want to know why. Logging an "export reason" alongside the username and timestamp turns a simple action log into a genuinely useful accountability record.

How Form Vibes implements this

Form Vibes Pro builds exactly this workflow into WordPress.

Submission Status marks every new entry as Unread by default, turning green when marked Read after review, or red when flagged as Spam. Filtering the dashboard to Unread at the start of a session shows exactly what needs attention.

Notes attach permanently to individual entries, visible only to users with Form Vibes access, never to the form submitter. Multiple team members can add separate timestamped notes to the same entry, building a clear history of what happened and when.

Role Manager gives granular control over four WordPress user roles - Editor, Author, Contributor, and Subscriber - toggling permissions independently across submissions, notes, status, and exports. A Subscriber role with view-only access works well for client logins; a Contributor role with notes and status access but no delete works well for junior team members.

The Activity Log records every field edit and export action automatically, including an Export Reason prompt that captures why an export was run.

Getting started

None of this requires migrating away from your existing form plugin. Submission Status, Notes, and Role Manager work as a layer on top of Contact Form 7, WPForms, Gravity Forms, Elementor, and other supported builders - no changes to your existing forms.

For a two-person team currently relying on "whoever sees it first handles it," even just status tracking and notes removes most of the daily back-and-forth. Role-based access becomes worth setting up once clients or junior team members need their own access without full WordPress admin.

DEV Community: WPVibes

How to Save Contact Form 7 Submissions to Google Sheets

Does Contact Form 7 Save Submissions Anywhere on Its Own?

Is Google Sheets Sync a Free or Pro Feature?

How to Connect Contact Form 7 to Google Sheets

Create Your Google API Credentials

Connect Form Vibes to Google Sheets

Set Up the Google Sheets Connection for Your CF7 Form

Choose the Form, Spreadsheet, and Worksheet

Map Your Fields on the Columns Mapping Tab

What Happens After Someone Submits Your Contact Form 7 Form?

Why Aren't Contact Form 7 Submissions Reaching Google Sheets?

Why Form Vibes for Contact Form 7 and Google Sheets?

Conclusion

Frequently Asked Questions

What's New in WordPress 7.1: Tab Block, Responsive Design, Pseudo States, and much more

How Does WordPress 7.1 Change the Way You Design Pages?

Style Every State Without CSS

What's New With the Notes Feature in WordPress 7.1?

How Does Client-Side Media Processing Speed Up Your Uploads?

What New Blocks Does WordPress 7.1 Add?

Tabs Block

Playlist Block

What's New for the Icon Block in WordPress 7.1?

Custom SVG Icons API

Icon Block Toolbar Improvements

What Else Changed in the WordPress Admin?

What Other Small Improvements Should You Know About?

What Developer Experience Improvements Does WordPress 7.1 Bring?

Better Block Bindings

Expanded Abilities API

Final Thoughts

Frequently Asked Questions

Custom SVG Icons: An Exciting WordPress 7.1 Feature

What You'll Build

Prerequisites

Step 1: Understand the API in Three Minutes

Step 2: Set Up the Plugin and Register the Collection

Step 3: Register Icons Two Ways

3.1: Register an inline icon with content

3.2: Register icons from .svg files

Step 4: Register a Whole Folder of Icons (Bulk Pattern)

Step 5: Use the Icons in Three Places

5.1: In the core/icon block

5.2: In PHP via wp_get_icon()

5.3: As a custom block icon in register_block_type()

Step 6: Style Custom Icons with CSS

6.1: Use currentColor for color inheritance

6.2: Override color when a specific color is needed

6.3: Size and hover states

6.4: When to use CSS classes vs. the size argument

Step 7: Remove Icons and Collections

7.1: Remove a single icon

7.2: Remove the entire collection on deactivation

Get the Full Plugin

How Custom Icons Fit the Bigger Picture

Wrapping Up

Frequently Asked Questions

PHP-Only Blocks in WordPress 7.0: The Developer's Complete Guide

Who Is This Guide For?

What Will You Build?

Prerequisites

Step 1: Set Up the Plugin

1.1 - File structure

1.2 - The main plugin file

1.3 - The loader

Step 2: Build the Notice Block

2.1 - Create the block class

2.2 - Define the attributes

2.3 - Add block supports

2.4 - Write the render callback

2.5 - Add the CSS

2.6 - See it working

Step 3: Build the Category Display Block

3.1 - Create the block class

3.2 - Define the attributes (all 4 types)

3.3 - Block supports

3.4 - Write the render callback

3.5 - Render a single category

3.6 - The ACF image with fallback

3.2: Register icons from `.svg` files

6.4: When to use CSS classes vs. the `size` argument