The Cwicly Themer and the Cwicly Theme

General
21

Let’s take a step back and look at the big picture before zooming into the specific question. This helps provide context for where Cwicly fits into the broader landscape, and it may guide developers in making strategic decisions.

The Competitive Hierarchy:

• Fortune 500: Adobe Experience Manager (AEM), Sitecore, SAP Commerce Cloud, Oracle Content Management, and custom solutions, etc.

• Mid-to-Large Corporations: Salesforce CMS, HubSpot CMS, and WordPress VIP, etc.

• Small-to-Medium Enterprises: WordPress, Webflow, and others.

• Small Businesses: Wix, Squarespace, and Shopify, etc.

Within WordPress, we see key competitors like Elementor, Divi, Beaver Builder, WPBakery, Bricks, Breakdance, and Builderius.

Industry Trend:

The trend in this space is consolidation. For example:

• Squarespace acquired Google Domains, positioning itself as an all-in-one solution—from domains to CMS to hosting to builder.

• Webflow offers a similar all-in-one experience.

• Elementor has followed this pattern within WordPress, expanding from a page builder to offering hosting, a theme, and other services like image optimization and email marketing.

Bricks as a Benchmark:

Bricks has consolidated in the same way, offering a theme-based builder with features like native form building, sort and filter, reducing reliance on third-party plugins.

Cwicly’s Strategic Opportunity and challenges:

Given this competitive landscape, my suggestion was that Cwicly should similarly aspire toward consolidation over the coming years. If Cwicly can create a seamless ecosystem, it can offer users all their builder needs in-house without depending on third-party plugins or themes, much like Elementor and Bricks.

Flexibility vs. Stability:

Some users in this thread mention the need for flexibility, preferring a plugin-based approach. However, what remains unclear is why anyone would prefer this flexibility when the Cwicly builder or a Cwicly theme-based builder can handle all site-building needs.

Take Elementor as an example:
Elementor recommends using its own blank Hello theme, and while technically you can use Elementor with other themes, in practice, most users stick with Hello for stability and optimal performance. The same is true for Cwicly.
Then why keep the redundancy?

Regarding AI, I’d argue that a streamlined, all-in-one system would be easier to integrate with AI advancements. A lean and unified theme-based builder setup could make more sense in an AI-driven future, as it reduces fragmentation.

At the end of the day, it’s about the trade-off between flexibility and stability—both are valid approaches, and it depends on what you value more for your workflow.

Though my may be a minority view based on the responses here, I maintain that a theme-based builder offers a sustainable, future-proof approach.
However, I respect that others may see it differently for reasons beyond my comprehension.​​​​​​​​​​​​​​​​

22

The difference is, Cwicly is not the same as Elementor or Bricks. Yes it can be used as a page builder and can be considered a site builder, but it has distinct differences.

Part of the flexibility comes because Cwicly integrates with Gutenberg. It enables users to work with other Gutenberg blocks, custom 3rd party blocks, use additional themes. Cwicly is not “perfect” and there are ways it can be decoupled further, but most of these have feature requests and some are planned or in the roadmap already.

I understand the desire for businesses to “consolidate”, or broaden their offering if it makes good business sense, at the same time it’s not possible to offer all things to all people and some of the most successful business models for tech products are when something is provided that fulfils a specific purpose and does it really well.

The fact that so many people have given clear feedback that after using Cwicly for any significant amount of time, they found it hard to use other products because they miss key features provided by Cwicly suggests Cwicly is successfully fulfilling its purpose.

With improvements for new users such as better access to initial templates and faster onboarding it has the potential to become more and more mainstream.

2 Likes
23

I agree with most of what you say, especially regarding the flexibility and integration with Gutenberg that Cwicly provides.
However, the part I fail to understand is why anyone would want to use Cwicly with any other theme besides the blank Cwicly theme.

Cwicly already delivers a powerful and seamless builder experience when paired with its own blank theme. Why introduce potential conflicts and added complexity by using third-party themes? It seems counterproductive when Cwicly is more than capable of handling all or most requirements to build a website.

