Building Tailpress: Custom WordPress Theme with Timber, Tailwind, Gutenberg, and AI

When I started building Tailpress, I did not want to create just another WordPress starter theme. I wanted a theme foundation that felt modern for development, flexible for content editing, and structured enough to grow into real production projects.

Tailpress is the result. It is a custom WordPress theme built with Timber/Twig, Vite, Tailwind CSS v4, Alpine.js, GSAP, Swiper, and a set of custom Gutenberg blocks. My goal was to make WordPress theme development faster, cleaner, and more reusable without losing the editing experience that makes WordPress valuable.

Project Snapshot

• Project type: Custom WordPress theme
• Focus: Modern theme architecture, editor tooling, reusable templates, and dynamic content blocks
• Main stack: WordPress, PHP 8.1+, Timber 2, Twig, Vite 7, Tailwind CSS 4, Alpine.js, GSAP, Swiper, Redux Framework
• Standout features: custom Gutenberg blocks, Tailwind compilation in the editor, AJAX loop builder, reusable template generator, header/footer pattern system, and AI-assisted markup editing

Why I Built It

I built Tailpress to solve a few problems I often see in WordPress theme development:

• theme files become hard to maintain when PHP, markup, and styling are mixed together
• Gutenberg is powerful, but custom layout building can still feel limiting
• utility-first CSS is fast to work with, but it needs a workflow that fits both the editor and the frontend
• reusable templates often end up locked inside page builders instead of staying portable as theme code

With Tailpress, I wanted a workflow where I could use modern frontend tools, keep templates clean, and still give editors a flexible experience inside WordPress.

The Architecture

One of the main decisions in this project was building the theme around Timber and Twig instead of writing everything directly in PHP templates.

That gave me a cleaner separation between logic and presentation. Main templates live in Twig views, block templates can also use Twig, and the theme context is extended with shared data such as menus, helper query functions, loop pagination data, and header/footer layout selections.

This makes the codebase easier to read and easier to scale. Instead of stuffing logic into template files, I can keep the rendering layer focused on markup while using PHP classes to manage theme behavior.

What I Built

1. Custom Gutenberg blocks for layout building

The biggest part of Tailpress is the custom block system. I did not want to rely only on default core blocks, so I built a block workflow that is more code-driven and better suited for custom frontend work.

Tailwind HTML block

This block lets me write custom HTML with Tailwind utility classes directly inside Gutenberg. It supports:

• optional dynamic rendering with Twig
• a fullscreen markup editor
• optional footer JavaScript
• live Tailwind CSS compilation from the current block content
• conversion into a semantic wrapper block when needed

This is useful when I want full layout freedom without leaving the block editor.

HTML Tag block

I also created a wrapper-style block for semantic structure. It allows custom tags and custom attribute pairs, which makes it easier to build clean nested markup while keeping the editor experience flexible.

Loop Builder block

This block is designed for dynamic content. It can query posts by post type, filter by taxonomy terms or manual IDs, accept raw meta_query JSON, and render each result using Twig-based item templates.

It also supports multiple pagination patterns, including:

• numbered pagination
• load more interactions
• previous and next navigation

On the frontend, pagination can continue through AJAX, so the block works as more than a static post list.

2. Tailwind compilation inside the editor

One challenge with utility-first CSS in WordPress is keeping the editor preview and frontend output aligned. To solve that, I built an editor-side Tailwind compilation workflow.

The theme extracts class usage from supported blocks, compiles scoped CSS, and stores the result as block attributes. On save, the theme also generates page-level cache files in the uploads directory. It merges compiled block CSS with additional editor CSS, removes duplicate rules, and writes dedicated stylesheets for pages and reusable patterns.

That means I can keep the flexibility of Tailwind without manually maintaining large custom CSS files for every page variation.

3. Smart asset loading with Vite

Tailpress uses Vite for both development and production.

In development, assets are served from the Vite dev server. In production, the theme reads from the generated manifest and loads built assets automatically. I also made the asset loader detect block-specific frontend scripts, so those scripts are only enqueued when the matching block exists on the current page.

For example, the Loop Builder runtime only loads when the Loop Builder block is actually used. That helps keep the frontend cleaner and avoids loading extra JavaScript everywhere.

The build pipeline also supports packaging the theme for distribution, including a production zip output.

4. Reusable header, footer, and template systems

I wanted the theme to support reusable layouts without depending on a full visual page builder, so I created two template-related systems.

First, the theme supports global header and footer layouts using WordPress block patterns, with optional per-page overrides.

Second, I built a custom global_template post type that works like a lightweight template builder. From the admin area, I can:

• create template entries
• preview them against singular or archive contexts
• generate PHP template files from predefined generators
• export generated files
• download them as a child theme package

This gives me a practical bridge between block-based editing and real theme files.

5. AI-assisted markup editing

One of the most interesting features in Tailpress is the AI editing workflow built into the fullscreen block editor.

From inside Gutenberg, I can send the current HTML, optional JavaScript, a text instruction, and even a reference image to a remote AI endpoint. The theme settings allow provider selection, API key storage, model selection, and optional post type context so the AI can respond with markup that fits the actual WordPress structure.

I designed this feature to help with real editing tasks, not just experiments. The goal is to speed up layout iteration while still keeping the final result inside the theme's own block structure, Twig syntax, and frontend conventions.

6. Frontend interaction support

Tailpress also includes built-in runtime support for common interactive patterns.

The theme exposes Swiper and GSAP utilities to both the frontend and the editor preview. That means sliders, animations, and dynamic interactions can be tested in a workflow that stays much closer to the final result instead of being limited to a static editor preview.

I also kept Alpine.js in the stack for lightweight interactivity directly in markup when needed.

7. Theme cleanup and quality-of-life improvements

Beyond the larger systems, I added a number of smaller improvements to make the theme feel more production-ready:

• WordPress frontend cleanup such as removing emoji scripts, generator tags, and global styles that are not needed
• a frontend admin bar toggle for administrator users
• centralized theme options for general settings, social links, Google Tag Manager, Google Maps, header/footer layouts, and AI configuration
• editor-side support so custom styles and interactive behavior can preview more accurately

These details are small individually, but together they make the development and editing experience much smoother.

What Makes This Project Valuable

Tailpress matters to me because it is not only a theme design project. It is a systems project.

It shows that I can:

• design a custom WordPress theme architecture
• build dynamic Gutenberg blocks instead of only styling existing ones
• connect PHP, Twig, JavaScript, asset tooling, and admin UX into one product
• create reusable template workflows that stay portable as theme code
• experiment with AI-assisted editing in a practical and structured way

Screenshot:

Technical Challenges I Solved

Several parts of this project were especially meaningful to solve:

• synchronizing Tailwind-generated styles between the editor and the frontend
• rendering dynamic Twig content safely inside custom blocks
• making loop pagination work on both initial render and AJAX requests
• creating reusable template generation without turning the theme into a locked page builder
• adding AI-assisted editing while preserving structured HTML, Twig, and optional JavaScript output

These challenges pushed the project beyond a normal starter theme and into something much more custom.

Final Thoughts

Tailpress started as a base theme idea, but it evolved into a custom WordPress development toolkit. It gives me a faster way to build themes, a more flexible Gutenberg workflow, and a cleaner bridge between modern frontend tooling and WordPress content management.

If I continue expanding this project, the next areas I would like to improve are more reusable design presets, stronger pattern libraries, and even deeper AI-assisted layout workflows.

For now, Tailpress stands as one of my most complete WordPress projects because it brings together theme engineering, editor experience, dynamic content, frontend tooling, and experimentation in a single codebase.