Possible Full Width Row rendering issue with WPBakery 8.7.3

Hello,

I am reporting this issue because I am currently trying to determine whether it originates from WPBakery, from the Bridge theme, or from an incompatibility between both products.

I have already submitted the same technical findings to the Bridge theme authors (Qode Interactive) so that both development teams can review the same reproducible test case.

My objective is not to assign responsibility to either product but simply to identify the root cause.

Background

I manage a production website built with Bridge and WPBakery.

Recently I noticed that rows configured as Full Width no longer span the full browser width and instead remain constrained to the site’s content grid.

Initially I suspected existing content, images, custom CSS or page-specific configuration issues.

To rule those out, I performed a series of tests and ultimately reproduced the problem with a completely new empty row.

Environment

• WordPress: latest version
• PHP: latest supported version
• WPBakery: 8.7.3
• Bridge Theme: 30.8.8.9
• Bridge Core: 3.3.4.8

All plugins, WordPress core, theme components and PHP are fully updated.

Issue

Rows configured as:

Row Type = Row
Use Row as Full Screen Section = No
Type = Full Width

are no longer rendered as full-width sections.

Instead, they remain constrained to the content grid width (~1300px).

Minimal reproducible example

To eliminate any influence from existing content, layout or images, I created a completely new empty row:

[vc_row
row_type="row" 
use_row_as_full_screen_section="no" 
type="full_width" 
background_color="#81D742" 
css=".vc_custom_test{padding-top:50px!important;padding-bottom:50px!important;}" 
]
[vc_column][/vc_column]
[/vc_row]

The row contains only:

• A green background color
• 50px top padding
• 50px bottom padding
• No content

Expected result:

• The green background spans the full browser width.

Actual result:

• The green background remains limited to the site’s content grid width.

Generated HTML

<div class="vc_row wpb_row section vc_row-fluid">
    <div class="full_section_inner clearfix">

The row remains rendered inside:

<div class="container_inner default_template_holder clearfix page_container_inner">
    <div class="wpb-content-wrapper">

and does not extend beyond the content grid.

Measurements

jQuery(window).width()
= 1905

jQuery('.container_inner').width()
= 1300

Rows configured as Full Width render at approximately 1300-1330px instead of matching the viewport width.

Diagnostic steps already performed

• Browser cache cleared
• WordPress cache cleared
• No JavaScript errors found in browser console
• Theme options re-saved
• Bridge options re-saved
• Issue reproduced with a completely new empty row
• Issue affects both existing and newly created rows

Interesting finding

Applying the following CSS immediately restores the expected behavior:

.vc_row.section{
    width:100vw!important;
    margin-left:calc(50% - 50vw)!important;
}

After applying this CSS, rows span the entire browser width correctly.

This suggests that the mechanism responsible for stretching Full Width rows is not being applied.

Question

Has the behavior of Full Width rows changed in WPBakery 8.7.3?

Is there any known compatibility issue or recent modification regarding Full Width row rendering that could explain this behavior?

Thank you for any feedback or guidance you can provide.

Hello. Is the old purchase license no longer valid?

The release date on the changelog for 8.7.4 is incorrect – https://kb.wpbakery.com/docs/preface/release-notes/

When will 9.0 be released? thanks

Hi, Could this plugin able to turn a wordpress website into something similar to shopify where users can create and design their website or is this only for wordpress admin to design its native webpages? If so, could the user side has its own menu rather using wp default panels?

Hello, in WPB 9 beta, blocks/rows/columns inside accordion, tabs, or tours can not be dragged in the backend. In the frontend, it is working as usual. Is it only me?.

Hi, WPB comes prepacked in my theme and just saw a notice about version 9 beta is it possible to get access to it from themes that have it included?

Hi there, Referring to the post by “Relevant-AS” above, is there a way to hide the YouTube player controls and title that briefly appear before disappearing on a background video? Can you help with that? Many thanks Best

Hello WPBakery Team,

I would like to report an issue we are seeing on multiple WordPress websites that use WPBakery Page Builder.

We first found the issue on a site using a ThemeREX/TRX Addons theme, but we are now seeing the same type of wp_user_roles trigger on other websites as well, including websites using different themes. So this does not appear to be limited to one specific theme.

The issue is that WPBakery can repeatedly rewrite the WordPress wp_user_roles option in the wp_options table when vc_editor_set_post_types() is called.

From our logs, the chain looks like this:

vc_editor_set_post_types() → vc_manager()->setEditorPostTypes() → Vc_Manager->setEditorPostTypes() → Vc_Role_Access_Controller → WP_Role->add_cap() / WP_Role->remove_cap() → update_option(‘wp_user_roles’)

On busy WooCommerce websites this can create a lot of unnecessary database write activity, especially when it is triggered during frontend requests, AJAX requests, cron/loopback requests, backup/export processes or crawler traffic.

We have seen thousands of wp_user_roles update attempts in a short time. In some cases, actual SQL writes to wp_options still happen. The option is large and serialized, so repeatedly rewriting it creates unnecessary database load and performance overhead.

