CodeCanyon Visual Composer - WordPress Plugin

Guide to Setting Up and Using CodeCanyon Visual Composer in Real Projects

In this article, CodeCanyon Visual Composer refers to the commercial WordPress plugin that is now developed under the name WPBakery Page Builder. That distinction matters: in older themes, archives, and CodeCanyon listings, it often appears as Visual Composer, while current documentation and settings use WPBakery Page Builder. This guide is designed not just to help you turn the builder on, but to integrate it safely into a live site, configure permissions, build a page, verify the output, and understand when another tool might be a better fit.

This material is intended for site owners, content editors, WordPress administrators, and developers who inherit a project with the builder already installed. We will cover preparation, installation, user roles, editors, templates, elements, responsiveness, SEO tools, conflict diagnosis, and a practical section-building workflow. It does not include instructions for purchasing, license activation, or bypassing restrictions - only working with an existing plugin and publicly documented features.

The main goal of this guide is to explain how the builder actually works: a row defines the framework, columns divide the space, elements output the content, and the design and responsive settings turn that structure into a polished public-facing page. Once you understand that logic, CodeCanyon Visual Composer stops feeling like a collection of buttons and becomes a manageable tool for landing pages, promo sections, informational content, galleries, and content-driven pages.

What This Builder Actually Is and Why the Sources Use Two Different Names

This product has a bit of history behind it, and that is why users often get confused. The older name, Visual Composer, refers to the plugin that was sold on CodeCanyon and later renamed WPBakery Page Builder. Separately, there is Visual Composer Website Builder - a different product that you cannot simply install over WPBakery and expect to act as a drop-in replacement. So a download page may say CodeCanyon Visual Composer, while the WordPress menu, documentation, and current tutorials refer to WPBakery Page Builder.

The practical takeaway is simple: follow the WPBakery Page Builder interface and documentation, but remember that older site pages, older themes, and older instructions may still call it Visual Composer. If you maintain an existing site, do not rename pages or remove shortcodes just because the name in the admin panel has changed. The builder stores content in the standard WordPress content area, but the layout itself is often represented by a chain of internal shortcodes. If the plugin is disabled, a visual page can turn into a block of technical shortcode markup, so any migration needs to be handled manually and in stages.

This is not a full theme editor - it is a builder for the content area. It helps you assemble pages, posts, and custom post types if those are enabled in the role settings. Headers, footers, archives, product pages, and global templates are often controlled by the theme or another builder. That is not a flaw, just a product boundary: WPBakery is strong when you need to manage page content quickly, but it does not always replace the theme template system.

Check before you start: if an older site shows editor buttons named Backend Editor, Frontend Editor, or WPBakery Page Builder, while the theme description says Visual Composer, it is almost always the same working stack. But if the source refers to Visual Composer Website Builder, do not assume the instructions carry over automatically.

When CodeCanyon Visual Composer Is Actually a Good Fit

This builder works well for sites where the page structure needs to change regularly without editing theme templates. Common use cases include service landing pages, company pages, feature sections, portfolios, promo pages, help content, card-based layouts, grids of posts, and pages with repeating sections. The editor lets you build a layout from rows, columns, and elements, then fine-tune spacing, backgrounds, buttons, images, responsiveness, and block visibility across devices.

It is especially well suited to projects that already use a theme with built-in WPBakery integration. Many premium themes shipped with custom elements, templates, and styles specifically designed for this builder. In that situation, replacing it with a different editor may be more expensive than carefully configuring the current tool. If a site is already built on WPBakery, it usually makes more sense to study the existing rows, templates, and roles before starting a migration.

For the Content Editor

Editors benefit from visual elements such as text blocks, images, buttons, galleries, separators, tabs, accordions, post grids, and call-to-action blocks. Instead of hand-coding layouts, they can change text, replace an image, duplicate a ready-made block, move a section, and review the result in the editor. But editors need clear boundaries: do not change global spacing without a reason, do not place heavy background videos in every row, and do not add random custom classes.

For the Site Administrator

Administrators get control through Role Manager. You can enable the builder only for the post types you actually need and restrict access to templates, elements, page settings, Grid Builder, presets, and drag-and-drop controls. This matters on sites with multiple roles: authors can be limited to safe elements and prebuilt templates, while administrators keep access to the full set of options.

For the Developer or Webmaster

