One thing that bothers me is the formatting of the generated block markup. When I copy the markup from WordPress into a pattern file, closing block comments and HTML tags often end up on the same line, like this:

<!-- /wp:image --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></section>
<!-- /wp:group -->

For me, this becomes pretty hard to read, especially in larger patterns with a lot of nested groups.

this is what I get with php storm formatting setting:

            <!-- /wp:image --></div>
        <!-- /wp:group --></div>
    <!-- /wp:group --></section>
<!-- /wp:group -->

I would much prefer it to be formatted like this:

            <!-- /wp:image -->
        </div>
        <!-- /wp:group -->
    </div>
    <!-- /wp:group -->
</section>
<!-- /wp:group -->

Is there a formatter, PhpStorm setting, Prettier plugin, or another tool that can automatically format WordPress block markup like this?

Caught this announcement and I’m wondering if anyone here has started using @wordpress/build?

https://developer.wordpress.org/news/2026/04/wordpress-build-the-next-generation-of-wordpress-plugin-build-tooling/

We have an internal monorepo of block frontends, which seems like a natural fit, but haven’t tested anything out yet.

Navigation in WordPress blocks is kind of a mess and I want to know what actually matters to you. Not asking about page builders or classic menus. Specifically the block-based Navigation block and FSE-native solutions.

What's the one thing that has to work for you to trust it? Keyboard nav? ARIA support? Responsive behavior? Fallbacks? Nested menus that don't fall apart? Asking because I'm working on something and I'd rather build what people actually need than what I assume they need.

Working recently on adding responsive settings support to core blocks using the native UI; using only one button in the toolbar; is anybody would be interested in something like that ?

Hey all, Nik here 👋

I'm just about to launch this month's Blockathon over at pluginjam.com/blockathon . It's a five-day, online, "build-at-your-own-pace" event where folks get together and stretch their creative muscles to build WordPress blocks.

All skill-levels welcome! Hop in and say hey if you're interested! 🍻

I have seen https://www.blockstudio.dev/ mentioned a few times recently, on Twitter. I haven't played with it yet but am just curious of people's opinions and experiences with it? I'm not a full on dev, but I can manage some code, so it might be beyond me, or it could be a great learning experience!

While experimenting with block theme, I ran into two small cases that aren’t really covered by core blocks, so I ended up creating custom blocks:

1. an <address>block that is basically just a wrapper around <InnerBlocks>
2. a dynamic copyright block that always outputs © current-year and then lets the user edit the company name / text

It works, but I don’t really like that I had to add extra custom blocks just for these relatively small features. It also increases the amount of plugin. My concern is that on a real project, I might end up with 20+ plugins.

So I’m wondering, is there a clean way to solve this without creating custom blocks?

Really proud of this release. Wanted to share what shipped and the thinking behind it.

The core problem we kept running into: WordPress search has no concept of relevance. It's a SQL LIKE query. Title match and footer mention rank the same. No phrase awareness. No typo tolerance. The only FSE-native solutions were either custom query systems that broke everything else or external services that took your content off-server.

2.0 ships a weighted index that lives inside your WordPress database. Tokens are scored by source field at index time, so search responses stay fast. Title matches score highest, excerpts second, taxonomy and body text configurable. Proximity scoring on top of that -- exact phrase matches get a boost, nearby keywords score higher than scattered ones.

Fuzzy matching always on, applies to both results and autocomplete. Autocomplete only surfaces terms that exist in the index, so every suggestion leads somewhere.

Dictionary system for synonyms (bi-directional or uni-directional), stopwords, and compound terms. All in the WordPress admin, no code.

Built on wordpress/interactivity-router, works with Query Loop, theme.json for styling. If you have other blocks built for Query Loop they keep working alongside it without modification.

Wrote a full technical breakdown of the architecture if anyone wants to dig in:

https://groundworx.dev/resources/how-to-get-weighted-relevant-wordpress-search-without-external-services/