I understand that third-party themes or plugins can trigger this by calling vc_editor_set_post_types(). However, it seems risky that WPBakery then performs a full role/capability sync without stronger internal safeguards.

Could you please confirm:

Is it expected that vc_editor_set_post_types() can rewrite wp_user_roles every time it is called? Is this behavior already known? Is there a WPBakery version where this has been patched or improved? Can WPBakery make this process more defensive, so roles are not rewritten when nothing actually changed? Can WPBakery prevent role updates when there is no real logged-in admin user, for example when get_current_user_id() === 0? Is there a safer recommended method for themes/plugins to add post types to WPBakery without triggering a full role/capability rewrite?

In my opinion, WPBakery should only update role capabilities when it is really necessary, and preferably only in a valid admin/editor/settings context. It should not be possible for frontend requests, AJAX, cron, loopback, REST, backup/export or bot traffic to trigger repeated wp_user_roles writes.

For now, we are using a custom MU-plugin guard to block unnecessary wp_user_roles updates outside valid admin contexts, but we would prefer to solve this properly at the source.

Can you let us know if this is something you can patch or if there is already an official fix?

Kind regards, Timothy

Question: Is the version 8.7.3 compatible with Wordpress 7.0 ? If not – when is ETA of an update with WP 7 compatibility? Thanks a lot.

Hi WPBakery team,

We’re experiencing a reproducible layout crash with the Masonry Media Grid element when a grid contains 45 or more images and the user scrolls through “load more” items at normal speed.

The issue: The grid crashes partway through loading additional items, the layout collapses and only a portion of the items are rendered (sometimes as little as the first 1/5). It does not happen every single page load, which suggests a race condition between image loading and the masonry layout recalculation. The problem becomes more frequent and severe the more images are present (most reliably reproduced at 50 images).

Video demonstrating the crash: https://d.pr/v/jJiPSB

WPBakery page content (shortcodes) from the affected page: https://d.pr/n/xKOmlW

Fix we attempted (did not resolve the issue): We added the following JavaScript as a workaround, which listens for the grid:items:added event and waits for images to fully load before triggering a masonry relayout, with a second pass 150ms later:

( function ( $ ) {
    'use strict';

    $( window ).on( 'grid:items:added', function( e, $gridEl ) {
        var grid, builder, $content;

        if ( ! $gridEl || ! $gridEl.length ) {
            return;
        }

        grid = $gridEl
            .closest( '.vc_grid-container' )
            .find( '[data-vc-grid-settings]' )
            .data( 'vcGrid' );

        if ( ! grid || ! grid.gridBuilder ) {
            return;
        }

        builder  = grid.gridBuilder;
        $content = builder.$content;

        if ( ! $content || ! $content.data( 'masonry' ) ) {
            return;
        }

        $content.imagesLoaded( function() {
            $content.masonry( 'reloadItems' ).masonry( 'layout' );
            setTimeout( function() {
                $content.masonry( 'layout' );
            }, 150 );
        } );
    } );
} ( jQuery ) );

This did not fully resolve the issue, the crash still occurs on the first “load more” trigger.

Question: Could you please advise on the correct way to handle masonry relayout after load more items are injected in the Masonry Media Grid element, specifically when the grid contains a large number of images (45+)? Is there a supported event or API method we should be using to ensure the layout recalculates only after all newly loaded images are fully rendered?

Thank you.

Hi, We are experiencing an issue with YouTube background videos in WPBakery Page Builder.

When a YouTube video is used as a row background, the video controls (play/pause, next, etc.) briefly appear on page load before disappearing. This did not happen before and started after a recent.

We have tested this on a clean setup using the default Storefront theme with only WPBakery active, and the issue still occurs. This confirms it is related to any theme.

Expected behavior is that background videos load without showing any player controls at any time.

Currently, the YouTube iframe seems to load with controls visible for a short moment before they are hidden, which creates a flashing effect and looks unprofessional on live sites.

This is affecting multiple websites and impacts the frontend experience.

Could you please confirm:

- if this is a known issue or recent change - if there is a fix or workaround available

Ideally, the video should be initialized in a way that prevents controls from being visible at all during load.

Thanks in advance.

Hi, we noticed a bug with the WPBakery Frontend Editor when editing pages that use an Arabic slug.
Steps to reproduce:
1. Create a page with an Arabic slug, for example:
 https://undsgn.d.pr/i/UypZ1U
2. Open the page with the WPBakery Frontend Editor and save it:
 https://undsgn.d.pr/i/EKbD62
3. After saving, the original Arabic slug is changed into a string of western letters and numbers:
 https://undsgn.d.pr/i/TVqBYz
This only happens after saving through the Frontend Editor. The original Arabic slug should be preserved.
Could you please check this?
Thanks

Hi,

There is a compatible issue with Slider Revolution v7.0.8. When editing a page, it shows some warnings:

Deprecated: Function getArrSliders is deprecated since version 7.0.0! Use get_sliders instead

Deprecated: Function getTitle is deprecated since version 7.0.0! Use get_title instead

Deprecated: Function getAlias is deprecated since version 7.0.0! Use get_alias instead