Developers can use Extra class name, Element ID, custom CSS, the shortcode mapper, and documented API filters. But the safe strategy is not to edit plugin files directly. It is to give blocks stable class names, keep CSS in the theme or the built-in custom field, make changes in small increments, and verify them on a test page.

This product may not be the right fit if you need a full-site editor, global header and footer templates, tight integration with dynamic fields without a theme acting as the middle layer, or a modern block-based workflow without shortcode dependency. In those cases, it is worth comparing WPBakery with Elementor, Divi, Bricks, Beaver Builder, or the native WordPress block editor.

What to Check Before Installing It on a Live Site

Before turning the builder on in a production project, slow down. WPBakery affects the page editor, loads its own styles and scripts, builds layouts through shortcodes, and can conflict with the theme, caching, JavaScript optimization, or custom post types. If the site is already generating leads or sales, work on a copy first, or at minimum prepare a full backup of both files and the database.

Theme Compatibility and the Content Area

WPBakery expects the page template to output the standard WordPress content area. If the theme or another builder removes that call, the editor may report that the page cannot be edited because the standard content area is missing. This is especially common with custom templates, archive pages, complex product layouts, and pages that the theme builds through its own fields.

Test a simple page using a standard theme template. If the builder works there but not in a specialized template, the issue is probably not the plugin installation - it is the template. In that case, do not try to force the editor to run everywhere. Decide where WPBakery should manage content and where the theme should remain in control.

WordPress Version, PHP, and Plugin State

The official changelog shows that the product receives regular fixes, including updates for editors, elements, forms, and access checks. Before you start working with it, make sure WordPress, the theme, and the builder itself are not critically out of date. Do not update everything at once on a live site without a copy. Update the staging environment first, open a few pages in Backend Editor and Frontend Editor, save a draft, and verify the public-facing site.

Caching, Minification, and JavaScript Optimization

Page builders are sensitive to scripts in both the admin area and the public site. If a caching, optimization, or security plugin changes the JavaScript load order, delays script execution, or blocks AJAX requests, the editor may load forever, show a blank canvas, or fail to save changes. Ideally, disable aggressive optimization in the admin area and confirm that deferred-loading settings are not being applied to editor pages.

User Permissions and Post Types

By default, WPBakery may not be available for every content type. If the editor appears on pages but not on posts, portfolio items, or products, check WPBakery Page Builder -> Role Manager. For the relevant role, choose Custom in the post types section and enable only the types where the builder is actually needed. Do not turn it on for everything automatically: the wider the scope, the greater the chance the editor will appear where it interferes with the theme template.

Quick summary: before installation, check the theme, the content area, caching, user roles, and a test page. Skip those four items, and most future issues will look like "the builder is broken" even though the cause is sitting right next to it.

Installation and Initial Testing Without Unnecessary Risk

Installation is standard for a WordPress plugin: upload the ZIP archive through Plugins -> Add New -> Upload Plugin, activate the plugin, and create a new test page. If the plugin comes bundled with a theme, follow the theme author's instructions. In some cases, updating the bundled version happens through the theme's required plugins area rather than through a standalone archive.

After activation, do not start by editing the home page. Create a separate page with a clear name such as WPBakery test, and do not place it in the menu. In the editor, you should see the Backend Editor button and, if allowed by the theme and role, Frontend Editor. Open one of the editors, add a row, two columns, and a simple text block. Save the page, view it on the front end, and confirm that the text appears without stray shortcodes.

What to Check Right After Activation

• Whether Backend Editor opens without an endless loading screen.
• Whether Frontend Editor opens, assuming the theme has not disabled it.
• Whether a simple page with one row and one text block saves correctly.
• Whether styles load on the public page and there is no raw shortcode output.
• Whether the intended user role can see the editor buttons.
• Whether the test page conflicts with caching, minification, or server-side security rules.

Why You Should Not Edit an Old Page Right Away

Older pages may contain custom theme elements, outdated shortcodes, custom CSS, and nonstandard templates. If you open that kind of page and save it without understanding the structure, you can easily change spacing, remove a nested section, or lose CSS stored in the page settings. Test the basic workflow on a new page first, then open the old page, make a copy, and work on the copy.

Post-Install Configuration: Roles, Editors, and Safe Limits

The settings area is the most important part of the initial setup. In WPBakery, the main options live under WPBakery Page Builder. Review the general settings, Role Manager, template access, custom CSS/JS, and extra features. Do not enable everything just because it is available. A well-configured builder gives editors enough power to work efficiently without letting them accidentally break the site's structure.