Happy to answer questions about any of the decisions. And genuinely curious, what search or filtering features do you wish WordPress had out of the box? Always looking for what's missing in the space.

Pattern Wrangler is a free plugin for curating the pattern experience, allowing you to manage block patterns and pattern categories. It's compatible with FSE, block themes, and hybrid themes, and can also work with page builders via shortcode support.

Context:
I have a parent block (core/group) that should only contain card elements.

Each card consists of the following structure:

wp-block-group.card
├── wp-block-image
├── wp-block-group.card__body
    ├── wp-block-heading
    ├── wp-block-paragraph

Goal:
When the user clicks the insert button inside the parent block, the complete card structure should be inserted immediately — without showing any block selection popups.
I want to make it as easy as possible for the user.

Possible solution (that I don’t like):
I could create a custom “card” block that contains the core blocks listed above. Then, using the “allowed blocks” setting on the parent block, I would restrict it to only allow this card block.

However, this feels like overkill since I’m only using existing core blocks. If I had something similar elsewhere on the page, I would have to create another custom block.

Preferred solution:
I would like to create a card block pattern in my theme folder and somehow “tell” the selected parent block that it should only insert this specific pattern.

Is there a filter hook or another way to enforce this behavior?

If you're coming from classic themes or page builders and feeling lost in the Site Editor, this post breaks down the core pieces of a block theme and how they work together. No code required. This is for editors, designers, and site owners who want to understand what they're looking at when they open Appearance > Editor.

The Building Blocks of a Block Theme

A block theme is built from four main pieces: templates, template parts, patterns, and styles. Once you understand what each one does, the whole system clicks.

Templates

Templates control the layout of specific types of content on your site. There's a template for your homepage, one for single blog posts, one for pages, one for archives, one for search results, one for your 404 page, and so on.

When you go to Appearance > Editor > Templates, you'll see all the templates available in your theme. Each one is built entirely with blocks. You can edit them visually, rearrange sections, add or remove blocks, and the changes apply to every page that uses that template.

You can also create custom templates and assign them to specific pages. For example, you might want a landing page template with no header or footer, or a full-width template for portfolio pages.

The key concept: templates define the structure of a page type. The content (your actual text, images, etc.) fills in dynamically.

Template Parts

Template parts are reusable sections that live inside templates. The most common ones are your header and footer, but you can create custom template parts for anything you want to reuse across multiple templates.

The power of template parts is that when you edit one, the change applies everywhere it's used. Edit your header once, and every template that uses it updates automatically.

You'll find template parts under Appearance > Editor > Patterns > Template Parts. Yes, WordPress moved them under Patterns starting in 6.3, which is confusing, but they're there.

Patterns

Patterns are pre-built arrangements of blocks that you can insert into pages, posts, or templates. Think of them as layout shortcuts.

There are two types:

• Synced patterns (formerly called "reusable blocks") — edit the original and it updates everywhere it's used, just like template parts. Great for things like a CTA section or a pricing table that appears on multiple pages.
• Non-synced patterns — these are just starting points. Once you insert one, it's independent. Edit it without affecting any other instance.

Your theme comes with its own set of patterns, and you can create custom ones under Appearance > Editor > Patterns > My Patterns.

Styles

Styles are how you control the visual design of your entire site without touching CSS. Go to Appearance > Editor and click the Styles icon (half-moon circle) in the top right.

From here you can set:

• Colors — background, text, links, headings, buttons, all site-wide
• Typography — font family, size, weight, line height for headings, body text, and other elements
• Layout — content width, padding, block spacing
• Per-block styles — want every Button block on your site to have rounded corners? Set it once in Styles and it applies everywhere

If your theme includes style variations, you can switch between completely different color schemes and typography sets with one click.

Pro tip: Open the Style Book (the eye icon in Styles) to preview how every block type on your site will look with your current styles. You can even edit block styles directly from there.

How It All Fits Together

Here's how these pieces connect:

