WPBakery rows are the building blocks of any page layout, containing columns and elements that structure the content. Designers often spend significant time configuring row settings like background colors, margins, paddings, and parallax effects. However, sometimes these row settings do not save properly, and after saving the page, the row reverts to its default settings, losing all the custom configuration that was carefully applied.
This problem can be incredibly frustrating because the settings appear to save correctly during editing, and no error message appears to indicate a problem. The page may look perfect in the editor, but when viewed on the frontend or reopened in the editor, the row settings have reverted to their default values. This issue can affect specific rows on a page or all rows across the entire website, and it often appears after updating WordPress, WPBakery, or other plugins.
The most common cause of this problem is that the WordPress database is not saving the row settings correctly due to corrupted post meta data. Another cause is that a security plugin is blocking the AJAX request that saves the row settings, or that the PHP memory limit is too low to process the save operation. Plugin conflicts can also interfere with the saving process by modifying the data before it reaches the database.
Why WPBakery row settings fail to save
WPBakery stores row settings as serialized data in the WordPress post meta table under the meta key “_wpb_shortcodes_custom_css” or similar keys. When the page is saved, WPBakery collects all row, column, and element settings, serializes them into a string, and saves them to the database. If any part of this process fails, the row settings will revert to their previous values or default settings. Serialization errors are particularly common when the page contains special characters or when the data size exceeds certain limits.
Security plugins that implement nonce verification or CSRF protection can sometimes block the AJAX request that saves row settings. The request may be sent successfully, but the security plugin intercepts it and returns an error because the nonce has expired or is invalid. This is especially common on websites where the admin session timeout is set to a very short duration. Increasing the session timeout or whitelisting WPBakery AJAX requests usually resolves this issue.
Another common cause is that the PHP max_input_vars limit is too low to process all the row settings on a complex page. When a page contains many rows, columns, and elements, the number of input variables sent during save can exceed the PHP limit, causing some data to be dropped silently. Increasing the max_input_vars limit to 3000 or higher allows all settings to be processed correctly. This limit is often set to 1000 by default, which may be insufficient for complex pages.
How to check if row settings are being saved to the database
Edit a page in WPBakery, make a change to a row setting, and save the page. Then, use a plugin like Custom Fields Suite or phpMyAdmin to inspect the post meta for that page. Look for the meta keys that WPBakery uses to store row settings, such as “_wpb_shortcodes_custom_css” or “_wpb_vc_js_status”. Check the values of these meta fields to see if they contain the row settings you configured. If the meta fields are empty or contain default values, the settings were not saved correctly.
Step by step guide to fixing WPBakery row settings problems
Follow these steps in order to ensure WPBakery row settings save correctly. Start with the simplest solutions before moving to more advanced troubleshooting steps.
- Increase PHP max_input_vars to 3000 by adding a line to the .htaccess file or php.ini
- Increase PHP memory limit to 512MB in the wp-config.php configuration file
- Disable all security plugins temporarily to test if they block saving operations
- Clear all caches including plugin cache, CDN cache, and browser cache completely
- Check the database for corruption using the WordPress database repair tool
- Temporarily deactivate all other plugins to test for conflicts with saving
- Switch to a default WordPress theme to test if the theme interferes with saving
- Update WPBakery to the latest version available from the official website
- Use the WPBakery built-in reset function to clear corrupted shortcode data
- Contact WPBakery support with specific details about which row settings are not saving
How to increase PHP max_input_vars for WPBakery
Add this line to the .htaccess file in the root WordPress directory to increase the max_input_vars limit. If your server does not use .htaccess, add the line to the php.ini file instead. After making the change, restart the web server and test if row settings save correctly. You can verify the new limit by creating a simple PHP info file or using a plugin like WP Server Health Check.
php_value max_input_vars 3000
WPBakery row settings troubleshooting reference table
Here is a reference table for diagnosing row settings problems in WPBakery based on specific symptoms you might encounter.
| Symptom | Most likely cause | Recommended solution | Row settings revert to default after saving | Database not saving serialized data correctly | Check post meta table and repair database | Settings appear saved but frontend shows old values | Caching plugin serving old version of the page | Clear all caches and exclude page from caching | Some row settings save, others do not | PHP max_input_vars limit exceeded | Increase max_input_vars to 3000 or higher | Settings work in backend editor but not in frontend editor | AJAX request blocked or nonce expired | Check security plugin settings and session timeout |
|---|
For more information about WPBakery row settings, visit the WPBakery page on wpwizzy.com.
Preventing WPBakery row settings problems in the future
Increase PHP max_input_vars to 3000 or higher during initial server setup to prevent issues with complex pages. Regularly check the database for corruption and optimize tables to ensure smooth saving operations. Clear all caches immediately after making changes to row settings, and test the frontend after every save to verify that settings were applied correctly.
Keep WPBakery and all other plugins updated to their latest versions on a regular schedule, and use a staging website to test major changes before applying them to the live production site. Document any custom PHP settings added for WPBakery for future reference, and consider breaking very complex pages into multiple smaller pages to reduce the number of settings saved at once.