Taking Greyd Theme to the WordPress repository

The idea to go to the repo with a theme, when did that start to bubble?

That idea has been in the back of our minds during the early stages of our company. Back then, we considered the possibility of offering our theme or plugin through the WordPress repository, or other channels for that matter.

However, we initially dismissed the idea, preferring to focus on a premium plugin version. One of the reasons for that was that we were concerned about the potential challenges of managing support and other aspects of being in the repository.

But over the years, our perspective evolved. We began to see the value in exploring this avenue, even though initially, it didn’t seem like the right move from a business standpoint. We realized we needed to adapt our existing features into a block theme. That’s when the project truly took off.

As the project progressed, we realized our theme could benefit a wider audience, if it were added to the WordPress repository. By simplifying the theme to its essentials and enhancing it with features like button hover styles and typography options, we made it more user-friendly to anyone who wants to create professional websites without writing code.

What were the challenges faced during this transition?

The main challenge was reconfiguring our classic theme to align with the requirements of Site Editing. We had to reevaluate every aspect, from code structure to functionality. It wasn’t a simple task, but it laid the foundation for a Full Site Editing-ready theme.

A hurdle we had to take was with our customizer extension. The Site Editor’s global styles feature works similarly to what we had done in our Customizer, but to be compatible, we had to rebuild our entire system on top of the new Site Editor features. You see, our extension exposed all settings as CSS variables, similar to how the global styles feature in the Site Editor works. We referenced these variables directly in blocks and the front end. But to achieve Site Editor compatibility, we had to replace this entire system.

Have you considered merging the systems?

The structure of the Site Editor made it difficult to merge our existing system. The required presence of theme.json, which defines default values for all styling options, automatically marked the theme as Site Editor-compatible, making it hard to maintain backward compatibility with our Customizer approach.

We could not maintain our custom styling system alongside the Site Editor’s global styles feature. This meant we had to build a new theme from scratch and map all our Customizer options to the new system. We also had to remove some options that were no longer necessary.

It seems like a lot of work went into this process. Did you have to make any other significant changes?

Absolutely. To get into the WordPress theme repository, we had to follow their guidelines, which made several changes inevitable. We had a unique system where users could edit templates (footer, 404, archive, etc.) directly within the editor. This was heavily intertwined with the theme and our Customizer, making it incompatible with the repository guidelines. It was heavily linked to the theme.

How did you resolve that conflict with the guidelines?

We extracted the editable template functionality from the theme and moved it into a plugin. This ensured it would function independently, allowing for greater compatibility with other themes and aligning with repository guidelines.

So, this move to the repository required a significant restructuring of your theme and extension. Did it impact your overall approach to development?

Getting into the repository forced us to thoroughly evaluate the architecture of our theme and plugin. We had to think more modularly, separating features and ensuring they adhered to best practices.

It was a challenging undertaking, but it resulted in a more robust, compatible, and maintainable codebase. While FSE is still evolving, we’re confident that our new approach sets us up for success in the future of WordPress development.

The process ultimately strengthened Greyd.Suite. While challenging, the journey to the repository forced us to improve our theme’s overall structure and compatibility, making it available to a wider audience and ensuring its future compatibility with WordPress.

Did you seek advice from others in the WordPress community?

Absolutely. We engaged with WordPress experts and core contributors, particularly during events like WordCamp Europe in Athens. Their insights were invaluable in navigating the complexities of Site Editing and understanding the necessary hooks and documentation.

You have ensured that the theme is accessibility-ready. Can you share more about that?

Ensuring accessibility is a priority for us, in general. We meticulously checked every aspect to guarantee compliance with accessibility standards. Which is actually not as daunting as it seems, and it’s crucial for providing an inclusive user experience.

Any final thoughts on this journey?

It’s been a rewarding journey from idea to execution. By embracing new technologies and community feedback, we’ve created a theme that meets the evolving needs of WordPress users. And now, being part of the WordPress repository, we’re excited to reach even more users and empower them to build beautiful websites effortlessly.