Key facts at a glance
WPBakery troubleshooting in 2026
Last updated
- Name the fault first
- Loading, front-end rendering, and saving are three different faults with three different fixes. The most common wasted hour is treating raw shortcodes on the front end as a broken save.
- The signature front-end fault
- Raw
[vc_row]text on the front end means the shortcodes are not being processed. The plugin is inactive, the post type is off in Role Manager, or CSS and JavaScript are disabled. - Why saving fails
- A complex page can exceed PHP’s
max_input_varsdefault of 1000, so PHP truncates the extra fields and elements reset on save. Raise it to 3000 or higher. - Role Manager is the key panel
- WPBakery then Role Manager controls which roles and post types can use the builder. It is the fix for both raw shortcodes on the front end and the builder missing on posts or custom post types.
- The resources WPBakery needs
- PHP 7.4 or higher, MySQL 8.0 or higher or MariaDB 10.4 or higher, and a memory limit of at least 256MB. Plus a raised
max_input_varsfor big pages. - Often bundled with your theme
- WPBakery, the js_composer plugin, ships bundled with many premium themes, so it installs and updates through the theme, not as a standalone zip. That explains most install and version-mismatch problems.
Source: the WPBakery Page Builder knowledge base on the spinning editor, the missing content area error, using it on posts and custom post types, the plugin settings, the install error, and the system requirements, plus our hands-on page-builder repairs. Get a quote in 60 seconds →
Why WPBakery breaks
WPBakery Page Builder, known in code as js_composer, builds pages from shortcodes. Every row, column, and element is a shortcode with its settings, and the editor is a layer of JavaScript that lets you arrange them visually. That design shapes how it breaks. The editor is JavaScript, so a script conflict or aggressive optimization stops it loading. The save sends every shortcode field to the server at once, so a big page can hit a PHP limit and lose data. And the front end depends on those shortcodes being processed into HTML, so if the plugin that defines them is not active, the page shows the raw shortcodes instead of your design.
It is also the builder most often bundled with a premium theme rather than bought directly, and that matters for troubleshooting. A bundled copy is installed and updated through the theme, not from WPBakery, which is why uploading a zip can fail and why a theme update can leave the builder out of sync. When someone deactivates the theme or the bundled plugin, every page built with it can suddenly render as raw shortcodes, which looks alarming but is usually a quick fix once you know the cause.
The good news is that the failure modes are finite, and almost all of them fall into three families, plus a short list of named errors. Getting clear on which family you are in is the fastest route to the fix, and it is what the rest of this page is organized around. Elementor and Divi fail in similar families for similar reasons, and we fix all of them, but the settings here, especially Role Manager and the shortcode behavior, are WPBakery specific.
The three faults
Nearly every WPBakery problem is one of these three. They look alike from the outside but need opposite fixes, so name yours before you change anything.
The editor will not LOAD
A delivery problem, getting the builder to you. The Backend or Frontend Editor is blank or spins forever. Caused by a conflict with another plugin, an optimization plugin minifying or combining the builder scripts, a jQuery clash, or a server low on memory. WPBakery has no safe mode, so isolate the conflict by deactivating plugins and reactivating one at a time, and raise memory to the 256MB minimum.
The front end will not SHOW your design
A rendering problem, unique to shortcode builders. The page prints raw [vc_row] and [vc_column] as text instead of your layout, which means the shortcodes are not being processed. The plugin is inactive or missing, often because a theme-bundled copy was deactivated, the post type is off in Role Manager, or CSS and JavaScript are disabled in the settings. Reactivate the plugin, enable the post type, and turn CSS and JavaScript back on.
Changes will not SAVE
A submission problem, and WPBakery’s most classic one. A complex page saves partially, loses rows, or resets elements because it submits more fields than PHP’s max_input_vars limit of 1000 allows, so PHP silently truncates the rest. Raise max_input_vars to 3000 or higher, confirm memory meets the 256MB minimum, and rule out a firewall or plugin blocking the save.
Error and symptom reference
Find the exact message or symptom you see. Each row says what it means and where the fix is.
| Error or symptom | What it means and how to fix it |
|---|---|
| The editor is blank or shows a spinning icon forever | The builder JavaScript is broken by a plugin conflict, minification, or a jQuery clash, or the server is low on memory. Isolate plugins one at a time, disable minification, and raise memory. |
| Content shows as raw [vc_row] or [vc_column] text on the front end | The shortcodes are not being processed. The WPBakery plugin is inactive or missing, the post type is off in Role Manager, or CSS and JavaScript are disabled. Activate the plugin, enable the post type, and turn on CSS and JavaScript. |
| Changes will not save, elements reset, or rows disappear on save | The PHP max_input_vars limit is truncating a complex page’s fields. Raise max_input_vars to 3000 or higher, and confirm memory meets the 256MB minimum. |
| "This page can not be edited with WPBakery since it is missing a WordPress default content area" | The theme page template does not call the WordPress the_content function that WPBakery renders into. Use a template that includes the content area, or add the_content to a custom template. |
| WPBakery is not available on posts or custom post types | Those post types are not enabled. In WPBakery then Role Manager, set Post Types to Custom and tick the posts and custom post types you want to build with. |
| The Backend or Frontend Editor buttons are missing | The plugin is deactivated, a Role Manager restriction is hiding it, or a conflict. Confirm the plugin is active and check the role and post-type settings in Role Manager. |
| "The package could not be installed. No valid plugins were found." | You uploaded a file that is not a standalone plugin zip. A theme-bundled WPBakery installs through the theme, not as an uploaded zip. Use the theme’s included-plugins prompt. |
| PHP memory limit error or a white screen while editing | The site hit its memory ceiling building the page. Raise the WordPress memory limit to at least WPBakery’s 256MB minimum in wp-config.php or a php.ini file. |
| Internal server error or a 500 when opening the builder | A PHP fatal, a low memory limit, or a plugin conflict. Read the server PHP error log, raise memory, and isolate plugins. |
| The front end shows the old design after an edit | A caching layer is serving the old page. Clear your caching plugin, host cache, and CDN, and hard refresh the browser. |
| Elements or styling break after a theme update | A theme-bundled WPBakery version fell out of sync with the theme. Update the theme, which updates its bundled WPBakery, then clear the cache. |
| The builder loads but is slow, or pages feel laggy to click | That is a performance problem, not a broken builder. Heavy builder JavaScript ties up the main thread and fails INP, the responsiveness Core Web Vital. |
What we fix in WPBakery
Twelve problem areas cover almost every WPBakery emergency. We diagnose which one is actually yours rather than guessing.
Editor Blank or Spinning
The Backend or Frontend Editor stays blank or spins forever. A plugin conflict, minification breaking the scripts, a jQuery clash, or low memory. We isolate the conflict and raise the limits.
Shortcodes Showing as Text
The front end prints raw [vc_row] and [vc_column] instead of your design. The plugin is inactive, the post type is off in Role Manager, or CSS and JavaScript are disabled. We get the shortcodes processing again.
Changes Not Saving
Complex pages save partially, lose rows, or reset elements. The PHP max_input_vars limit is truncating the save. We raise it and right-size memory so big pages save whole.
Missing Default Content Area
The builder refuses a page because the theme template has no the_content. We move the page to a compatible template or add the content area so WPBakery can build.
Not Available on Post Types
WPBakery is missing on posts or custom post types. We enable them in Role Manager so the Backend and Frontend Editor buttons appear where you need them.
Editor Buttons Missing
The Backend or Frontend Editor buttons are gone. A deactivated plugin, a Role Manager restriction, or a conflict. We restore access and the builder controls.
Install Error: No Valid Plugins
The no valid plugins were found error on install. A theme-bundled WPBakery installs through the theme, not an uploaded zip. We install the right copy the right way.
PHP Memory Limit Error
The site hits its memory ceiling building a page. We raise the WordPress and PHP memory limits to at least WPBakery’s 256MB minimum so the builder has room.
Front End Differs from the Editor
The editor looks right but the live page does not, usually a caching layer serving an old copy. We clear the cache plugin, host cache, and CDN in the right order.
Minification and jQuery Conflicts
A performance plugin combining or minifying JavaScript corrupts the builder scripts. We exclude WPBakery from minification so the editor loads and saves.
Version Mismatch After a Theme Update
A theme-bundled WPBakery falls out of sync with the theme. We update the theme so its bundled builder matches, then clear the cache.
Slow Editor and Laggy Pages
The editor drags or the published page feels laggy to click. Heavy builder JavaScript on the main thread. We reduce and defer it, measured against INP.
The settings that fix most of it
WPBakery does not have a one-click safe mode like some builders, but a short list of settings and checks resolves the large majority of problems. Work through these before anything drastic, because they are quick and reversible.
Under WordPress Dashboard then WPBakery Page Builder then Role Manager, set Post Types to Custom and tick every post type you build with, including posts and custom post types. This is the fix when the builder is missing on a post type, and one of the first checks when the front end shows raw shortcodes, because a page built on a post type that is not enabled will not have its shortcodes processed.
For a blank or spinning editor, WPBakery’s official method is manual isolation. Deactivate all your other plugins and confirm the editor loads, then reactivate them one at a time until it breaks again, which names the culprit. If deactivating an optimization plugin fixes it, the cause is minification or file-combining corrupting the builder scripts, so exclude WPBakery from those settings rather than leaving the whole plugin off.
A complex page submits many shortcode fields at once, and PHP’s max_input_vars default of 1000 truncates the rest, which is what resets elements on save. Raise it to 3000 or higher in php.ini, or through .htaccess or wp-config.php if you cannot edit php.ini, and confirm the memory limit meets the 256MB minimum.
In WPBakery then General Settings, confirm the CSS and JavaScript options are enabled, since disabling them can strip the styles and behavior the front end needs. Then clear your caching plugin, host cache, and CDN, because a cached copy can keep serving an old or broken version of the page after you have fixed the cause.
Why specialist WPBakery work helps
WPBakery problems are often more confusing than other builders because the same symptom can come from the plugin, the theme that bundles it, the server, or a cache, and the raw-shortcode failure in particular looks like the whole site is broken when it is usually a single setting. Without a safe mode, isolating a conflict means methodical plugin-by-plugin testing on a live site, which is exactly the slow, nervous work most owners want to hand off. The skill is recognizing the fault family fast, the blank editor, the raw shortcodes, or the failed save, and going straight to the WPBakery setting or server limit behind it.
We do this all day, so the process is the same every time. Confirm the public site works, which tells us this is a builder problem and not a whole-site critical error. Identify whether the fault is loading, rendering, or saving. Then go to the right lever, Role Manager for shortcode and post-type problems, conflict isolation for a dead editor, max_input_vars and memory for failed saves, the theme for a bundled-version mismatch, and test that the page loads, renders, and saves. We charge a flat rate because we are fast at finding the one setting that matters, rather than billing hours against guesswork.
The 2-hour guarantee and the money-back promise are the enforcement. We do not get paid if we cannot get your builder loading, rendering, and saving for the agreed scope. If the real limit is your hosting plan or a theme that has to be updated or replaced, we tell you that up front rather than charging for a fix that cannot hold.
Related fixes and hubs
WPBakery problems often sit next to a broader WordPress issue, or a different page builder. These are the pages for the ones that reach past WPBakery itself.
On Elementor instead of WPBakeryThe Elementor repair hub. The same fault families, with Elementor’s Safe Mode, editor loader method, and generated CSS.
Elementor repair hub →On Divi instead of WPBakeryThe Divi repair hub. The same three faults, with Divi’s Safe Mode, System Status, and static CSS cache.
Divi repair hub →WPBakery pages slow or laggy to clickHeavy page-builder JavaScript ties up the main thread and fails INP, the responsiveness Core Web Vital. A field metric you cannot read in the lab.
Fix high INP →The whole site is down, not just the builderA blank page or a critical error for every visitor is a PHP fatal error, diagnosed through the debug log, not a WPBakery-only problem.
Recover a critical error →Allowed memory size exhaustedThe PHP memory limit is below WPBakery’s 256MB minimum. We right-size memory so the builder has room to load and save.
Fix memory exhaustion →Everything WordPress repairThe parent hub for plugin, theme, update, and critical-error repairs across WordPress, with WPBakery as one part of it.
Visit the WordPress hub →Pricing and process
Send your site and the symptom
Use the quote form with your URL and what WPBakery is doing, will not load, showing raw shortcodes, or will not save. A senior engineer replies with a flat-rate quote, usually within 30 minutes during business hours.
Approve, we start immediately
No scheduling step, no kickoff call. Approve the quote and we begin. You provide WordPress and hosting access through a secure link. The clock starts on the 2-hour guarantee.
Building restored and tested
We fix the real fault, confirm the builder loads, the page renders, and it saves, and tell you what caused it. Money back if we cannot get WPBakery working for the agreed scope.
WPBakery troubleshooting FAQ
Why will the WPBakery editor not load, or show a spinning icon forever?
When the Backend or Frontend Editor stays blank or spins after you click the WPBakery Page Builder button, its JavaScript is being broken or the server is starved. The usual causes are a conflict with another plugin, an optimization plugin minifying or combining the builder scripts and corrupting them, a jQuery conflict, or a memory limit set too low. WPBakery does not have a built-in safe mode, so the official method is manual conflict isolation: deactivate all your other plugins and confirm the editor loads, then reactivate them one at a time until it breaks again, which names the culprit. At the same time, make sure WordPress and WPBakery are up to date and that your memory limit meets WPBakery’s 256MB minimum.
Why is my page showing raw shortcodes like [vc_row] as text on the front end?
This is the signature WPBakery front-end failure, and it means the shortcodes your page is built from are not being processed into HTML, so WordPress prints them as plain text. The most common cause is that the WPBakery plugin is inactive or missing, which happens a lot when WPBakery came bundled with your theme and the theme or plugin was deactivated or not reinstalled after a change. Other causes are the post type not being enabled in WPBakery then Role Manager, the CSS and JavaScript options being turned off in WPBakery then General Settings, or a caching layer serving an old copy. Confirm the plugin is active, enable the post type in Role Manager, enable CSS and JavaScript in the settings, and clear every cache. Once the shortcodes are being processed again, the design renders instead of the raw text.
Why will WPBakery not save my changes, or why do elements reset when I save?
When a complex WPBakery page saves partially, loses rows, or resets elements, the usual cause is the PHP max_input_vars limit. WPBakery builds a page from many nested shortcodes and their settings, and each one becomes a separate input in the save request. PHP’s max_input_vars defaults to 1000, and a big page can submit more fields than that, at which point PHP silently truncates the extras and the missing settings revert on save. The fix is to raise max_input_vars, commonly to 3000 or higher, in your php.ini, or through .htaccess or wp-config.php if you cannot edit php.ini, and to make sure the memory limit meets WPBakery’s 256MB minimum. A firewall or security rule blocking the save, or a plugin conflict, can also break saving, so isolate those if raising the limits does not resolve it.
What is the WPBakery Role Manager and when do I use it?
The Role Manager, under WordPress Dashboard then WPBakery Page Builder then Role Manager, controls which user roles can use WPBakery and, importantly, which post types it is enabled on. It is the fix for two common problems. If WPBakery is not available on your posts or a custom post type, or the Backend Editor button is missing there, you set Post Types to Custom and tick the post types you want to build with. And if your content is rendering as raw shortcodes on the front end, a post type disabled in Role Manager is one of the first things to check, because a page built with WPBakery on a post type that is not enabled will not have its shortcodes processed. It is one of the most useful and most overlooked panels in WPBakery.
What does "this page can not be edited with WPBakery since it is missing a WordPress default content area" mean?
It means the page template your theme is using does not include the standard WordPress content area, the the_content function, which WPBakery needs as the place to render the builder into. Some themes and some custom or third-party templates replace the default template and leave out that function, and without it WPBakery has nowhere to build. The fix is to use a template that includes the content area, switch to the default template for that page, or, if you or your developer built a custom template, add the the_content function to it. Once the template exposes the content area again, WPBakery can edit the page normally.
Why can I not use WPBakery on my posts or custom post types?
By default WPBakery is enabled on pages, and if you want to build posts or a custom post type with it you have to enable those post types explicitly. Go to WordPress Dashboard then WPBakery Page Builder then Role Manager, set Post Types to Custom, and tick every post type where you want the builder available, including posts and any custom post types your theme or plugins register. Save, and the Backend and Frontend Editor buttons appear on those post types. If a post type is missing from the list entirely, it may not be registered with the settings WPBakery needs, which is a theme or plugin configuration to check.
I get "the package could not be installed, no valid plugins were found" when installing WPBakery. Why?
That WordPress error means the file you uploaded is not a valid standalone plugin zip. It almost always happens because WPBakery Page Builder came bundled with a premium theme, and a bundled copy is installed and updated through the theme, not as a separate purchase you download from WPBakery and upload yourself. If your theme bundles WPBakery, install and update it from the theme’s own plugin prompt or included-plugins screen, not by uploading a zip. If you bought WPBakery directly, download the correct plugin zip from your account, since the file from a marketplace download bundle is sometimes the whole package rather than the plugin itself.
What server resources does WPBakery need?
WPBakery Page Builder requires PHP 7.4 or higher, MySQL 8.0 or higher or MariaDB 10.4 or higher, and a memory limit of at least 256MB. For installation the upload_max_filesize should be greater than 7MB, and it needs the Zip, cURL, Exif, and GD PHP extensions. Beyond those published minimums, the setting that most often causes trouble on complex pages is PHP max_input_vars, which defaults to 1000 and should be raised to 3000 or higher so large pages save without losing fields. A builder that will not load or save on a site that otherwise works is very often just under these limits, so raising memory and max_input_vars resolves a large share of WPBakery problems.
Are WPBakery Page Builder and Visual Composer the same thing?
They share a history but are now two different products, and the confusion causes real support headaches. What is today called WPBakery Page Builder is the long-standing plugin, known in code as js_composer, that ships bundled with a huge number of premium themes and uses shortcodes like vc_row and vc_column. Visual Composer is a separate, newer website builder from the same original creators that was split off and rebuilt, sold on its own. They are not interchangeable, their settings and elements differ, and a fix for one may not apply to the other. This page is about WPBakery Page Builder, the js_composer plugin, which is the one most people mean when a theme they bought came with the builder included.
Is a WPBakery problem the same as the WordPress white screen of death?
No, and telling them apart saves time. A WPBakery problem is usually confined to the builder or a page’s rendering: the rest of your site works, and only the editor hangs, a save fails, or one page shows raw shortcodes. The white screen of death is a whole-site failure, a blank page or a There has been a critical error message on the front end, caused by a PHP fatal error rather than anything specific to WPBakery. If your live pages are down for everyone, that is the critical error to diagnose through the debug log, which we cover on the white screen page. If your live pages are fine and only the builder or one page misbehaves, you are in the right place. They overlap only when a fatal fires inside WPBakery code, but the starting question is always whether the public site works.
Sources and further reading
Every technical claim on this page traces back to the WPBakery Page Builder knowledge base, or to documented PHP behavior for the max_input_vars limit.