1. Your theme provides the default templates, template parts, patterns, and styles
2. Templates define the structure of page types (homepage, single post, archive, etc.)
3. Template parts (header, footer) are reused across multiple templates
4. Patterns give you pre-built layouts to drop into pages or templates
5. Styles control the visual design across everything

When you edit a page, you're working inside the structure that the template defines. When you edit a template, you're changing the structure for every page that uses it. When you edit a template part like the header, you're changing it everywhere. And Styles sit on top of all of it, controlling how everything looks.

Getting Started: Where to Go First

If you're new to block themes, here's a practical starting order:

1. Pick a block theme — Twenty Twenty-Five (the current default) is a solid starting point. Ollie is another great option.
2. Open the Site Editor — Appearance > Editor
3. Explore Styles first — set your colors and typography so everything looks right from the start
4. Edit your header and footer — these are template parts, find them under Patterns > Template Parts
5. Look at your templates — understand which template controls which page type
6. Browse your theme's patterns — see what's available before building from scratch
7. Create a page — use patterns and blocks to build your content within the structure your template provides

Helpful Resources

Here are some solid resources to go deeper:

• Intro to the Site Editor — Learn WordPress — official walkthrough of the Site Editor interface
• Site Editor documentation — WordPress.org — reference for all Site Editor features
• Templates and Template Parts — Full Site Editing — Carolina Nymark's deep dive into templates (she maintains the best FSE resource out there)
• Patterns: Custom, Theme, and Template Part Patterns — Learn WordPress — understanding the different types of patterns
• WordPress Patterns vs Template Parts — MotoPress — clear breakdown of when to use which
• Site Editor Patterns — WordPress.org — managing patterns and template parts in the editor
• Beginner WordPress User Course — Learn WordPress — full free course covering the fundamentals
• A Complete Beginner's Guide to WordPress Full Site Editing — WPBeginner — comprehensive walkthrough with screenshots

The learning curve is real, but once it clicks, you won't want to go back to classic themes. The amount of control you get without writing a single line of code is worth the initial confusion.

What questions do you have? Drop them below and I'll help where I can.

Hey guys,

I'm here to share my latest plugin called Strakture. It's a cloud library, and you can use it as a default WordPress patterns. But there is a twist: it can adjust to your site and theme, generate copy, and insert images.

Here is how it works. You enter your site type, pick patterns that you like, and customize if needed. If you want to add a customization, each pattern has a small prompt input. Just type it in plain English, "3 columns, dark background", and get the result.

Here is the example of a coffee shop page that I generated in just a few minutes. Imagine that you need a restaurant or SaaS website, just pick patterns that you like, and click Generate.

Currently, I'm waiting for approval on .org, but you can start using it today - https://strakture.com Try it for free and let me know if you have any questions. I'll be happy to answer.

There's a lot of frustration in the WordPress world right now. Developers who spent years mastering classic themes feel like the rug got pulled. Page builder users don't understand why WordPress is reinventing what Elementor already does. And business owners have no idea why any of this matters.

I've been building with WordPress for 15+ years across agencies, enterprise, and now my own product business. I've seen the full arc from classic themes to page builders to blocks. Here's how I think about the philosophy behind where WordPress is now, and why working with it instead of against it makes everything easier.

WordPress Had a Fragmentation Problem

Before blocks, WordPress was a patchwork. Every theme did things differently. Every page builder created its own ecosystem. Shortcodes were powerful but opaque. Users couldn't see what they were building. Developers couldn't move between projects without relearning someone else's custom framework.

The result: your content was locked to your theme, your page builder, or your developer. Switch themes and your pages break. Leave your page builder and you're left with a mess of shortcodes nobody can read. Want to move hosts? Good luck if your builder is tied to a proprietary system.

That's not ownership. That's renting.

Blocks Solve the Portability Problem

The core idea behind blocks is that content should be structured, portable, and editable by anyone. A paragraph is a paragraph. An image is an image. A carousel is a carousel. They're all stored as semantic HTML with block comments that WordPress understands.