General Settings

In the general settings, check the responsive behavior of content, Google Fonts subsets, and the guided tour. The official documentation notes that Google Fonts subsets should only be enabled when needed. That is practical advice: extra font subsets increase the number of assets being loaded and often provide little visual value. If the site runs in Russian, verify whether the selected font actually needs a Cyrillic subset, and do not enable uncommon subsets without a reason.

Change the global responsive behavior carefully. By default, elements should stack on smaller screens so columns do not become narrow strips. If you disable that behavior, a complex section may look fine on a large screen but fall apart on a phone. For most sites, it is safer to keep the default responsive logic and fine-tune width, spacing, and block visibility within individual row and column settings.

Role Manager for Editors and Clients

Role Manager lets you manage access by WordPress role. Administrators usually keep full access. For content editors, it is smarter to restrict risky settings: access to Page settings with custom CSS, global settings, template deletion, saving new presets, and some elements that can disrupt the layout. If editors only need ready-made sections, let them apply templates but not create or delete shared templates.

After each role change, save the settings, sign in as a test user with that role, and open the test page. Verifying access as an administrator does not prove that an editor will see the same controls.

Backend Editor or Frontend Editor

Backend Editor is useful when you need to see structure: rows, columns, nested elements, templates, grids, and more complex blocks. It depends less on the current visual state of the public page and works well for technical editing. Frontend Editor is helpful when visible spacing, background settings, image sizing, and overall visual output matter most. But it is also more sensitive to the theme, caching, scripts, and nonstandard templates.

For a typical site, the most practical workflow is to build the structure in Backend Editor, review the visual result through preview, and use Frontend Editor only where it adds value. If front-end mode does not work in a specific theme, do not assume the entire product is broken. Some themes genuinely limit or override builder behavior.

Custom CSS and JS

WPBakery includes fields for custom CSS and JS, but they should be used carefully. CSS is fine for small visual adjustments when you have a precise class to target. Add JS only if you understand what it does and only if it does not affect forms, checkout flows, security, or other critical behavior. For most tasks, it is better to use CSS, an extra element class, and a quick test on a staging page.

Rollback rule: before changing global CSS, copy the old snippet into a note, apply the new code only to the class of a specific section, and test the page in an incognito window. If the result is not right, remove one snippet instead of hunting for the problem across the entire site.

How Rows, Columns, and Elements Work in WPBakery

To use the builder confidently, you need to understand not just the button names, but the internal logic of the layout. The basic unit is the Row. A row defines the horizontal layer of the page: width, height, background, stretch behavior, spacing, parallax, video background, animation, and extra classes. Inside the row are columns. Columns divide the space and determine where the text, image, button, or form will appear. Elements live inside the columns.

If a page looks wrong, the cause is often not a specific button - it is the level where the setting was applied. For example, the background for an entire section usually belongs at the row or section level; the spacing between text and a button belongs at the element level; the width of the content area belongs at the row level; and mobile behavior belongs at the column and responsive-settings level. The more accurately you choose the level, the fewer side effects you create.

The Row as the Framework of a Section

A row is the place for larger layout decisions: background, overall width, vertical alignment, equal-height columns, full-width stretch, and disabling a block. If you are building a hero section or a feature block, start with the row: decide whether it should span the full width, whether it needs a background, how many columns it requires, what gap should exist between them, and how the section should behave on smaller screens.

The Column as a Meaningful Container

A column is responsible for grouping elements. For example, the left column may contain a heading, text, and a button, while the right column holds an image. If you need to change the order or width on mobile, the relevant setting is usually closer to the column than to an individual text block. It is important not to create too many small columns without a good reason: on a desktop layout that can look neat, but on mobile it often turns into a long and awkward sequence.

The Element as the Working Content Unit

Elements output the actual content: text, image, button, gallery, tabs, accordion, post grid, call-to-action block. Each element has its own settings, along with common fields such as Element ID, Extra class name, and Design Options. Do not fill Element ID with random words - the ID should be unique on the page. In most CSS scenarios, Extra class name is enough.

My Elements and Presets

The My Elements feature is useful when you configure an element once and want to reuse it. For example, you can save a button with the right style, spacing, and class, then insert it into multiple sections. That is safer than manually picking the color, size, and border radius every time. But presets need clear names: Primary CTA, Small outline button, Promo text block. Names like test2 quickly turn the library into a mess.

