Cleora v2: Rebuilding Our WordPress Theme From the Ground Up

A WordPress theme can start simple and become complicated surprisingly quickly.

A few dependencies here, some utility classes there, another JavaScript library, a growing build pipeline, more theme options, and eventually you have a theme that works, but is harder to maintain than it needs to be.

That's what happened with Cleora.

So for version 2.0, we decided not to keep patching the existing theme.

We rebuilt it from the ground up.

Cleora v2 is a complete redesign and codebase rebuild focused on one thing:

A fast, accessible, reading-first WordPress theme without unnecessary complexity.

Cleora is now available for free on the official WordPress theme directory and the source code is available on GitHub.

WordPress.org: https://wordpress.org/themes/cleora/
GitHub: https://github.com/HeliconiaIO/cleora/

What is Cleora?

Cleora is a minimal editorial WordPress theme designed primarily for blogs and long-form content.

The new version is built around a few simple principles:

• Keep the front end small
• Make long-form content comfortable to read
• Use WordPress features instead of reinventing them
• Keep the code understandable
• Make the editor and front end look consistent
• Avoid dependencies where they aren't necessary
• Treat accessibility as part of the design, not an add-on

The result is a theme that feels intentionally restrained.

There isn't a giant settings panel.

There isn't a visual builder.

There isn't a JavaScript framework.

There isn't a CSS framework.

And there isn't a build step required to use the theme.

Why rebuild Cleora?

The original Cleora used technologies that made sense when it was built, including Tailwind CSS and Alpine.js.

Over time, however, we started questioning whether those dependencies were actually helping the theme.

For a relatively small editorial theme, we were carrying:

• Tailwind CSS
• PostCSS
• Autoprefixer
• An npm build pipeline
• Alpine.js

The problem wasn't that these technologies are bad.

They're not.

The problem was that Cleora didn't need all of them.

We wanted to see how far we could simplify the theme without sacrificing the things that matter.

So instead of progressively modifying the old architecture, we started with a clean implementation.

What we removed

One of the interesting parts of rebuilding a project is realizing how much you don't need.

Tailwind CSS

Cleora v2 no longer uses Tailwind CSS.

Instead, the theme uses a single hand-authored stylesheet.

This gives us direct control over the CSS and removes the Tailwind build pipeline from the project.

There is no PostCSS or Autoprefixer pipeline either.

The browser loads the stylesheet directly.

Alpine.js

We also removed Alpine.js.

The theme only needs a small amount of JavaScript for things like:

• Mobile navigation
• Sub-menu toggles
• Search interaction

So instead of shipping a JavaScript framework, Cleora v2 uses approximately 5 KB of vanilla JavaScript.

That's enough for what the theme actually needs.

The npm build pipeline

Because the theme no longer depends on Tailwind, PostCSS, Autoprefixer, or Alpine.js, there is no frontend build pipeline required for the theme.

You can work directly with the source.

That makes the project easier to inspect, modify and maintain.

Design tokens with CSS custom properties

One of the most important architectural changes in v2 is the introduction of a design-token approach.

Colours, typography, spacing and layout are defined through CSS custom properties in style.css.

The same design decisions are represented in theme.json.

The goal is simple:

The WordPress editor and the front end should speak the same visual language.

If a colour or typography decision exists in the theme, it shouldn't need to be recreated separately for the editor.

This also makes the theme easier to customize.

Instead of hunting through hundreds of CSS declarations, the core design values are defined in one place.

Why theme.json matters

theme.json is now an important part of Cleora v2.

The new version uses it for:

• Colour presets
• Typography
• Spacing
• Layout presets
• Editor configuration

This is particularly useful for maintaining parity between the block editor and the website.

A common frustration with WordPress themes is editing content in an environment that looks noticeably different from the published website.

Cleora v2 tries to reduce that gap.

No web fonts

We also removed the Google Fonts request.

Instead, Cleora uses a system font stack.

The interface uses a sans-serif system stack, while article content uses a serif stack designed for comfortable reading.

There is a practical reason for this decision beyond aesthetics.

Web fonts introduce additional network requests and can affect how text renders during the initial page load.

With system fonts, the browser can render the typography immediately using fonts already available on the user's device.

For an editorial theme, that felt like the better trade-off.

Reading comes first

The single-post template received one of the biggest design changes.

The default experience is now intentionally focused on the article.

Single posts and pages are full width by default.

The content has a generous reading measure, with support for normal, wide and full-width blocks.

The idea is to remove visual distractions when someone is reading a long article.

A sidebar can still be enabled when needed, but it isn't forced on every single post.

You can configure this from:

Appearance → Customize → Cleora Options → Sidebar

A better blog index

The blog homepage was also redesigned.

Instead of treating every post equally, Cleora v2 introduces a featured lead article followed by a post grid.

This creates a clearer editorial hierarchy.

The first article gets more visual emphasis, while the remaining posts are presented in a structured grid.

It's a small change, but it makes a content-heavy homepage much easier to scan.

Related posts and post navigation

Long-form reading shouldn't end abruptly.

The new single-post template includes:

• Author biography
• Related posts
• Previous/next post navigation

These elements provide natural paths to continue exploring the site after finishing an article.

The objective isn't to add more UI.

It's to make the content relationship between posts more useful.