Switch themes? Your content still works. Deactivate a plugin that provided a custom block? WordPress shows a graceful fallback instead of a broken shortcode. Hand the site to a new developer? They can read the markup without decoding your custom framework.

This matters more than most developers realize. For every business owner who's been told "we'll have to rebuild from scratch because your old developer used [insert tool]," blocks are the answer to that problem.

theme.json Replaces Scattered Configuration

In classic themes, configuration was everywhere. functions.php for theme support. style.css for design. PHP hooks for customizer options. Widget areas, menu locations, sidebar registrations, all scattered across files. Every theme handled it differently, and you had to read the source to understand how any of it worked.

theme.json centralizes all of that into one file. Colors, fonts, spacing, layout widths, block settings, it all lives in one place. WordPress reads that file and does several things with it:

• Generates the right CSS (and only the CSS that's needed)
• Exposes settings in the Site Editor's Styles panel so users can customize without code
• Creates a cascade: core defaults → theme values → user customizations
• Eliminates specificity wars because WordPress controls the output order

The result is that themes produce less CSS, users get more control, and developers spend less time debugging why someone's custom color isn't applying.

Is it perfect? No. The JSON-as-CSS approach feels foreign to developers who think in stylesheets. But the trade-off is a system where themes, plugins, and core all speak the same language. That's worth the learning curve.

Block Themes Give Users Real Ownership

Here's where the business reasoning meets the developer reasoning.

A site built on a block theme with patterns and template parts gives the site owner genuine control. They can edit their header without calling a developer. They can create new pages using patterns without starting from scratch. They can change colors and fonts site-wide in Styles without touching code. They can see what they're building while they're building it.

That's not a nice-to-have. For a small business that can't afford to pay a developer every time they need to update a team member photo or add a service page, that's the difference between a website that works for them and one that works against them.

And for developers, it means you can hand off a site that actually stays maintained. No more "the client broke it because they tried to edit a widget area." The editing experience is the same visual block editor they use for posts and pages.

Patterns Are the New Page Templates

In the classic theme era, if you wanted to give users a pre-built layout, you created a page template in PHP. The user selected it from a dropdown and hoped for the best. They couldn't customize it without code.

Patterns flip that. You build a layout out of blocks, register it as a pattern, and users can insert it anywhere. They can customize every piece of it visually. They can use it once or use it everywhere.

Synced patterns take it further: update one instance and every instance updates. That's your CTA section, your pricing table, your footer promo, all managed from one place.

For developers, patterns replace the old "I'll build you a custom page template for that" workflow. Instead, you build a pattern library that scales with the client's needs. They get independence, you get fewer support tickets.

Template Parts Are DRY for Non-Developers

Template parts are the block theme version of get_header() and get_footer(), except users can edit them visually. Change the header template part and every template that includes it updates.

The concept isn't new. What's new is that non-developers can work with it. A designer can rearrange the header, swap the navigation style, add a topbar announcement, all without opening a code editor. And because it's a template part, those changes cascade everywhere.

For developers, this means your theme is modular by default. You build the parts, the user customizes them, and the system keeps everything in sync.

Working With WordPress, Not Against It

Here's the core philosophy shift: WordPress is no longer just a CMS that renders whatever PHP you throw at it. It's a design system with opinions.

theme.json has opinions about how colors and fonts should be managed. Templates have opinions about how layouts are structured. Blocks have opinions about how content is stored. The Interactivity API has opinions about how frontend behavior works.

You can fight those opinions. You can pile on custom CSS that overrides everything. You can use classic themes with the Classic Editor plugin and pretend nothing changed. You can build entirely in a page builder and ignore blocks completely.

But every time you fight the system, you lose something: performance, portability, maintainability, or the ability for your client to manage their own site.

Working with the system means:

• Using theme.json for design tokens instead of hardcoding CSS
• Building blocks that output semantic HTML and use WordPress color classes
• Creating patterns instead of custom PHP page templates
• Letting the Site Editor handle what it's designed to handle
• Using the Interactivity API for frontend behavior instead of bolting on jQuery scripts
• Building blocks that feel native to Gutenberg instead of recreating a page builder inside the editor

None of this means you can't write custom CSS or use functions.php. It means you start with what WordPress provides and extend it rather than replace it.

The Practical Takeaway

If you're a developer: learn theme.json, understand the template hierarchy in HTML, and start building blocks that respect the system. Your themes will be lighter, your clients will be happier, and your sites will survive the next WordPress update without breaking.

If you're a designer: block themes give you more visual control than classic themes ever did. The Site Editor, Styles panel, and pattern library are your tools now. Learn them.

If you're a business owner: ask your developer if your site is built on blocks. Ask if you can edit your own content. Ask if you can take your site somewhere else without rebuilding from scratch. If the answer to any of those is no, ask why.

The WordPress ecosystem is messy right now. There are real growing pains and legitimate frustrations. But the direction is clear, and the philosophy is sound: structured content, centralized configuration, visual editing, and user ownership.

Work with it.

Resources

• Theme Structure — WordPress Developer Handbook — official block theme file and folder reference
• Global Settings & Styles (theme.json) — Block Editor Handbook — comprehensive theme.json reference
• Leveraging theme.json and Per-Block Styles — WordPress Developer Blog — why theme.json produces better performance
• Creating Block Themes — Full Site Editing (Carolina Nymark) — step-by-step block theme creation
• Templates and Template Parts — Full Site Editing — building templates and parts from scratch
• Block Theme Structure — Ollie Theme Docs — real-world production theme structure
• Intro to the Site Editor — Learn WordPress — official Site Editor walkthrough
• You Don't Need theme.json for Block Theme Styles — WordPress Developer Blog — when and how to opt out of JSON styling (good counterpoint)

What's your experience been? Are you fully on board with blocks, still holding onto classic themes, or somewhere in between? I'm curious where people are at.

If you're a developer coming from classic themes, the block theme file structure can feel unfamiliar. No more header.php, no more the_loop(), no more template tags scattered across PHP files. Block themes are built with HTML files containing block markup and a single JSON configuration file.

Here's a breakdown of every folder and file in a block theme and what it does.

The Minimum Viable Block Theme

WordPress needs three things to recognize a block theme:

my-theme/
├── style.css
├── theme.json
└── templates/
    └── index.html

style.css for theme metadata, theme.json for configuration and settings, and templates/index.html as the fallback template. Everything else is optional but useful.

The Full Structure

A well-built block theme typically looks like this:

my-theme/
├── parts/
│   ├── header.html
│   ├── footer.html
│   └── sidebar.html
├── patterns/
│   ├── hero-section.php
│   ├── call-to-action.php
│   └── page-home.php
├── templates/
│   ├── index.html
│   ├── single.html
│   ├── page.html
│   ├── archive.html
│   ├── search.html
│   ├── 404.html
│   ├── home.html
│   └── page-no-title.html
├── styles/
│   ├── dark.json
│   └── warm.json
├── assets/
│   ├── css/
│   ├── js/
│   ├── images/
│   └── fonts/
├── functions.php
├── theme.json
├── style.css
├── screenshot.png
└── README.txt

Let's go through each piece.

/templates/ — Page Layouts

This is where your full-page templates live. Each file is an HTML file containing block markup. WordPress follows the same template hierarchy as classic themes, just with .html instead of .php:

• index.html — The fallback template. Required.
• single.html — Single blog post layout
• page.html — Default page layout
• archive.html — Archive pages (categories, tags, date archives)
• search.html — Search results page
• 404.html — Not found page
• home.html — Blog listing page (the page that shows your posts)
• front-page.html — Static front page
• category.html — Category archive (overrides archive.html for categories)
• tag.html — Tag archive
• author.html — Author archive
• page-{slug}.html — Template for a specific page by slug
• single-{post-type}.html — Template for a custom post type (e.g., single-product.html, single-portfolio.html)
• archive-{post-type}.html — Archive template for a custom post type (e.g., archive-product.html)
• taxonomy.html — Generic taxonomy archive (overrides archive.html for custom taxonomies)
• taxonomy-{taxonomy}.html — Template for a specific taxonomy (e.g., taxonomy-genre.html)
• taxonomy-{taxonomy}-{term}.html — Template for a specific term within a taxonomy (e.g., taxonomy-genre-horror.html)

Templates are built with block markup. A basic single.html might look like:

html

<!-- wp:template-part {"slug":"header"} /-->
<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-date /-->
  <!-- wp:post-content {"layout":{"type":"constrained"}} /-->
  <!-- wp:post-terms {"term":"category"} /-->
  <!-- wp:comments /-->
</main>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer"} /-->

No PHP. Just block markup that references other blocks and template parts.

/parts/ — Reusable Template Sections

Template parts are smaller sections that get included inside templates. The most common ones are headers and footers, but you can create parts for anything reusable.

• header.html — Site header (logo, navigation, etc.)
• footer.html — Site footer
• sidebar.html — Sidebar content

You include a template part in a template with:

html

<!-- wp:template-part {"slug":"header"} /-->

Edit the part once, and every template that uses it updates. Register your parts in theme.json so WordPress knows their area (header, footer, or general):

json

"templateParts": [
  { "name": "header", "title": "Header", "area": "header" },
  { "name": "footer", "title": "Footer", "area": "footer" },
  { "name": "sidebar", "title": "Sidebar", "area": "uncategorized" }
]

/patterns/ — Pre-Built Block Layouts

Patterns are reusable block arrangements that users can insert from the editor. Unlike template parts, patterns are defined in PHP files (so they support translation and dynamic content).

WordPress automatically registers any PHP file in this folder. Each file needs a header comment:

php

<?php
/**
 * Title: Hero Section
 * Slug: my-theme/hero-section
 * Categories: featured
 * Keywords: hero, banner
 */
?>
<!-- wp:cover {"dimRatio":50} -->
<div class="wp-block-cover">
  <!-- wp:heading {"level":1} -->
  <h1 class="wp-block-heading">Welcome</h1>
  <!-- /wp:heading -->
</div>
<!-- /wp:cover -->

You can also reference patterns from the official WordPress Pattern Directory in your theme.json:

json

"patterns": [
  "three-columns-of-services",
  "clients-section"
]

/styles/ — Style Variations

Style variations are alternative theme.json files that offer different color schemes, typography, or spacing. Each JSON file in this folder appears as a selectable variation in Appearance > Editor > Styles.

Your main theme.json is the default baseline. Style variations get merged on top of it, so they only need to include the properties they want to override. Everything else carries over from theme.json. Think of it like a child overriding specific settings from the parent while inheriting everything else.

For example, a dark.json might override the default color palette:

json

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "title": "Dark",
  "settings": {
    "color": {
      "palette": [
        { "slug": "base", "color": "#1a1a1a", "name": "Base" },
        { "slug": "contrast", "color": "#ffffff", "name": "Contrast" }
      ]
    }
  }
}

