Allowing Theme based Page-builder in the repository

[Dentalicious]

What problem does this address?

Currently, WordPress enforces a strict separation between themes and plugins, where themes are meant to handle design and layout, while functionality, especially in relation to content creation and customization, is delegated to plugins like page builders. This separation limits the flexibility and ease of use for developers and end-users who wish to have a streamlined solution where both design and content customization are integrated into one powerful tool - A Theme based Builder.

In practice, this practice of allowing blank themes, leads to the unnecessary complexity of having to install both a theme and a page builder. For example, in a recent forum discussion at Cwicly,

https://discourse.cwicly.com/t/the-cwicly-themer-and-the-cwicly-theme/6028

this issue was debated, and developers/users using Cwicly (or similar builders) must install a blank theme alongside the builder, confusing users with redundant layers of customization and setup. This also introduces potential compatibility issues between themes and builders, adding maintenance overhead for users and developers alike. Meanwhile, solutions like Bricks demonstrate the benefits of integrating theme and builder functionalities into one, achieving better performance and simplicity. However, these platforms are excluded from the WordPress repository due to existing restrictions, limiting innovation and user choice.

What is your proposed solution?

Historical context: A Look Back: When Page Builders Took Over

Prior to 2016-2017, WordPress users were all about themes. Themes like Astra, GeneratePress, Genesis, Avada, Enfold, etc., were everywhere because that was how you made a website look good without touching code. But themes could only do so much. So, along came page builders like Elementor, Divi, and Beaver Builder, letting people create custom layouts and designs without needing a developer.

Initially, these page builders were just tools you used with a theme. But there was a problem: sometimes they didn’t play nice with certain themes, which meant endless tweaking and frustrating compatibility issues.

Then Elementor had a lightbulb moment. Around 2017, they introduced their “Hello” theme, which was basically a blank canvas that let the page builder do all the work. The theme became a mere sidekick, while the builder did the heavy lifting.

From there, it became clear that themes were kind of… extra, redundant. You didn’t really need them if the page builder was doing everything.

What Bricks Did Right: Fast forward to Bricks Builder, another player that was paying attention to what Elementor did. Bricks saw that having both a theme and a page builder was adding unnecessary complexity. They cut out the middleman and went straight for a theme-based builder approach. In doing so, Bricks became a leaner and faster solution, with everything under one roof. No theme-builder conflicts, no extra steps—just simplicity.

Why other page builders Should Follow Suit!

Right now, page builders like Cwicly and others are still playing the same game as Elementor did in its early days—using a blank theme with the builder as a separate plugin. But honestly, if you’re already using a blank theme, why even bother with the separation? New users especially look at this and think, “Wait, I have to install a theme AND a page builder? Which configuration supersede what? This setup is ridiculous.” And they’re right. It feels unnecessary, and it is.

The proposal is to allow themes in the WordPress repository to integrate the full power of page builders, eliminating the need for separate plugins and blank themes. By relaxing the strict design-versus-functionality separation, WordPress can adapt to modern development trends, which favor all-in-one solutions that provide ease of use, performance, and consistency.

This flexibility will:

1) Simplify the user experience by reducing unnecessary steps in configuring a theme and page builder separately. 2) Foster innovation by enabling developers to provide integrated solutions that offer customization options without sacrificing performance or usability. 3) Address compatibility issues that arise when page builders must work alongside themes developed by third parties. 4) Allow for faster, leaner websites, as users can bypass the bloat that occurs when both a theme and page builder are used simultaneously.

Bricks has already demonstrated the value of an integrated theme-builder model, and while they operate outside the WordPress repository, developers like Cwicly who wish to remain within the repository must sacrifice user experience and innovation to conform to the current rules.

By enabling this flexibility, of allowing theme based page-builders, WordPress will stay competitive with other platforms such as Webflow, Wix, and proprietary solutions like Bricks.

[carolinan]

Thank you for brining this up.

But it is unclear how this relates to Gutenberg: Please remember that the requirements for the WordPress.org theme directory is completely separate from this plugin and separate from the block editor. Perhaps this is more relevant to bring up in a meeting with the WordPress project lead, the Meta and Themes teams.

You bring up several points but are not addressing the reason for why this separation exist: The user's website breaks when the plugin functionality is removed: when the theme with the extra functionality is switched.

I also think you may be missing an opportunity to discuss if separate themes are needed. Why isn't the "blank" theme part of core, so that the "page builders" don't need to build themes?

• What is it that you actually need from Gutenberg?
• What are the actionable items for Gutenberg?

[carolinan]

I would also question why a page builder would need a custom theme and not work with any theme. It seems incredibly limiting and something that would inherently limit the number of customers the plugin could have.

[Dentalicious]

Thank you for your response.

You’re correct that this request isn't directly related to Gutenberg, but I wasn’t sure where to place it. If you could direct me to the appropriate forum or team—whether it's with the WordPress project lead, Meta, or Themes teams—I’ll gladly repost my request there.

Regarding your point about a user's website breaking when a theme or page builder is switched, I agree that this is a logical consequence of using any system that tightly couples design and functionality. However, my request is focused on a slightly different issue.

My concern is the current limitation placed on third-party themes in the WordPress repository. Specifically, I am requesting for flexibility to allow themes that offer the same depth of functionality as a page builder, to be allowed in the repository, thereby eliminating the need for users to install both a theme and a separate page builder plugin.

In my original post, I provided some historical context about why themes and page builders have been separate entities. This separation, while understandable from a legacy standpoint, has now become an unnecessary and burdensome step for users, and If WordPress is committed to evolving with user needs, it seems worth considering whether this separation is still beneficial.

Again, I’d appreciate any guidance on where to properly raise this issue. Thank you!

[carolinan]

All team meetings are listed in the public calendar: https://make.wordpress.org/meetings/

[Dentalicious]

Thanks for the link for the team meetings. I am constrained for time to sit through a team meeting on unrelated topics outside of my post request. Is there a link to a forum where I can post this request for the consideration of appropriate technical leads if this place isn't appropriate for it? Thanks again, Cheers!

[carolinan]

Meeting agendas are posted on the team blogs before the meetings. You can comment on the agenda to have your discussion point added, but it will be very difficult for the attendees to discuss your idea without you present, since you are the person who has all the context and the request.

There is a WordPress Slack where most teams have their own channel. The channel names are the names of the teams. https://make.wordpress.org/chat/

[carolinan]

Theme developers are already able to request exceptions from the theme directory requirements. But such a request should be communicated very clearly in advance to not get blocked by the theme uploader scripts.

[Dentalicious]

Thanks for the information that theme developers can apply for an exception, much appreciated.

I'll pass along the information to the Cwicly developers, and if they find merit in the approach of a theme based page-builder, they have dedicated resources to follow up with the Wordpress team.

Cheers.