Search without a JavaScript framework

Cleora v2 also introduces a header search panel.

The interaction is implemented with vanilla JavaScript and includes keyboard support.

Again, the principle is simple:

If a small interaction can be implemented with a small amount of native JavaScript, we don't need to introduce an entire framework to do it.

Accessibility is part of the implementation

Accessibility wasn't treated as a checklist at the end of development.

It's part of the theme structure.

Cleora v2 includes:

• Skip link
• Visible focus states
• Keyboard-operable navigation
• Keyboard-operable sub-menus
• Screen-reader labels
• Semantic landmarks
• Reduced-motion support
• Accessibility-ready theme support

Navigation and menus are particularly important here.

A menu that looks good with a mouse isn't necessarily accessible.

Keyboard users need to be able to navigate it too.

That's why the new navigation JavaScript handles accessible menu and sub-menu interactions rather than relying purely on visual behavior.

Semantic markup and BEM-style classes

Every template was rewritten during the v2 rebuild.

The new implementation uses semantic markup and more predictable class names.

For example, instead of depending on framework-generated utility classes throughout the markup, the theme uses semantic classes such as:

post-card
entry-content
site-header

This makes the relationship between the markup and the styling easier to understand.

It also makes the theme more approachable for developers who want to create a child theme or modify the templates directly.

Block editor support

Cleora v2 was also rebuilt with the WordPress block editor in mind.

The theme includes styling for common core blocks and introduces several reusable block patterns.

There are also three block patterns and a Card block style included with the theme.

The intention isn't to create a huge collection of proprietary blocks.

Instead, the theme extends the WordPress editor while staying close to the native block experience.

The small details matter

Some of the changes in v2 aren't immediately visible.

For example, excerpt handling was changed so that presentational markup is no longer injected into get_the_excerpt().

The comment list now uses WordPress's HTML5 markup.

The pagination, search results and 404 page were redesigned.

The old clean_url filter hack used for deferring scripts was removed in favor of WordPress's script loading strategy API.

These changes aren't necessarily things a visitor will notice.

But they're important when you're trying to maintain a clean WordPress codebase.

Upgrading from Cleora 1.x

Because v2 is a ground-up rebuild, we wanted existing users to be able to upgrade without losing their content.

Existing:

• Posts
• Pages
• Menus
• Widgets
• Featured images

continue to work.

There are, however, some intentional changes.

Tailwind CSS and Alpine.js have been removed, so child themes that relied on Tailwind utility classes from the previous implementation will need to be updated.

The old cleora_link_color setting is migrated as the default for the new Accent Colour control.

The previous widget header colour setting is no longer used because widget headings now follow the theme's typography system.

And single posts and pages are now full width by default.

If you prefer the previous sidebar behaviour, it can be restored through the Customizer.

What we learned from the rebuild

The biggest lesson from Cleora v2 wasn't about WordPress.

It was about knowing when to simplify.

It's easy to assume that a more sophisticated stack automatically produces a better product.

Sometimes it does.

Sometimes it just produces a more sophisticated stack.

For Cleora, we found that removing dependencies gave us more control.

Removing the CSS framework made the stylesheet easier to reason about.

Removing the JavaScript framework made the frontend smaller.

Removing web fonts removed an external font request.

Removing the build pipeline made the project easier to work with.

And rebuilding the templates gave us the opportunity to rethink the actual reading experience rather than simply reproducing the old design.

The numbers aren't the whole story

It would be easy to turn this into a performance article and focus only on file sizes.

But that's not really the point.

The important question isn't:

"How many kilobytes did we remove?"

It's:

"How much complexity does the theme actually need?"

Cleora v2 has a deliberately small frontend because the theme itself has a relatively small job.

It needs to present content beautifully, provide the expected WordPress functionality, remain accessible, and give developers a clean foundation to build on.

That's it.

Built for WordPress, not around WordPress

This is probably the best way to describe the philosophy behind Cleora v2.

We didn't want to build a separate application that happens to run inside WordPress.

We wanted to build a WordPress theme that uses WordPress properly.

That means working with:

• theme.json
• The block editor
• WordPress template hierarchy
• WordPress menus
• WordPress widgets
• WordPress Customizer
• WordPress script APIs
• Native WordPress markup

The less we have to fight the platform, the simpler the theme becomes.

Cleora is open source

Cleora is released under the GPLv2 or later license.

The complete source code is available on GitHub.

If you're a WordPress developer, you can inspect the implementation, fork the project, modify it for your own needs, or contribute improvements.

GitHub:
https://github.com/HeliconiaIO/cleora/

If you're a WordPress user, you can install it directly from the official theme directory.

WordPress.org:
https://wordpress.org/themes/cleora/

What's next?

Version 2.0 gives Cleora a completely new foundation.

Now the interesting part begins.

We'll continue improving the theme based on real-world usage, feedback and the direction of WordPress itself.

The goal isn't to turn Cleora into a theme with hundreds of features.

If anything, we want to keep going in the opposite direction.

More useful. Less unnecessary.

A better reading experience.

A cleaner codebase.

A smaller frontend.

And a WordPress theme developers can actually understand.

That's Cleora v2.

---

Cleora is built and maintained by Heliconia Solutions and is available for free through the WordPress.org theme directory.