Get contextual feedback on your published Beaver Builder page

Q: What does Publish do?

Publish makes the changes live and publicly accessible when the WordPress site itself is public.

Q: When does Beaver Builder create a WordPress revision?

Publishing creates a revision. Beaver Builder notes that the WordPress Revisions feature applies to published changes, not saved drafts.

Q: What can Discard remove?

It can remove all saved but unpublished changes made since the page was last published, including work from earlier editing sessions.

Q: What are the default Beaver Builder breakpoints?

The documented defaults are Large at 1200px, Medium at 992px, and Small at 768px. Widths above 1200px use the Extra Large device size, and the values can be changed.

Q: Does Beaver Builder use a desktop-first responsive model?

Yes. Its documentation describes starting at desktop or Extra Large and working down to smaller devices with max-width media queries.

Q: Do reviewers need Beaver Builder access?

No. They can review a browser-accessible published frontend. WordPress roles and Beaver Builder access settings remain with people who need to edit.

Paste the browser-accessible WordPress frontend URL, send one review link, and collect comments on the page visitors will actually see.

See how it works

Loved by1,250+Agenciesand companies in 100+ countries

Beaver Builder drafts, published pages, and editor access are separate.

Beaver Builder provides its own editing and publishing workflow inside WordPress. BugSmash reviews the browser-accessible frontend selected for stakeholder review.

Four documented boundaries matter before sharing a page:

Save Draft does not change the published page.
Save Draft exits the builder and keeps the session's changes visible only while editing in Beaver Builder.
Publish makes changes live.
Beaver Builder documents Publish as making changes live and accessible to the world when the site itself is public.
Only publishing creates a restorable revision.
The WordPress Revisions workflow applies to published changes, not saved drafts. Discard can remove all saved, unpublished work since the last publish.
Builder access is controlled by WordPress roles.
Beaver Builder access settings can grant unrestricted editing, apply granular restrictions, or prevent selected roles from opening the builder.

BugSmash keeps review on the rendered frontend:

share the published page, keep WordPress and builder permissions with the site team, and, when the script is installed on the rendered frontend, use the Feedback Widget for an authenticated state that a pasted URL cannot open.

How it works

Three steps to a reviewed Beaver Builder page

Publish the intended review state

Finish the builder edits and use Publish when the changes should appear on the public WordPress frontend and create a WordPress revision.

Send one review link

Paste the published frontend URL into BugSmash. Reviewers can comment on the rendered page without receiving WordPress or Beaver Builder access.

Resolve feedback and publish again

Use the attached page, screenshot, browser, operating system, and viewport context to update the layout and publish the next review state.

Review the Beaver Builder frontend without opening the builder

Comment on the published page

Attach feedback to the visible frontend instead of describing a row, column, or module in a separate message.

Compare responsive layouts

Review browser widths alongside Beaver Builder's Extra Large, Large, Medium, and Small responsive editing views.

Capture technical context

Keep the page URL, screenshot, browser, operating system, and viewport size with each comment.

Separate review from permissions

Let stakeholders review the frontend without changing WordPress roles or Beaver Builder access settings.

Keep revision rounds clear

Publish an intentional state for review so the WordPress revision and the frontend being discussed stay aligned.

Use the widget for gated pages

When the rendered frontend permits the BugSmash script to be installed, use the Feedback Widget inside a session reviewers are already authorized to use.

Which Beaver Builder URL should I review?

Choose the frontend URL representing the state stakeholders should see. Builder access and frontend access are separate decisions.

Your URL	Review by URL	What to do
Public published Beaver Builder page	Works	Paste the visitor-facing WordPress URL and start the review.
Public WordPress staging frontend	Works	Use the staging URL after confirming reviewers can reach it and it contains the intended published state.
Site protected by supported Basic Auth	Works	Use the accessible Basic Auth URL; BugSmash lists Basic Auth-protected websites as supported.
Saved Beaver Builder draft	Not published	Publish the intended changes to an accessible frontend before asking external reviewers to assess them.
Frontend behind login or SSO	Use the Widget	Pasting a URL does not bypass application login or SSO. If the script can be installed on the rendered frontend, use the Feedback Widget inside the authenticated session.
Beaver Builder or WP Admin URL	Not the review surface	Share the rendered frontend instead of granting builder access for visual feedback.

Installing the Feedback Widget on a Beaver Builder site

Where the WordPress frontend permits the BugSmash script to be installed, use it when authorized reviewers must stay inside a logged-in or stateful experience. Existing WordPress access still determines which pages they can open.