I started to work in Bricks recenly and there’s a thing which is quite annoying, when using Classic editor.
Even though the page is made with Bricks, when I open it in WP dashboard (aka Classic Editor), the irrelevant WP content is shown. I would expect, that when the page is made with Bricks I would see only the “Edit with Bricks” button, or at least, I would land on the Bricks tab. Instead I’m constantly directed to the Text tab. Probably because the system is trying to remember the last tab visited (which was Bricks), but somehow it cannot manage to target it, so I it ends up on the Text tab.
IMHO, it would be much better to hide all the WP native tabs, when on Bricks page, the same way, how it’s done with the Templates (or in Elementor). The content in the WP native tabs is irrelevant, and editing it doesn’t have any effect. It causes only confusion.
Just to answer in advance the question likely to come - why to edit the Bricks page in th WP dashboard? Well, I have there some extra ACF fields, to add tags or featured tmages etc…
And one more thing - the system constantly hides the additional second row of the TinyMCE toolbar, it’s really annoying to click it again and again. I’m using TinyMCE Advanced (now called Advanced Editor Tools), but the behaviour is same even without it activated.
Hi @Blackeye, I’m not sure it would be a great idea to just hide all the WP native tabs on regular pages & posts as many rely on them to add content there and it’s a bit intrusive imo. It makes sense for templates as it’s specifically for Bricks though.
As for the TinyMCE toolbar issue, can you please create a separate report for this with a screen recording of the issue so we can try & replicate it and track it?
Well as I wrote, hiding the tabs wouldn’t be necessary, if I was at least directed to the corresponding tab - which in the case of Bricks page is the Bricks tab. Instead, I’m constatly redirected to one of the WP tabs, showing me the irrelevant content, which (even if I can edit it) doesn’t have any impact on what’s shown on the front end.
Here is the screencast of the typical page editing workflow: Jam
Maybe I’m doing something wrog, but IMHO, this is far from the good user experience. Mainly because:
It’s not obvious which editor was the page made in (WP Classic or Bricks). Moreover, the native WP tab gives the impression the page is made in Classic WP.
As the page is opened on the WP tab, it suggests me to start editing it there. But when I check out the page on the font end, it doesn’t have any effect.
Even when I select the Bricks tab, after every update, I’m back to the Text tab.
Same with going right from the the Bricks editor to the WP dashboard - Text tab again.
There’s not a single reason, why the WP tabs should be shown, if they doesn’t have any effect on the front end. It only confuses the user.
I think it should be done similarly to Elementor: when the page is in the builder mode, WP tabs are not shown and vice versa. You can switch between these two modes.
I brought this up internally for feedback and this is more of an improvement/feature request than a bug. Especially given that you could have both WordPress & Bricks as a content source for your page, I’m not sure if it’s a great idea to only show “Edit with Bricks” on pages built with Bricks. Landing on the Bricks tab might be a good improvement though.
Thanks for considering my suggestions. I agree, showing only Edit with Bricks is more a feature request than a bug.
On the other hand, (not) landing on the Bricks tab still seems to me like a bug, since it seems Bricks is trying to land there, but somehow isn’t able to manage it, hence lands next to it on the HTML tab. Which is really confusing, as the user has no business to do on this tab (because editing it doesn’t have any effect on the front end).
Meanwhile I managed to create a little script I’ve added to the edit page, which switches to the Bricks tab when the page (made with Bricks) is loaded:
function simulateButtonClick() {
var switchButton = document.querySelector(".bricks-editor-active #switch-bricks");
if (switchButton) {
var clickEvent = new MouseEvent("click", {
bubbles: true,
cancelable: true,
view: window
});
switchButton.dispatchEvent(clickEvent);
}
}
window.addEventListener("load", function () {
simulateButtonClick();
});
It seems to work, but could you please chek it wheather is ok and isn’t doing anything nasty? (I suck at JS…)
I have changed the category to “feature request/improvements” for this report and the consensus when I shared this with the team back then was that the current implementation is the intended behavior. We also didn’t get any similar complaints tbh. But it’s great that you found a solution that can work for your desired setup. The code seems to be alright without testing it it shouldn’t cause problems as it’s just waiting for the page to load and then automatically clicks the button for you.
When I was writing the reply, I was new to Bricks and thought, that it works the same way as it’s done in Elementor - it’s one editor or another. In the meantime I realized, I can use WP content in Bricks even on the same page (even though I haven’t done so, yet).
Which, in fact, makes it even more confusing for a non experienced users (like are my usual clients). There should be some more obvious way, how to distinguish what content is in charge, when you cklick on “Edit Page” link. For now it’s in the “try to gues it” realm…
Just encountered this myself being new to Bricks. Went back to a page I was putting together with Bricks and when I edited the page there was just a big empty area, but when I went to click edit with Bricks it was all there. I guess coming from Elementor as well the way Elementor does it is when you save the page it adds some of that builder content to the WordPress main content data so they lock it out, while Bricks keeps the data separate. I think I would prefer a toggle in the Bricks settings so Bricks allowed pages you can specify to lock the content area off with a button to use Bricks.
We are at least three… plus our clients who get confused when they are presented with an empty Guttenberg editor on a page that should be edited in Bricks.
@sly Yep we’re currently working on improving the UX when using the block editor (show a more noticeable notice when the page is built with Bricks). I’ll also bring up this forum thread internally to discuss whether we should implement the same for the classic editor.