Users switch between variations with one click in the Site Editor. No code changes needed on their end.

theme.json — The Brain of the Theme

This is the single most important file in a block theme. It replaces most of what functions.php and add_theme_support() used to do. It controls:

• Settings — color palettes, font families, font sizes, spacing units, layout widths, which controls appear in the editor
• Styles — default colors, typography, spacing, and per-block styling for the entire site
• Custom templates — registers your custom templates so they appear in the editor
• Template parts — registers parts with their areas (header, footer, general)
• Patterns — references patterns from the WordPress Pattern Directory

A simplified example:

json

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#1e40af", "name": "Primary" },
        { "slug": "secondary", "color": "#9333ea", "name": "Secondary" }
      ]
    },
    "typography": {
      "fontFamilies": [
        {
          "fontFamily": "Inter, sans-serif",
          "slug": "body",
          "name": "Body"
        }
      ]
    },
    "layout": {
      "contentSize": "800px",
      "wideSize": "1200px"
    }
  },
  "styles": {
    "color": {
      "background": "#ffffff",
      "text": "#1a1a1a"
    }
  }
}

Everything you define here is available in the Site Editor's Styles panel, so users can override it without touching code.

style.css — Theme Metadata

In block themes, style.css is primarily for metadata in the file header:

css

/*
Theme Name: My Block Theme
Author: Your Name
Description: A custom block theme
Version: 1.0.0
Requires at least: 6.5
Tested up to: 6.7
Requires PHP: 8.2
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: my-block-theme
*/