And to be clear, with my proposal, nothing about your current experience with Cwicly would change if it transitioned into a theme-based builder. It would simply streamline the process by reducing reliance on external themes or plugins. So, I don’t quite understand the resistance to this transition.

24

This is the power of flexibility, you don’t necessarily need to have an immediate reason to want to do something now, but you may in the future.

Here are just two easy examples to answer your question:

  1. Cwicly are planning on sharing templates to improve onboarding - at some point they may decide to bundle these into one or more customised themes.
  2. One or more third-party companies may release Cwicly specific themes either for free or for sale.

Cwicly provides all of the tools we may need to build sites without ever needing a different theme, that doesn’t mean that themes don’t have inherent value and if you combine them, it may create a multitude of advantages.

The point is, right now, the door is open for these opportunities and so can see why many people are asking: “why not just keep it open?”

1 Like
25

Cwicly-specific themes by third parties—but why create crucial dependencies on third parties for such an essential part of the infrastructure such as a theme?

These third parties can still contribute significant value by providing or selling templates and sections (hero sections, testimonials, navigation mega menus, headers, footers, etc.), similar to what we see with Bricks and Elementor.
There are countless external template libraries, both free and paid, that users can tap into without adding complexity to the builder’s core structure.

As David mentioned in his original post, users must be told unapologetically that when using the Cwicly themer, they should stick to the Cwicly theme.
My proposal goes a step further—however, transitioning to a theme-based builder would not change the core experience of Cwicly.
It would only serve to enhance consistency and stability, simplify the user journey, and reduce potential conflicts without sacrificing any of the features users currently enjoy.

26

And how are these to be delivered and packaged?

Using HTML to Blocks we can paste in Tailwind, but that limits the control we have significantly.

Using the Cwicly design library may be an option if it was opened to community contributions but that also narrowly funnels the delivery channel and requires the Cwicly team to do additional work and maintenance.

My point is that having alternative themes can be an easy way to package templates because that is literally what they are designed for and there is no additional work required to make them compatible with either WordPress or Cwicly. These can of course be used as child themes.

We always use child themes as best practice and for certain projects those themes may contain certain codes or assets required to integrate with other aspects of the site or external applications, etc.

Having the Cwlcly barebones theme as the default is a good thing and does eliminate any possibility of third-party conflicts as you say, which is what we do as a starting point. At the same time, putting a restriction to never use any other themes or child themes would be unnecessarily limiting and would prevent valid and real-world use cases.

As long as all of the features are allowed and accepted by the WordPress review team of course.

1 Like
27

Bricks also supports child themes, so being a theme-based builder doesn’t mean you lose the ability to create child themes or customize the builder to suit your needs. You still have full flexibility to tailor it to any project.

Regarding template libraries, while there are countless options, let me highlight a specific example: many of these libraries offer templates built to be compatible with the CSS frameworks commonly used with Bricks, such as Core or ACSS. Importing these templates is seamless, enhancing the user experience.

If Cwicly gains popularity in the repo, it’s likely that third-party developers will follow suit, creating similar template libraries with Tailwind compatibility to cater to Cwicly users, just as they do for other builders.

In essence, you don’t lose any flexibility with a theme-based builder. In fact, you gain stability, reliability, and reduce potential conflicts and external dependencies while still allowing for third-party innovations where they matter most—templates and design elements.

IMG_0960
IMG_09601170×2204 179 KB

IMG_0959
IMG_09591170×1986 115 KB

28

We can agree on that part:

I am all for third party integrations of popular libraries and tools as this only improves what can be achieved. That said, unless there is a default native integration then it is not something that can be relied upon at this stage.

The most important question to ask is, how will Cwicly import/export templates?

Packaged in themes is one option, there are others and it remains to be seen whether @Louis has different plans that we don’t even know about yet.

If there is a simple and easy way to package and share templates, then the conversation changes immediately.

29