Templates, Template Library, and Reusing Blocks

WPBakery gives you several ways to avoid building every page from scratch. You can save your own layout as a template, use the template library, copy and paste elements between pages, and save individual elements as presets. This is especially helpful on sites that regularly publish similar landing pages, service pages, benefit sections, or promo blocks.

When to Use Your Own Templates

A custom template makes sense when the site has a recognizable structure: hero section, benefits block, testimonial section, gallery, call to action. Build that page once, test the responsive behavior, assign clear classes, and then save the finished parts. An editor can insert the block and replace the text without touching the spacing or layout. That reduces the chance of accidental breakage.

When Template Library Makes Sense

Template Library provides ready-made layouts that you can download and adapt. The official documentation notes that the library is available through the templates window in the builder panel. It is useful as a starting point for a new page, but you should not insert a template and publish it unchanged. Review the structure, remove unnecessary elements, replace the images, adjust the typography, and confirm that the template does not clash with the theme design.

Copying Between Pages and Sites

Copying elements is useful for repeating blocks. But if you move a block between different sites, make sure WPBakery is installed and active on both, and that any theme elements or add-ons used by the block are available as well. Otherwise, part of the layout may fail to render or turn into an unknown shortcode. It is safer to move simpler blocks: rows, columns, text, images, buttons, and basic elements.

Practical tip: keep your core sections on a separate utility page hidden from the menu. That way, editors can copy proven blocks instead of digging through an old page that "looked kind of similar once."

Practical Example: Building a Hero Section for a Service Page

Now let us walk through a real scenario. Suppose you need to create the top section of a service page: heading, short explanation, and button on the left, with an image or illustration on the right. The section should look clean on desktop, stay intact on mobile, and include a clear call to action. This example shows the logic of CodeCanyon Visual Composer well: first the framework, then the content, then the design, responsiveness, and verification.

Goal

Create a section you can use on a service page or promo page: a large heading, two or three sentences, a button, an image, a background color, and solid spacing. The section should be easy for an editor to work with and should not require manual changes to the theme template.

Preparation

• Create a test page and open Backend Editor.
• Prepare an appropriately sized image - do not use a random oversized photo without compression.
• Decide what text will appear in the heading, description, and button.
• Make sure the administrator role has access to rows, columns, images, buttons, and Design Options.

Build Steps

1. Click Add Element and add a Row.
2. Choose a two-column structure, either equal width or a wider left column for text.
3. Add a Custom Heading or Text Block to the left column for the heading.
4. Add a Text Block below it for the short explanation.
5. Add a button element and set its text, link, size, color, and alignment.
6. Add a Single Image element to the right column and choose an image from the media library.
7. Open the row settings and configure the background plus top and bottom spacing through Design Options.
8. Check the vertical alignment through the content position setting if the text and image do not line up evenly.
9. Save the page and open the front-end preview.

How to Review the Result

On a wide screen, the section should feel visually balanced: the text should not be pressed against the edge, the button should not be glued to the paragraph, the image should not stretch unnaturally, and the background should not repeat in odd fragments. On mobile, the columns should stack in a usable order, and the heading should not consume half the page in a single long line. If the image ends up above the text, decide whether that order still works. In many cases, mobile is better with the text first and the image second.

A Common Detail That Gets in the Way

If the background looks repetitive or crops oddly, check where it was applied. A row background, a column background, and an individual element background behave differently. For a full hero section, you usually want the background on the row or section level; for a highlighted card, you usually want it on the column or element. If spacing changes do not work, confirm that the theme is not overriding the container CSS.

Responsiveness, Performance, and SEO: Settings You Should Not Leave for Later

A page builder makes layout assembly easier, but it does not remove your responsibility for speed, readability, or indexing. WPBakery includes responsive controls, width and visibility settings, a built-in SEO tool, custom CSS, grid elements, and media options. They need to be used carefully: a visual page should not just look good in the editor - it should also be fast, understandable, and verifiable on the public site.

Responsive Columns

Test every important section in at least three states: wide desktop, tablet width, and phone width. If two columns contain a lot of text and a large image, standard stacking is usually better than forcing both columns to remain side by side on a small screen. In the column settings and design options, use width, offset, and visibility only where they genuinely improve readability. Do not hide important text on mobile just to make the layout look cleaner.