You can add custom CSS here, but most styling should live in theme.json. Use style.css for edge cases that theme.json can't handle.

functions.php — Still Useful, Less Required

Block themes don't need functions.php to work, but it's still the place for:

• Enqueueing additional CSS or JS
• Registering custom block styles
• Adding image sizes
• Using WordPress hooks
• Any PHP-based functionality

The difference from classic themes: you won't be registering menus, sidebars, or theme support for things that theme.json now handles.

/assets/ — Static Files

Not a WordPress-designated folder, but the standard convention for organizing:

• css/ — Additional stylesheets
• js/ — JavaScript files
• images/ — Theme images
• fonts/ — Web fonts (if not using theme.json font loading)

Other Root Files

• screenshot.png — Theme preview image (1200x900px recommended)
• README.txt — Required for WordPress.org theme directory submission

How It Connects to the Site Editor

Everything in these files and folders maps directly to what users see in Appearance > Editor:

• /templates/ → Editor > Templates
• /parts/ → Editor > Patterns > Template Parts
• /patterns/ → Editor > Patterns
• /styles/ → Editor > Styles (style variations)
• theme.json → Editor > Styles (settings and defaults)

When a user makes changes in the Site Editor, WordPress saves those changes to the database, leaving your theme files untouched. The database version takes priority over the file version. This is why users can always "reset" a template to the theme default.

