Browser: Chrome 110 OS: macOS / Windows / Linux / etc. URL: Link to a page that illustrates this issue Video: Short screen recording that illustrates this issue (free tool: jam.dev)
Hey bricks team,
I just got introduced to bricks. I have to say it’s awesome.
I encountered a problem during the initial review of Custom Authentication Pages…
I and many users always bookmark the WordPress login page in the browser. After the first successful login, if we click on the bookmark again, we will see the custom login form again, while the WP toolbar is visible at the top of the page. Because we are logged in.
In fact, the expected behavior is that if we are logged in, we will not be able to see the Custom Authentication Page and will be automatically redirected to the WordPress dashboard.
Although I partially agree, I wouldn’t count this as a bug since it’s the current expected behavior, so I have moved this to the improvements category.
I agree that there should be an easy way to redirect logged-in users when they visit the custom authentication pages. This is already possible to implement using custom PHP (simply check if the user is logged in and if the current page is a custom authentication page). But it would be great to have a solution that wouldn’t require custom coding nonetheless.
However, I don’t think this should be the default behavior, since you wouldn’t be able to edit or view the custom login page during development. I’ll bring this back to the team to discuss how we may improve this (perhaps through a Bricks setting that allows you to decide what should happen).
You bring up an interesting point. If this affects builder access for the Custom Authentication Page, an edit mode option would be great, which you mentioned.
In fact, this option behaves quite similarly to the Keep open while styling option in offcanvas. If we want to edit the Custom Authentication Page, we enable this option and disable it again when we are done.
A question occurred to me that I wanted to share with you. I should also add that I don’t know how to code and I don’t understand it. My question may be completely wrong. But I hope it’s useful.
We have the same behavior in Password protection, right?
For example, if we apply Password protection to page X, as an admin user, if we want to edit this page, we will not be able to do so and will be faced with a custom Password protection page. Unless we enable the Disable for logged-in users option in the Password protection settings.
But the question is, why doesn’t Password Protection, by default, exempt the site administrator role (or any role with creator access) from that rule so that the site administrator can edit the page? Is there a scenario where the admin role locks access to page content for itself?
Or about this Custom Authentication Page, why is it that when the redirection feature for logged-in users is added, as you mentioned, the site admin role cannot access the Custom Authentication Page in the Builder by default and is redirected?
In general, in its coding and implementation, is it possible that the rule of these two features (Custom Authentication Page and Password protection) does not apply to the site admin or any role that has access to the Builder? Only for access to Builder
In the password protection feature case it’s usually helpful to know that your password protection is working as expected as you’re building the site. And once you submit the password, the password protection won’t be applied until the cache is cleared.
