Notice to Theme Developers Regarding Visual Composer Boycott

My small web development company spends thousands of dollars on themes for our small business customers.

Effective today, we will no longer purchase themes that use Visual Composer and are encouraging others to boycott it as well. Why? There is no sort of a licensing structure in place that makes makes financial sense while allowing us to take care of our clients.

If you want our business, don’t use VC until the folks behind it put together a licensing structure that works for both theme developers and protects end users and web designers. Integrating it into themes and then forcing developers to purchase a full license for each site whenever there is a WordPress update is a valid business strategy, but is the kind of bait and switch in which we will no longer participate.

It’s that simple.

You do realize that WPBakery (the author of Visual Composer) has absolutely no control over the licensing structure? The regulations regarding the usage of extended licenses, which allows theme authors to bundle plugins/scripts with their theme, is put in place by Envato itself and applies to all authors/buyers equally, no matter how big or small an individual author is.

There is nothing WPBakery or any other author can do about it, but to follow it. Your grievance is directed at the wrong party as authors have simply no choice but to follow those regulations, as they otherwise risk having their account suspended or even cancelled.

So instead of punishing authors, talk to Envato about changing their regulations or at least add more flexibility to it, because boycotting an author for regulations s/he did not create and has not an ounce of control over is simply ludicrous and quite frankly insulting to the authors work.

Of course, making the extended license more flexible and tying the original plugin/script author more to the theme buyers will either require that the cost for an extended license will have to increase significantly (right now it is just 5x the standard license costs, no matter how many licenses the theme ends up selling), or plugin/script authors will have to share in the theme revenue. Both of those things will likely cause themes to get more expensive, but without providing plugin/script authors an option to recoup their costs for - in your opinion - having to provide direct support and updates to indirect users, this will simply not work. Plugin/script authors have costs too, and you can’t expect them to work for free.

But as stated, those changes have to be implemented by Envato itself, as the license regulations are imposed by Envato, and not the individual sellers.

I hear you, but the problem is that as a site developer, I just can’t allow VC to be incorporated into themes we purchase anymore. Once I do, I have no idea when the latest WP update is going to break them or when a given theme developer is going to push out an update. I have 14 sites I finished within the last month that have VC baked into them and none of those clients can edit their sites right now. The clients are livid and don’t care whether it is the theme developers’ issue, VC’s issue, Envato’s issue or a WP issue. They blame me and expect a resolution from me.

I would think that with the success WPBakery has had licensing VC to theme developers and that with the success those developers have had selling their themes through Envato, the three parties could work something out so that the end user isn’t completely hosed in a situation like the one we’re in now. You tell me what you’d do in my shoes? Standing in front of the customer and explaining the finer points of licensing while clients are unable to update their sites is not the best course of action. The only solution I have given the current environment is not to install it all. If there is a better solution that keeps my sites functioning, then clue me in. I’m all ears.

So you think it is a valid and fair option for Envato to make extra agreements with certain plugin/script/theme authors, that don’t also apply to all other authors? I don’t think so; regulations must be the same for everybody, no matter how big or small an author is, particularly when it comes to licensing. And to reiterate, the VC authors have no control over the licensing, as the market regulations define those.

And by all accounts, this is the first time that a WP update is causing so much trouble for VC users, but VC is out for several years now (almost 5), and there have been quite a lot of changes and updates to WP during that time, with VC still going strong. And to be fair, the recent WP update is not just causing trouble for VC, but also for many themes and other plugins.

Besides, nobody has to update immediately, just because an update is available, especially if it is such a major update. And if you are using themes that bundle plugins, you should wait even longer, until the theme author gives the okay that a certain version, that also includes updated plugins (if necessary), is compatible. And then there is of course the whole matter of making appropriate backups before making major updates. To me, that is just common sense. Buyers and end users have responsibilities too, it’s not just all on the authors!

Could the VC authors have had an update available earlier? Maybe, but then VC itself is more complex than many themes you can buy on Themeforest, so that is not always possible. Every author has the exact same time to prepare their product for new WP versions (from the moment the first BETA is released, until the final version is out), so how is WPBakery supposed to have their product ready any sooner than your theme author (or other plugin authors) can make their product ready?

1 Like

A better solution is to learn about staging environments and charge your clients a healthy fee for maintenance packages. Never update to a major WordPress version without testing it first on your staging or dev environment.

The WordPress 4.5 upgrade didn’t just break Visual Composer, it broke many other plugins and themes code due to a Javascript API change.

This is no different from any other software. In fact, in most software ecosystems, major version releases often drop backward compatibility. WordPress has been extremely strict about maintaining backward compatibility but of course with millions of different use cases, it can’t be guaranteed.

As far as themes being broken is concerned, contact the author for an updated version of the theme with the latest Visual Composer.


Your focus is still on protecting VC and WPBaker. Mine has to be on the customer. You never answered my question. What is the customer supposed to do in this situation? Our only answer has been to lose a half day of work rolling back old sites so that they can be updated.

The hard truth is that your customers should never have updated without taking the appropriate precautions (backups) and ensuring, that all their plugins/themes are actually compatible. And I’m not trying to protect anybody … I don’t have any skin in this game … but everybody seems to direct their anger to VC and its authors, while there are many more parties involved here. And when it comes to the licensing, that has absolutely nothing to do with WPBakery, and everything to do with how Envato set up this marketplace.

Don’t get me wrong, I can of course understand your and your customers frustrations, but please direct it to where it belongs … and it is NOT Visual Composer or its authors. And as stated before, your customers must take some responsibility to, for basically jumping the gun with their update.

And I fully understand the position this puts you as the person who created/built/designed those websites for your customers … you are now caught in the middle (am a web designer myself), and your customers hold you personally responsible. It sucks and is unfair, but so is blaming individual authors. VC already released an update that is compatible with WP, and it is now up to the theme developers to include that update with their next theme update, after making sure that their theme itself and any other bundled plugins are compatible.

Also, have in mind that many theme’s that bundle VC also modify VC and also include their own set of custom elements, and that is something WPBakery as the original author has no way of accounting or preparing for. And personally, I prefer themes that don’t modify VC, but as the VC API and framework is so incredibly flexible, many theme authors are tempted to do so. That also means, that those themes usually require a little more time to release updates, as all those modification need to be tested/changed as well. But once again, not VC’s or WPBakery’s fault (unless you fault them for providing a flexible and extendable product in the first place).

1 Like

That’s exactly what I addressed in my previous post. Updates for major WordPress versions (like 4.5), shouldn’t be performed without testing in a staging environment first.

I have no interest in defending VC as they only increased our support workload, but it’s about fairness. It’s not their fault. Are you aware that so many plugins and themes broke, WordPress created a topic about it on their support forums:

This has happened before several times, and this is very likely to happen again in future. If it’s not going to be VC, it’s going to be another plugin or a theme. That’s simply how software works.


I no longer buy themes that use VC. An awful plugin that forces the re-invention of the wheel and a steeper learning curve for my clients. The VC frontend editor is clunky and a hindrance to creativity.

1 Like

I am just finding out the bigger problems with Visual Composer. It drops nearly 8,000 characters, or 16 pages of inline code on every page (4,000 from WooCommerce after I deactivated). A short novel. Very slow load time. I am an SEO company and this is a big Google penalty. AND people will not wait. You get 3-6 seconds, that’s it. Sites that use Visual Composer with be hurt in 2 ways: search engine rankings and visitor abandonment from slow load times. We found a theme we loved but took 23 seconds to load (from WP Engine) on mobile. A shame.