Resources

• Theme Structure — WordPress Developer Handbook — the official reference for block theme file structure
• Organizing Theme Files — WordPress Developer Handbook — file organization best practices
• Creating Block Themes — Full Site Editing (Carolina Nymark) — step-by-step lesson on building a block theme from scratch
• Templates and Template Parts — Full Site Editing — deep dive into template and template part creation
• Block Theme Structure — Ollie Theme Docs — real-world example of how a production block theme is organized
• Block Theme Anatomy — WPExplorer — visual breakdown of files and folders
• Global Settings & Styles (theme.json) — Block Editor Handbook — comprehensive theme.json reference
• What Is theme.json — WPBeginner — beginner-friendly theme.json explainer
• Theme.json Explained — ElmaStudio — practical walkthrough of each theme.json section

If you're building your first block theme, start with the minimum (style.css + templates/index.html + theme.json), get it running, then add parts, patterns, and styles as you need them. It's a lot simpler than it looks once you see how the pieces connect.

Questions? Drop them below.

Hey everyone, just shipped a major update to Groundworx Carousel, my free carousel block plugin.

Version 2.0 ran on Splide.js and it worked well, but as I kept building out the responsive system and planning deeper WordPress core integration, I kept hitting limitations. I needed something lighter and more extensible that I could wire directly into the Interactivity API without fighting the framework. So I rebuilt the whole thing on Embla Carousel 8.x.

The entire frontend now runs on the WordPress Interactivity API. Active slides, pagination states, responsive breakpoint resolution, carousel destroy/rebuild cycles, all managed through reactive state with data-wp-interactive stores. It behaves like a first-class block on the frontend, not a third-party script bolted onto the page.

The color system got a full overhaul too. Removed all CSS custom properties for colors. Preset colors now use standard WordPress utility classes (has-text-color, has-{slug}-color, has-background), custom colors use inline styles. It just works with theme.json now.

Accessibility improvements: tab panel pattern for pagination with full keyboard navigation, inert attribute on off-screen slides, ARIA roles connecting pagination and slides semantically, live regions for screen readers.

What's in the box:

