Because there was the first question about a page builder: https://community.getbeans.io/discussion/beaver-builder-and-the-navbar/
Maybe Beans should come with support for a opensource page builder. Many people like those tools. Siteorigin is opensource and one of the most used builders: https://de.wordpress.org/plugins/siteorigin-panels/
A few thoughts.
Seems to me this is a bit of a strategic choice. One which pretty much puts the framework in a corner in regards to market segmentation. WP is exploring the live composer road, and just about every marketplace has its own top dog builder. And there's the niche of custom fields (which is getting better with front-end editing evolution but which is a dying breed in the long road either way).
A lot of this comes down to what Thierry has in mind on a strategic level. Will beans remain a free & open (source) framework without commercial enablement? Will it split in in a baseline + commercial licensing model? These are types of questions which may be tough, and perhaps too early for him to engage or explore in, but the answers will define what primary (free), secondary (serviced) or tertiary (licensed) paths have to be put in place.
Don't get me wrong, people will do their thing anyhow. A good initiative is never a bad idea, but it can be a bad thing down the road.
Wouldn't it make sense then to make use of UIKit for the typical elements which people use for putting page / post content together? There's been very little in regards to the combination of Wordpress / UIkit ever since bootstrap. There's one plugin (abandoned) which aimed to provide integration for page / post builder. Meanwhile there's a lot of talk at Automatic about tightening the screws on frameworks (a topic in its own right).
One thing I noticed, is that it is very hard to find a page builder which does not sucker people with vendor lock-in. I recently bumped into someone who had to migrate away from Visual Composer. I've seen dead people who looked more alive than him. I'd leave the option for vendor-lock in up to those who go to work with the framework, so to speak.
There's this voice in my head yapping around, telling me that enabling beans with such a (nowadays common) feature is something which to a high degree is in the corner of uikit. Getting beans to a ready-state is a big project in its own right.
Here's a question though. Whatever happens, many people will use many types and sorts of visual page / post builder tools anyway. Isn't there a potential for conflicts & compatbility?
Also, isn't that going to impact strong points of beans, like performance, speed and such?
I'm not a programmer, I'm far from a developer. If anything I'm more of an example of what beans if succesfull (you know what I mean) is going to have to deal with 😛 I do realise that there is no avoiding contact with this kind of thing.
Hey guys,
This is an interesting discussion. In the WP extensions world, lots of products unfortunately require some special attention (code wise) to integrate smoothly with the various themes. The issue is that they think they are alone in the world and themes should just add support for them.
From Beans point of view, we want to keep it as clean as possible and not add support for a zillion plugins in the Core as every website is different and uses different plugins if not none. It starts with "What about adding support for WooCommerce since it is so popular" and then "What about EDD since it is like WooCommerce but for digital products" and then "Can we have support for JetPack since it is made by Automattic" and then "Oh, Beaver Builder is the most popular plugin on the market, can you add support for it in Beans Core" and then "..." and then "..." and before you know, we have more code for plugins support than for the theme itself.
So here is the solution, building plugin to integrate each of these super star requiring special treatment which you can be installed if you use one of these. At this stage, it is not next on the list to build official Beans Plugins Integration and I would love to see the community starting to get their hands dirty. The forum Extend category is welcoming you to come to the party and extend Beans.
J.C. to answer your question about "Beans Strategy" and pricing, Beans is free and will always be. Beans API being so powerful, I do think that some commercial add-ons will come very soon whether it is on the official Beans website or on a third party market place. With Beans growing so quickely and being so flexible and easy to extend, this is inevitable and a good thing for Beans growth 🙂
Thanks for your contribution guys,
My 2 cents: I love Beans because it is so powerful from a programming standpoint. I can see that I will become able to "do anything" with the Beans framework (once I learn my way around a little better), just as I can now do "pretty much anything" with PHP to build a website however I want. Thing is, clients want WordPress, so I need to be able to deliver custom WordPress themes for them.
The whole thing about page-builder app-type-thingies is that they are all limited in what they can accomplish. That is, all the page-builder type programs I've encountered are limited and frustrating to the max.
And yeah, I agree with Thierry that adding support for sundry plugins is a slippery slope that can eat time and resources that are often best used elsewhere = on Beans itself.