It’s actually much simpler than you think.
With Bricks, for instance, you just create an account with the template library of your choice, link that template library login and password in the backend of Bricks, and voila—those templates are available right within the editor.
In fact, you can link multiple template libraries if you have accounts with more than one.
It’s incredibly seamless and efficient, making the entire process a breeze.

This same kind of functionality can be expected with Cwicly as it grows. If Cwicly gains popularity, third-party developers could offer similar template libraries, including Tailwind-compatible designs, tailored specifically for Cwicly users.

This way, you keep all the flexibility and customization options, while also gaining the stability and streamlined user experience of a theme-based builder.

30

I do know how template libraries work :smile:

As I said:

There has to be a native included starting point. That may be a built-in integration with a third party library, it may be more WordPress oriented or it may be something completely proprietary that @Louis proposes.

1 Like
31

Cwicly is not Bricks. I don’t want Cwicly to become Bricks. And I really hope it doesn’t.

I want to build my own themes with templates ready using Cwicly if I want to.

I want to be able to use a specialized theme in a project, but still benefit from the flexibility and control Cwicly gives me to build specific pages.

I won’t comment on the “AI enhanced” text about strategies and financial burdens… Saying pretty words doesn’t make the offer more attractive to me.

Cwicly works best as an extension of Gutenberg. It gives me the flexibility I expect from an advanced visual builder. I don’t think switching to a theme is beneficial. I think it limits our options.

There are plenty of cases in which having a separate theme would be advantageous. For everything else, installing the Cwicly theme is a breeze with the on-boarding wizard.

1 Like
32

I find the framing that “Cwicly is not Bricks” a bit strange.
If that’s the logic, then what is it—Elementor?

Ultimately, there are two primary models: plugin-based page builders and theme-based builders.
Cwicly inevitably falls into one of those categories, and if you look at the history, Elementor brought the blank theme model with its “Hello” theme into mainstream.

The logic is consistent across both approaches—self-sufficiency without relying on third-party themes that might introduce limitations or unnecessary dependencies.

This debate on “flexibility to use other themes” seems to have come full circle. Why?

Elementor, for example, recommends its blank theme for a good reason—to avoid the complexities and potential conflicts that come with using third-party themes.
Cwicly follows a similar path, and anyone has yet to illustrate a compelling argument explaining why introducing third-party themes would actually benefit users.

Now, about the idea that “a separate theme is advantageous”—could you or anyone provide a concrete example of when using the Cwicly blank theme or the Hello Blank theme is actually a disadvantage?

From my perspective, the fewer moving parts you introduce, the more streamlined, stable, and reliable the platform becomes.
Third-party themes bring more potential for conflicts and maintenance headaches.

As for the “pretty words for AI” comment, my argument is rooted in logic.
When you minimize dependencies on external, unpredictable elements, you’re investing in long-term stability and reducing the risk of compatibility issues. That’s not just an aesthetic argument—it’s a practical, technical one.

So, the key question remains:
Why create dependencies on third-party themes when Cwicly already provides everything necessary?

If you or anyone can present a use case that benefits the vast majority of users—say, 90%—it would be useful to see.

Otherwise, this just feels like a demand for “choice” where the practical use cases don’t really exist for a vast majority of users.

33

I agree with all the lads @zeinnicholas, @StrangeTech, @AnthonyKeller and @sunny. The versatility of Cwicly as a plugin leaves us with more options. Cwicly isn’t all encompassing that way. Say if I want to use Blocksy (which is a theme) I can do so in tandem with Cwicly. I prefer to create my own themes/child themes from a blueprint of mine.

You have your opinion and you are entitled to that. But, you are indeed in the minority here.

This comparison with Elementor and Bricks and ‘reducing reliance on third-party plugins’ I also don’t agree with. My fundamental issue with Bricks besides being a theme, is the necessity for additional plugins to achieve the same level of functionality as Cwicly.

I feel there are far more pressing matters to focus on.

34

