What about ClassicPress?

Hi all!

I recently found out that there is an interesting fork for Wordpress called ClassicPress. A group of developers and enthusiasts took a version of WP 4.9 and based on it made ClassicPress: classicpress.net. The main point of this project is that there is no Gutenberg, support for older versions of PHP is removed, and some basic functionality will be carried out in plugins. Here you can read: Using WordPress 4.9? 10 Reasons to Switch to ClassicPress

Personally I like this approach when the emphasis is on speed and performance and all this is based on a community opinion, as in Bricks :slightly_smiling_face: If you put together a system like this: Fast CMS + Fast E-Commerce + Quick Visual Builder, then in theory the perfect site :sunglasses: In my practice I work a lot with online stores and for me it is very important.

Questions for Bricks developers. Do you know about this fork and what do you think about it? Will Bricks be implemented there? As far as I understand, from visual builders it already has support for Beaver Builder.

Want to talk about it?

3 Likes

I completely agree. Just got into Bricks Builder and when I see that every single function is improved and just as fast I keep thinking to myself: Why isn’t Thomas and the team stripping down and forking Wordpress or creating a cms from the ground up to get rid of the Wordpress dependency once and for all. Full site editing and the transformation of wordpress.org into a more unintuitive version of wordpress.com is just scary and Automattic seem to be making bad decision after bad decision. I love the plugin-based ecosystem, I love Bricks, but Wordpress seems to be moving away from the professionals day after day. Just stay out of the Webflow „we host you pay” area of things and let us host things ourselves even if we need to pay for the cms itself, ownership is important. Great idea! Hope Thomas and the team start taking it seriously at some point, since I am convinced a lot of contributors will rise to the occasion.

1 Like
1 Like

I don’t get this video’s connection to Bricks. I was suggesting Thomas and the team consider moving away from wordpress and into a leaner cms that is either forked by or developed by them since they seem to have the management skills necessary for a project this big. That could be a risky move, but staying on wordpress might prove to be even riskier considering their latest decision process.

‘Ownership’
I keep hearing this word time and again from people using Wordpress, especially from people developing pagebuilders and plugins, and suggesting it to their users to use Wordpress and not other service providers, like Webflow, or Shopify, because of ‘Ownership’.

There is no ‘Ownership’ in Wordpress. It’s a marketing term misused deceptively in the Wordpress ecosystem.
That free CMS is worthless without using the services of a hosting provider, and users have to pay a fee to a hosting company, to even use Wordpress.

The moment users stop paying a hosting fee, for instance, the ‘ownership’ of the website is gone.
The same is true for Wordpress as it is for Webflow, Shopify, Squarespace, Wix and others.
Thus there are only ‘privileges’ but no ‘ownership’
To host on a third party solution is a ‘Privilege’ and not a ‘Right’, and without a ‘Right’, there can be no ‘ownership’.
Pay to Play.

Yes, an user can move from one hosting provider to another, within the Wordpress ecosystem,but that would be akin to a tenant(lessee) changing a rental place, and taking their furniture (data, themes & plugins) with them to another host (lessor).
If the tenant doesn’t have the money to secure a new lease, or if the hosting provider refuses to grant their service to the user, the furniture is useless, and ownership of that furniture is meaningless.

That apart, Wordpress is successful because of its rich ecosystem of users, products and service providers.
Bricks and others themes and plugins thrive in that ecosystem.
ClassicPress lacks that robust ecosystem in comparison to Wordpress, and so does Joomla and Drupal, which arguably have an edge over Wordpress in some areas.

As far as Gutenberg aka Gutenturd is concerned, in 99/100 instances, products from private players will always outshine a product from a committee of not-for-profit volunteers.
If Bricks continues to outshine Gutenturd, users will keep using Bricks, no matter what direction Wordpress takes.

In the off chance things don’t work as laid out, that video might be of some help.

1 Like

I completely agree with almost everything you said, but to conflate the Wordpress model of dependencies with the Webflow one would be a lapse in logic. With Wordpress I have the ability to choose the companies my websites depend on, an ability which I completely lack with Webflow, a platform where all of my eggs are in their basket so to say.

As for Bricks vs Gutenberg, Classicpress vs Wordpress, you’re completely right. I’m just worried as are many people from the Wordpress community, that we’re going to wake up in a world where the entire cms is “built for everyone” as the Automattic leadership keeps saying, while dropping or radically changing features which are essential for web dev with third party tools like Bricks.

My point was not necessarily that Bricks should support Classicpress, rather that Classicpress is an interesting project with an unfortunate execution, and Thomas and the team seem to have the vision necessary to fill what I (and probably many others) perceive to be a gap in the market of open source/self-hosted CMS software.

2 Likes

Lapse in logic! All eggs in one basket! Built for everyone!
Lot of mind-benders in that paragraph.

Dependencies are a matter of perspectives.
There is a reason I shared that video.
How granular does a user wants to go?

For instance, Bricks is built using Vue, Oxygen with Angular, while Elementor with React.

Does it matter to an user of a page builder whether the technology choice was Vue, Angular or React?
No. The user outsourced that technology decision to a third party, the pagebuilder.
The user is only concerned with the user’s experience of interacting with a pagebuilder, and whether the user is able to achieve the desired outcomes using that pagebuilder.
Some pagebuilders come with an inbuilt form feature with rich integrations and functionality, while others don’t, and an user has to use a third party form plugin in the latter case.
Some pagebuilders lack functionality and a user has to install 20 plugins to achieve the desired result, while some other pagebuilder comes inbuilt with many functionalities and an user only has to install 10 plugins for instance.
A pagebuilder bundles various different technologies and functionalities to give an unified experience to the user, to achieve as many different outcomes as a user desires. Those choices differentiate them from their competitors.