Background Videos, Parallax, and Heavy Images

WPBakery supports video backgrounds, parallax, and image filters, but that does not mean every page needs them. Those effects add weight, can hurt the mobile experience, and may conflict with optimization settings. If you want an effect in the first screen, test load speed, make sure there is a static fallback image, and verify the behavior on a phone. For informational pages, a lightweight background, a solid image, and clear text are often the better choice.

WPBakery SEO

The built-in WPBakery SEO tool is available from the editor panel and helps with the title, description, key phrase, content analysis, and social preview settings. It should be treated as a supplemental check, not a replacement for a full SEO plugin or for editorial judgment. If the analysis says the page has too little text, no internal links, or missing social data, that is a reason to improve the page - not to mechanically repeat the key phrase ten times.

A Safe CSS Tweak for a Button or Section

If you need to adjust the appearance of a specific section carefully, use Extra class name. For example, give the row the class service-hero and the button the class service-hero-button. You can place the CSS in WPBakery's built-in custom CSS field, in the theme's Additional CSS, or in a child theme. Below is a small, reversible change that does not depend on the plugin's internal classes and does not modify plugin files.

.service-hero {
  padding-top: 72px;
  padding-bottom: 72px;
}

.service-hero .service-hero-button {
  margin-top: 20px;
}

@media (max-width: 767px) {
  .service-hero {
    padding-top: 40px;
    padding-bottom: 40px;
  }
}

The verification is simple: open the page, confirm that the spacing changed only in the intended section, then check the mobile view. Rolling it back is just a matter of removing that CSS snippet and saving the settings. Do not use edits like this to hide structural problems. If the section is built incorrectly, fix the rows and columns first, and use CSS only for fine-tuning.

How to Verify the Result After Publishing

Publishing the page is not the end of the job. The builder may look correct in the editor, but the public-facing result still depends on the theme, caching, optimization, roles, and devices. After every meaningful change, run through a short verification path. It takes a few minutes and can save hours of troubleshooting.

Front-End Check

• Open the page in a normal browser window and in incognito mode.
• Clear the site cache if a caching plugin or CDN is enabled.
• Check the first screen, buttons, images, gallery, and tabbed content.
• View the page at mobile width, especially sections with columns.
• Make sure no raw shortcodes are visible on the page.
• Check the browser console if the editor or interactive elements behave strangely.

Editing Check

After publishing, open the page again in Backend Editor. If the canvas is blank, buttons do not work, or the editor loads forever, do not keep editing blindly. Resolve the conflict first. Check whether the roles changed, whether a new optimization plugin was enabled, whether the theme was updated, or whether the standard content area disappeared.

SEO and Link Check

If the page matters for search visibility, review the title, meta description, main content, internal links, and buttons. WPBakery SEO may point out part of the problem, but the final judgment still belongs to the editor. The page should satisfy the user's goal, not just pass an analysis indicator.

Why the Editor or the Page May Not Work Correctly

Most WPBakery issues look similar: the editor does not load, the buttons are missing, the page does not save, styles do not apply, shortcodes appear on the site, or a specific post type cannot be edited. It is important not to treat everything with the same fix. Below is a diagnostic path based on symptoms, likely causes, and safe actions.

Editor Loads Forever

Symptom: after clicking the editor button, you see a spinner but the canvas never appears. The official knowledge base recommends first confirming that WordPress is up to date and then checking for third-party plugin conflicts. In practice, the cause is often JavaScript optimization, a security plugin, a theme conflict, or an error in admin-side scripts.

What to Check

• Whether a simple test page opens correctly.
• Whether there are JavaScript errors in the browser console.
• Whether the problem disappears when caching, minification, and security rules are temporarily disabled.
• Whether the editor works with a default theme on a staging copy.

How to fix it: disable conflicting plugins one at a time on a staging copy, exclude editor pages from optimization, update the theme and the builder, and then re-enable plugins gradually. If the issue is theme-related, it is usually best to contact the theme author, especially if WPBakery was bundled with it.

The Editor Button Does Not Appear for Posts or Custom Post Types

Symptom: the builder is available on pages, but there is no button on posts, portfolio items, or products. A likely reason is that the post type is not enabled in Role Manager. The official documentation notes that you need to select a custom set of post types for the role and enable the specific types you want.

How to fix it: open WPBakery Page Builder -> Role Manager, select the administrator or editor role, enable the required post type, and save. Then verify the page while signed in under the same role whose access you changed.