I also don’t want to see Cwicly require you to use a particular theme. Changing themes on a wordpress site usually means that all your pages break, all at once. Then you go on a frantic Easter egg hunt finding and fixing all the breakage. If, in order to try out Cwicly, you have to change themes, you are very likely to say “not worth the risk”, no matter how much gain there is. This would lock Cwicly out of many established web page cases.

35

Fair enough.

If you want the flexibility of using Blocksy with Cwicly, I get it—though I don’t entirely understand the reasoning behind it.

That flexibility is there for now, but if Cwicly transitions to a theme-based builder, that option would disappear.

I saw an opportunity for improvement and attracting more users, so I shared feedback on how Cwicly could streamline and simplify things.

I myself acknowledged that I’m in the minority here, for reasons beyond my comprehension.
No biggie.

1 Like
36

You are grand @Hank :slightly_smiling_face: you have made some valid points and you have handled the criticism well.

1 Like
37

The point is, Cwicly isn’t either of them, it is Cwicly, trying to fit it into an existing bracket is effectively missing the point of how much potential it has.

Good products don’t just follow what has already been done, they innovate and lead the way.

A recommendation is not the same as a mandate or requirement, the emphasis is not on what is the default or recommended workflow, it’s about what else can you do when the normal flow is not sufficient. Cwicly has been a Godsend in that regard because many times one approach didn’t work and there were 2-3 other options as a fallback that Cwicly provided. I have never had that experience with any other WordPress plugin.

Agreed, with the caveat that this has to be balanced with features and functionality. The fewest moving parts are none at all and I’m sure we can also agree that Cwicly as an empty plugin wouldn’t do any of us much good. :smile:

We definitely agree on this point, which is why a default native implementation is so important as discussed.

I don’t think anyone is suggesting creating a dependency on third-party themes, simply that allowing them to work with Cwicly is a useful thing. Cwicly definitely provides more than enough power that in most circumstances a third party theme is not required. The only advantage a starter theme gives at the moment is a faster starting point for templates.

This is worthy of a larger discussion I don’t have time for right now, I will just say that Firefox used to cater to developers (who are not the majority of users). Then it didn’t.

Cwicly has significant features that 90% of users may never use, however, they are some of the most compelling reasons to use it for the other 10%.

2 Likes
38

We are a use case where the ability to switch out the theme was essential. We started using Cwicly on top of Kadence, as we needed to do a lot of verification before we decided to move our whole site over. So we installed Cwicly, played around with it, spend weeks porting pages over, did more CSS, then finally switched out the Kadence theme, and spent the remaining time fixing everything that was broken. We never would have been able to invest all that time and tears if we couldn’t look before we leapt.

4 Likes
39

I don’t want to drag this, but just to clarify and emphasise on best practices for live sites wanting to overhaul/migrate, It’s generally not advisable to test significant site changes like theme switching directly on a live site, especially for major overhauls.

It worked out for you with sweat and tears, but generally, doing these kinds of updates on a staging site or local installation provides a safer environment to ensure nothing breaks and all functionality works smoothly before pushing the changes live.

While your experience of gradually transitioning from Kadence to Cwicly worked out, it introduces unnecessary risks by making real-time changes that could affect the user experience or cause downtime.

By following best practices, such as using staging or local environments, you minimize disruptions and can test freely without worry.

In any case, I reckon we agree that it’s always better to look before you leap, just in a more controlled and secure space.

In other words, this isn’t really a use case.

Zooming out and looking at the larger picture, customer ignorance of best practices shouldn’t shape how a product is developed.

There was even another guy in a recent livestream who said he uses Cwicly on top of Breakdance.
But in cases like this, if something goes wrong, who takes responsibility and does the debugging—Breakdance support or Cwicly support?

With Cwicly now free and looking to gain traction in the repo, there’s a risk of a lot of DIY users setting it up haphazardly, unaware of best practices.
When things break, who will do the debugging and who will they turn to for help?
Cwicly will inevitably get the blame, even though the core problem stems from incorrect usage.

This opens up a can of worms—or Pandora’s box—however you prefer to put it.