You should check the file \js_composer\include\classes\vendors\plugins\class-vc-vendor-revslider.php. Also in that file, you should not call the RevSlider class. It may be deprecated in future.

Best regards,

Hi, I am experiencing a recurring PHP Warning in my error logs related to WPBakery Page Builder (js_composer) specifically on my WooCommerce Cart and Checkout pages.

The error is: PHP Warning: Attempt to read property “post_title” on null in …/wp-content/plugins/js_composer/include/helpers/helpers.php on line 615

Context:

The Cart and Checkout pages are correctly assigned in WooCommerce settings.

These pages are built using the standard WordPress Block Editor (Gutenberg), but WPBakery is active on the site.

It seems helpers.php at line 615 is trying to access the $post object before it is fully initialized or while it’s null on these specific dynamic pages.

My support license is currently expired, but I am willing to renew it immediately if your team can confirm that this issue is solvable or if you can provide a specific fix/patch for this compatibility conflict. I want to ensure my site remains stable before proceeding with the renewal.

i can’t update the plugin on the site, i have a message telling i must activate WPBakery Page Builder license while the license is activated and added in your site here https://support.wpbakery.com/licenses

Using code like this correctly works:

add_filter( 'vc_css_editor_border_radius_options_data', function( $data ) {
    $data['var(--rounded-xl)'] = 'Extra Large';
    return $data;
} );

Can you let me know if this is ok to use or should the extra border radius options be restricted to pixels?

I just want to ensure if I use something like this it won’t break in the future or cause any issues currently (seems to be fine).

Thank you!!

WPBakery contains sprintf strings with incorrect placeholders. Please fix.

Here are the four window.sprintf() calls and their format strings:

Call site     |  Format string    | Argument
-------
checks.js:356 | textLengthSuccess | "The text contains %s words. Good job!"    textLength (number)
-------
checks.js:379 | passiveVoiceError    | "%s of the sentences contain passive voice, which is more than the recommended maximum of 10%"    percentage + '%' (e.g. "25%")
-------
checks.js:414 | paragraphLengthError | "%s of the paragraphs contains more than the recommended maximum of 150 words."    longParagraphsCount
-------
checks.js:440 | sentenceLengthError | "%s%% of the sentences contain more than 20 words, which is more than the recommended maximum of 25%."    longSentencePercentage.toFixed()

The passiveVoiceError string is the main culprit. It ends with ...maximum of 10% — that trailing % with no format specifier after it is what triggers [sprintf] unexpected placeholder. The sprintf parser sees % and tries to parse a placeholder but finds nothing valid after it.

The sentenceLengthError has the same problem: ...maximum of 25%. — the % before the period is also an unescaped literal percent.

In PHP, %% produces a literal %. WPBakery correctly used %s%% at the start but forgot to escape the trailing % characters. A classic bug.

Hello, just a deprecation notice, FYI (running on 8.7.2 and latest WP 6.9, on PHP 8.4):

[25-Jan-2026 09:48:30 UTC] PHP Deprecated (trace): ltrim(): Passing null to parameter #1 ($string) of type string is deprecated in /wp-includes/formatting.php:4496 #0 /wp-includes/formatting.php:4496 ltrim() #1 /wp-content/plugins/js_composer/include/templates/editors/popups/partials/element_teasers.tpl.php:32 esc_url() #2 /wp-content/plugins/js_composer/include/helpers/helpers.php:82 require() #3 /wp-content/plugins/js_composer/include/templates/editors/popups/vc_ui-panel-add-element.tpl.php:60 vc_include_template() #4 /wp-content/plugins/js_composer/include/helpers/helpers.php:82 require() #5 /wp-content/plugins/js_composer/include/classes/editors/popups/class-vc-add-element-box.php:251 vc_include_template() #6 /wp-content/plugins/js_composer/include/templates/editors/partials/footer.tpl.php:16 Vc_Add_Element_Box->render() #7 /wp-content/plugins/js_composer/include/helpers/helpers.php:82 require() #8 /wp-content/plugins/js_composer/include/templates/editors/partials/backend_editor_footer.tpl.php:14 vc_include_template() #9 /wp-content/plugins/js_composer/include/helpers/helpers.php:82 require() #10 /wp-content/plugins/js_composer/include/classes/editors/class-vc-backend-editor.php:199 vc_include_template() #11 /wp-includes/class-wp-hook.php:341 Vc_Backend_Editor->renderEditorFooter() #12 /wp-includes/class-wp-hook.php:365 WP_Hook->apply_filters() #13 /wp-includes/plugin.php:522 WP_Hook->do_action() #14 /wp-admin/admin-footer.php:78 do_action() #15 /wp-admin/post.php:369 require_once()

And this warning also:

[25-Jan-2026 09:48:30 UTC] PHP Warning: Trying to access array offset on true in /wp-content/plugins/js_composer/include/templates/editors/popups/partials/element_teasers.tpl.php on line 32

Regards!

Hi. Wordfence recently reported this regarding WPBakery. Obviously nothing serious, but still thought you folks would like to know that Wordfence considers this an “issue”. [Dec 07 04:42:20:1765078940.562720:3:error] Unable to determine version for plugin js_composer