Missing Content Area Message

Symptom: the editor reports that the page cannot be edited because the standard WordPress content area is missing. The cause is usually a theme template or another builder that does not output standard content through the normal WordPress mechanism.

How to fix it: switch the page to a regular template if the theme allows it. If this is a system page, archive, or product layout, do not try to force WPBakery onto it. That type of page may need to be configured through the theme, a WooCommerce template, or a separate theme builder.

Styles Do Not Appear After Saving

Symptom: the changes are visible in the editor, but the public page still shows the old design. Possible causes include page caching, minification, a CDN, theme CSS, permissions issues when saving custom CSS, or an optimizer conflict. Sometimes the editor saves the content correctly, but the cache continues serving the older version.

How to fix it: clear the WordPress cache, browser cache, and CDN cache if applicable. Check the page in incognito mode. If the problem affects only custom CSS, move the important small CSS snippet into the theme's Additional CSS or a child theme instead of leaving it in an unstable location.

Shortcodes Are Visible on the Page

Symptom: instead of a normal layout, visitors see internal shortcode markup in square brackets. This can happen if the plugin is disabled, a required add-on is missing, the page was moved to a site without WPBakery, or the theme uses elements that do not exist in the current installation.

How to fix it: verify that WPBakery and all add-ons used in the layout are active. If you migrated the page, make sure the same set of elements exists on the new site. If you are moving to a different builder, plan a manual page rebuild instead of trying to strip shortcodes automatically.

The Page Will Not Save or the Server Returns an Error

Symptom: simple edits save correctly, but a complex block, inline CSS, or a long section triggers an error. Possible causes include server-side security rules, request limits, a theme conflict, an error in custom code, or a security plugin. Do not disable protection on a live site unless you understand the cause.

How to fix it: save a copy of the page first. Simplify the problematic block and test which part triggers the error. If the server is blocking the save because of a security rule, contact your hosting provider with the exact time of the error and the admin request URL. If the error disappears after removing custom CSS or JS, add the code back in small pieces.

Limitations and Decisions Worth Accepting Up Front

WPBakery is useful, but it comes with important limitations. The first is its dependence on shortcode-based structure. As long as the plugin is active, that is a workable way to store layouts. But if you decide to move to another builder, automatic migration almost never produces a perfect result. Pages need to be rebuilt, blocks compared, and the public display checked manually. That matters even more on sites with dozens of landing pages.

The second limitation is the difference between a page builder and a theme builder. WPBakery edits the content area, but it does not always control global templates. If you need full control over headers, footers, archives, product cards, and dynamic templates, verify whether your theme covers that or whether you need another tool. Do not promise a client that a single plugin will replace the entire theme.

The third limitation is performance. Any visual builder adds markup, styles, and scripts. That is not a reason to reject it automatically, but it is a reason to work with discipline: do not insert unnecessary elements, do not duplicate heavy sections, optimize images, check caching, and avoid visual effects that serve no purpose.

How to Decide Whether to Keep Using It

• If the site is already built on WPBakery and the editors are comfortable with it, improve the roles, templates, and troubleshooting workflow.
• If you are starting a new project from scratch and need full template control, compare modern alternatives before you begin.
• If the main pain point is speed, optimize images, caching, and unnecessary elements first instead of blaming one plugin immediately.
• If migration is required, rebuild pages gradually and keep the old version until the new result has been verified.

When CodeCanyon Visual Composer Is the Right Choice

CodeCanyon Visual Composer is worth using if your site already runs on WPBakery, your theme supports it well, your editors need a straightforward builder for content pages, and the project does not require a full replacement for the template system. In that scenario, the best results do not come from a "magic" installation. They come from discipline: a test page, role settings, clear templates, a limited set of elements, responsive checks, and careful conflict diagnosis.

If you are still choosing a tool for a new site, evaluate more than the look of the editor. Think about the long-term consequences: how layouts are stored, who will edit the pages, whether a free version matters, whether you need global templates, how important performance is, and whether the team is ready to maintain the chosen stack. For an older WPBakery site, it is often more practical to clean up the current system first and decide on migration later.

Once the preparation is done, the roles are configured, the test page saves correctly, and the public result has been checked across devices, you can get the CodeCanyon Visual Composer package and use the archive within a safe workflow: staging first, then a copy of the important page, then publication and final verification.