Same goes for Hosting.
Take AWS for example.
When one goes into the weeds of how granular one can go with something like AWS, it is nuts.
One can get into the weeds of AWS directly, else seek assistance from third parties.
Thus there are countless options when choosing hosting providers, and these service providers offer layered solutions on top of something like AWS, i.e. managed hosting.
(Whether it’s Cloud, VPS, Shared, Managed, some other industry term - it’s all managed in a way).

Webflow takes away this hassle from the user.
All a user has to do is hit ‘Publish’ and Webflow takes care of the rest. No hosting worries, no plugin updates nightmare, no roll backs, no bugs, no other shenanigans. It’s super managed. A user doesn’t have to worry about the hosting infrastructure at all, and can focus solely on web design.
An unified solution - CMS, Builder, CMS items, apps, Hosting.
All eggs in one basket! Perhaps the more appropriate term is outsourcing of concerns.
An user outsourced their concerns to an unified service provider.
Elementor also recently started offering hosting solutions, and is following this model.
Some prefer this unified approach, while some prefer granularity like dealing with AWS directly and installing countless plugins, while most fall somewhere in between.

Wordpress - Built for everyone.
What’s wrong with that!
Bricks is built for everyone in a way.
Bricks is for users creating Brochure Sites, WooCommerce Sites, Multilingual Sites, and other sub types.
If a user starts getting worried or starts complaining that Bricks should not focus on multilingual functionality and compatibility and focus solely on Brochure Sites, would that stand make sense?
Some other user might complain that Bricks should not focus on WooCommerce and focus solely on Multilingual functionality and compatibility. Would that stand make sense?
No.
A subset of Bricks clients use multilingual functionality and compatibility, while some other subset use WooCommerce, while some other subset use Bricks to build Brochure Sites, and Bricks has to cater to all their needs if Bricks wants to expand its user base.
So does WordPress.
WordPress has to cater to all their users, if it wants to expand its market share.
Built for everyone! - It’s a good thing.

Forking!
Bricks is puny compared to Elementor in terms of the user base it serves.
Despite all its raging success, Elementor never dared to fork, and stayed within the WordPress ecosystem and is still thriving in it. For Bricks to even consider forking would be a death wish.

ClassicPress!
A link shared above states that they had forked WordPress 4.9.
I visited their website, and now they have forked WordPress 6.0.
It seems that they will keep forking every major version of WordPress.
ClassicPress seems like a hobby project more than anything else.
Why be on a fork, when one can be on the real deal!

Why are you not trying to find any common ground? Built for everyone sounds good in theory, but in practice, focusing on unexperienced users might lead to an environment where some of the features we use now are deemed legacy and might hurt the entire builder ecosystem.

As for trusting a single company with your entire infrastructure we are both right at the same time. It is a matter of preference whether one will store all of their data with a single provider or choose to go to different providers for different services.

The only thing you are not addressing is that wanting a well built CMS with a good plugins, themes, etc. infrastructure that doesn’t tie you to other services as Webflow and co do, will inevitably lead you to Wordpress as there currently are no other options.

So my point remains the same: You say “the real deal”, but one day the real deal might be an open source wordpress.com which is simply not enough for professional site building. And I am not happy with Automattic going that direction.

Why worry about what Automattic is going to do or not going to do?

Do you have any control over it? No

Do I have any control over it? No

Does Bricks or Elementor or any other pagebuilder or plugin has any control over it? No

Does anybody outside of Automattic has any control over what Automattic is going or not going to do? No

What do people have control over?
Where to spend their time and money.

Till the time WordPress/ Bricks/ Elementor/ Webflow/ WooCommerce / Shopify
 offer solutions that meet people’s need, people will spend their time and money on these solutions.
When there are better solutions, people will start spending their time and money on those solutions.

It will all work itself out.
Don’t stress about it.
Cheers.

1 Like

The modular system (core + add-ons) always wins. And it is always effective not only in website development, but everywhere in life.

The problem with Wordpress is that its development is going a bit wrong. Yes, he has always or almost always set and sets trends in website development, including in the page builders. But at the same time, WP developers do not want to solve real system problems that have been accumulating for years. Now there is a slight shift and it pleases, but not everything is so rosy.

Example. For the experiment, I made an online store (with the help of Bricks, of course :slightly_smiling_face:), which houses 100,000+ products. And it works. But it works very slowly on a very powerful hosting. And all this is due to the fact that WP has data for all records written to the same tables “wp_post” and “wp_postmeta”. These tables are overloaded with data and therefore we get a low speed of work, which is no good. Neither the cache nor other optimizations will help here.

The solution to such a problem is another database structure, which requires such an opportunity to create. Or connect to WP databases other than MySQL. There is a much better analogue - PostgreSQL. You need to be able to select database servers, and not focus on just one.

And there will be a lot of such systemic problems. It is for this reason that forks appear. Maybe today it’s a hobby that will become another serious competitor in the web development market tomorrow.

1 Like

Forking is a romantic Idea.
I get the allure of it.
Perhaps this Wikipedia article might shed some light on the realities and the historical context of forking.

Fork (software development) - Wikipedia.

Fastforward almost two years since OP. There is an interesting chat here on running Bricks Builder in ClassicPress 2.X. I got to design pages with Bricks.

1 Like

Did anyone ever suggest to the Bricks team about declaring those dependencies, like what was mentioned in that ClassicPress thread?

I am not a ClassicPress user myself, but better code is better code, no matter which CMS you use Bricks on.

It is in Wait status now: