Brizy Editor Unable to Save or Update After Editing Global Section
Hi Brizy Support,
I'm experiencing an issue with the Brizy editor on our WordPress website and would appreciate your assistance in identifying and resolving the cause.
Website: Acro Accounting & Financial Planning
Affected page: Tax Accountant Services Brisbane
Page URL: https://acroaccounting.au/tax-accountant-services-brisbane/
Issue Summary
Initially, I was able to edit the page normally in Brizy. I made multiple changes to regular sections and was able to save and update the page successfully without any issues.
The problem first occurred when I edited an existing Global Section. After making changes to that Global Section, Brizy produced an error when I attempted to update/save the page.
To determine whether the problem was specific to that particular Global Section, I then:
- Created a completely new block/section.
- Confirmed that I could work with the new block.
- Set the new block as a Global Section.
- Attempted to save/update it.
- The same save/update problem occurred.
After performing this test, the issue became more severe.
I am now unable to save or update edits made even to ordinary, non-global sections on the page.
The sequence was therefore:
Normal Brizy editing and saving worked correctly
→ Edited an existing Global Section
→ Save/update error started
→ Created a new block and converted it to Global
→ Same problem occurred
→ Brizy now fails to save changes even to regular non-global sections
This makes me suspect that the issue may be related to Brizy Global Sections/Global Blocks, their database records, the editor save request, or something triggered when a block is converted to Global, rather than the content of an individual normal section.
Troubleshooting Already Performed
I have already cleared the relevant website caches, including:
- SiteGround Optimizer cache
- WP Rocket cache
- Cloudflare cache
The problem persists within the Brizy editor.
The live website remains accessible and the previously published changes are displaying correctly. The issue is specifically preventing me from reliably saving further edits through Brizy.
What I Would Like Brizy Support to Investigate
Could you please check:
- Whether there is an error associated with the affected Global Section or Brizy Global Blocks
- Whether a corrupted or stuck Global Section record could be preventing subsequent page updates
- Whether the Brizy save/update request is failing at the REST API, AJAX or server level
- Relevant PHP/server errors associated with the failed save requests
- Whether there are browser console or JavaScript errors associated with the Brizy editor
- Whether the page or Global Block data has become corrupted
- Whether converting the test block to Global triggered a wider editor/save issue
- Whether this is a known issue with the currently installed Brizy/Brizy Pro version
- Whether the affected Global Section can be repaired without losing the existing page content or design
Please let me know if you require any additional information, screenshots, browser console output or server details.
Thank you for your assistance.
-
Hi Ardy,
To help us investigate this issue, could you please provide temporary access to your WordPress admin dashboard? This will allow us to take a closer look at your setup and identify the cause of the issue.
Kindly send the following details to communitysupport@brizy.io:
- Support Forum Post: https://support.brizy.io/hc/en-us/community/posts/38434050882706
- WordPress Admin URL:
- Username:
- Password:
We’ll review it as soon as we receive the access.
Best regards,
Ariel H.0 -
Hi Ardy,
Upon checking, we found that the WordPress Administrator account has lost the required access to save the headers, which is why it is returning an Error 403 in the browser console. This issue was likely caused by the site migration from staging to production.
To correct this, you can change or set the current Administrator role to Editor, then grant the user Full Access through Brizy’s Role Manager. This process is demonstrated in this screencast:
We also created a second temporary Administrator account so we could update the brizy_tech user account to Editor, since a user cannot change its own role while logged into the same account.
Feel free to test the setup and delete the temporary Administrator credentials afterward if they are no longer needed.
If you have any further questions or need any assistance, please let us know.
Best regards,
Ariel H.0 -
Awesome!!
Thank you so much, Ariel!
Everything is now working fine regarding the issue.
My client hired a 3rd party marketing specialist who made some edits in the website and it somehow messed up some features.
I have other concern though, kindly refer to the below info:Issue
The main navigation menu displays correctly, but the submenu dropdowns sometimes fail to appear or function, particularly when viewing the website as a logged-out visitor or in incognito mode.
During previous troubleshooting, we found that disabling certain caching/optimisation settings restored the submenu functionality.
In particular, WP Rocket's Optimise CSS Delivery / Remove Unused CSS appeared to affect the Brizy header and navigation. Disabling this feature helped restore the dropdown menus.
We have therefore tried to avoid overlapping CSS and JavaScript optimisation between WP Rocket and SiteGround Speed Optimizer.
The concern is that the website may appear and function correctly while logged into WordPress, but cached versions served to normal visitors can experience problems with the Brizy submenu dropdowns.
Current Optimisation Setup
We have deliberately limited SiteGround Speed Optimizer's CSS and JavaScript optimisation because WP Rocket is also installed.
WP Rocket's more aggressive CSS optimisation, particularly Remove Unused CSS / Optimise CSS Delivery, has also been disabled because of the submenu issue.
Request for Brizy Support
Could you please investigate whether Brizy navigation dropdowns have any known compatibility issues with WP Rocket or SiteGround Speed Optimizer?
In particular, could you advise:
- Whether Brizy requires specific CSS or JavaScript files to be excluded from WP Rocket optimisation.
- Whether any Brizy scripts should be excluded from JavaScript defer, delay, minification or other optimisation.
- Whether Brizy-generated CSS should be excluded from Remove Unused CSS processing.
- Whether caching can cause the dropdown functionality to work for logged-in users but fail for logged-out/incognito visitors.
- What caching and optimisation configuration Brizy recommends when using WP Rocket together with SiteGround Speed Optimizer.
Our goal is to retain website caching and performance optimisation without risking the Brizy submenu dropdowns becoming unavailable to website visitors.
We would appreciate Brizy's recommended configuration or exclusion rules so we can resolve this permanently rather than simply disabling optimisation features.
Regards,
Ardy0 -
Hi Ardy,
Please add the following Brizy JS and CSS files to the exclusion list in WP Rocket or the asset optimization settings and see if this fixes the issue.
JavaScript Exclusions:
/wp-content/plugins/brizy/public/editor-build/prod/editor/js/main.base.min.js
/wp-content/plugins/brizy-pro/public/editor-build/prod/js/main.base.pro.min.jsCSS Exclusion:
/wp-content/plugins/brizy/public/editor-build/prod/editor/css/preview.cssBest regards,
Ariel H.0 -
Hi Ariel,
I’ve adjusted the WP Rocket settings based on your recommendation, and everything is functioning properly now. I’ll continue monitoring to ensure the current frontend experience remains stable and will check later to see if the issue reoccurs.
Best,
Ardy0
Please sign in to leave a comment.
Comments
5 comments