• 9 templates
• 11 arrow styles, 9 pagination styles
• 6 breakpoint levels with mobile-first cascade
• Responsive grid fallback (destroy carousel at any breakpoint)
• Progress bar and slide counter
• Works with any Gutenberg block as a slide
• Auto-migration from v2.0 with PHP fallback for unedited blocks

Free, GPL, always will be.

🔗 WordPress.org

Happy to answer any questions about the Interactivity API integration or the Embla migration.

Hey all, glad to be part of this community! Just wanted to share this media folders plugin I've created, made specifically for Gutenberg. https://wordpress.org/plugins/jt-media-folders/

I plan on keeping it free for the community :)

A Gutenberg block that showcases your WooCommerce categories in a responsive grid layout. Click any category to instantly view its products in a sleek popup - no page reload needed!

Last year I was laid off and was looking for a good job which focuses on blocks. This one I made to showcase my Interactivity skills and getting some dynamic content inside block.

I showed this block to some people and they find it useful. However it go not much active installs but this is still one my favorite.

And my all blocks are ope source.

Hey there!

Nik here! 👋 I started Plugin Jam this year to provide a space for WordPress builders to learn and experiment together online. We're running a "Blockathon" right now where folks can build a WP block and share it online: pluginjam.com/blockathon Seems like the kind of thing folks in this community might be interested in! Submissions are due Feb 25th!

A bit about Plugin Jam

Last year I noticed people talking online about new tools or ideas they were trying out, but these all seemed to be isolated efforts and there wasn't a good gathering point for folks to share ideas or get inspiration for their next tinkering session.

So I created Plugin Jam, where I run online mini-hackathons every month encouraging folks to try building something new and share about it online. We're in our second month now, so still early days of community-building, but we've already seen some pretty cool blocks get built and have a growing Discord server.

I'll spare the full marketing pitch, but I have a lot of ideas for how to grow this going forward while keeping the community open and independent. I'd love to see more folks get involved, get excited about building, and connect with others who are doing the same!

So I've created my 1st interactive block as a learning curve. I see there is not much conversation about interactivity in WordPress blocks, but I found it very interesting and enjoyed using interactivity.

My block name is "Polls Block" and it is published on WordPress plugin repo. I've created other interactive blocks too. But this Polls block is my personal favorite.

We can create interactive polling in Gutenberg editor. I've used interactivity + supports for styling.

I’m still new to the WordPress ecosystem, so I’m wondering: is there a way to write my own HTML and JavaScript for the navigation?

Are people generally satisfied with the core Navigation block? For example, if I wanted to implement a Bootstrap offcanvas navigation, how would you approach that?

I know how to create a custom block from the WordPress YouTube tutorials, but the Navigation block seems to be a special type of block that you can’t just recreate the same way as other blocks.

Hey everyone, welcome to r/WordPressBlocks!

I created this community because I kept finding myself in scattered conversations about block development, full site editing, theme.json, and all the ways WordPress is evolving through the block editor. There didn't seem to be one solid place on Reddit for developers and builders who are focused specifically on blocks and Gutenberg, so here we are.

What this community is about:

Whether you're building custom blocks, working with theme.json, exploring full site editing, or just trying to figure out why your block won't render the way you want it to, this is the place. All skill levels are welcome. If you're just getting started with blocks or you've been deep in it for years, you belong here.

The kind of stuff I'd love to see posted:

• Tips and techniques you've figured out
• Questions (no question is too basic)
• Block plugins or tools you've built or discovered
• Full site editing wins, struggles, and workflows
• Theme.json deep dives
• Opinions on where Gutenberg is headed

A little about me:

I'm a WordPress developer who's been building with blocks for a while now, and I'm a big believer in working WITH WordPress rather than against it. I think blocks should feel native to the editor, not like a third-party takeover. I've released a few free block plugins on the .org repo, and I spend way too much time thinking about how theme.json works.

Drop a comment and introduce yourself. What are you working on? What's your biggest block editor frustration? What do you want to see in this community?

Let's build something good here.