Thus, the environment has to be controlled to prevent these kinds of issues from surfacing in the first place.
A theme-based builder offers that stability and structure—it’s a genuine innovation, providing a consistent and reliable foundation.
On the other hand, a plugin-based builder is more like the Wild West—open but inherently chaotic and prone to compatibility issues.

You have to draw a line in the sand.
Take Elementor, for example—they operate on a subscription model, while Bricks offers a lifetime deal (LTD).
When potential customers demand a lifetime deal from Elementor, they don’t cave.
Instead, Elementor responds by saying, “we’re not in the LTD business,” and they’re willing to lose customers to other page builders offering such deals because they prioritize long-term growth and viability.

Unless Cwicly draws a similar line in the sand, and is prepared to lose customers like Elementor does with LTD demands, users will always lean towards a Wild West model that prioritizes short-term convenience and choice over long-term stability.

Cwicly needs to define what success looks like:

  • Is it about stacking Cwicly on top of other builders like Breakdance? Is that success?

  • Or using Cwicly with thousands of random themes, leading to potential inconsistencies? Is that success?

  • or Perhaps it means using Cwicly to create a few landing pages on a site built on a completely different system. Can that be labeled as success?

Or does success mean DIYers, freelancers, and agencies confidently building entire new sites or rebuilding existing ones on Cwicly, creating a streamlined and reliable system?

Without defining success, Cwicly risks leaning into a chaotic, unpredictable model, which could lead to more issues and support demands.

But we’ve had this discussion already, and I know I’m in the minority on this, so I’ll leave it at that.

1 Like
40

I don’t think choice and long-term stability are mutually exclusive, in fact as long as the features that provide the choice are themselves stable and well maintained, I think choice (i.e. the flexibility to be able to adapt) can be a pivotal factor in providing long-term stability.

The only contention I have with this statement is: who defines what best practices mean in the context of development?

Taking for example certain CSS libraries, one person could argue that Tailwind is best practice for teams, another person could argue that global classes are the only way to go.

Does that make one person right and the other person not? Does it make one ignorant and the other wise? Who is the arbiter and what gives them authority over everyone else?

Up until now @Louis hasn’t imposed his or anyone else’s idea of best practices on users. He has listened and provided features that users requested.

So, I think your points about looking after “DIY users” are absolutely valid and Cwicly should also retain the flexibility and freedom for “Power users” to continue to push the envelope.

I think you and I would agree on most best practices most of the time, so I am not saying there are not common pathways that will usually lead to successful results.

At the same time, Cwicly is a tool that has the potential to cater for website developers of all levels of experience.

Having guidelines and guard rails to help less experienced users is essential.

For experienced developers, giving them the power to “break the rules” and trusting them to be responsible for the results is what leads to further innovation and improvements overall.

A simple way to answer this is by redefining the question first.

A conscientious business’s success can be quantified by it’s customers’ success. So in that sense, Cwicly doesn’t have to define success, as much as define its target users.

@Louis has already clarified his intentions of building a strong community to help progress things and to invite open source contributions. So from this it is clear that experienced developers and other users familiar with Cwicly that have something valuable to contribute are definitely within its target user base.

So it logically follows that a good strategy is to devote at least a portion of time to giving them what they need.

Say what you want but it is evident that @Louis has always demonstrated a very clear acumen when it comes to this.

I think this discussion mirrors ones that have been happening over the last few decades of tech on the internet.

There was at one time discussion of removing the “View page source” feature from browsers by default and requiring a browser extension to re-enable it.

The logic was that the majority of browser users are not developers therefore they have no need for it and developers are more than capable of installing an extension.

The obvious counter to that was that developers are the ones that create the websites and the browser would be redundant without them. As developers tend to care more about what goes into the browser and will actively help improve it, it’s probably a good idea to cater for their needs as well.

I think the resolution here is the same as for cases like that. Feedback will act as a guide to get to the ideal balancing point.

There will never be a full consensus, and majority rule won’t necessarily lead to good outcomes, so all we can do is keep the conversation going and rely on @Louis’s better judgement.

3 Likes