Open wpshellbelle opened 3 years ago
@wpshellbelle Is there any more information you can share as to how to reproduce this?
Does this happen on all your Atomic sites? Only with certain plugins enabled? Only with certain themes?
Hi @obenland I followed the same steps by logging in to a user on a private browser first, and was able to reproduce the same. If the user account had previously accessed wp-admin of the site in the current web browser, the WordPress.org bar will not appear.
The issue is reproducible on AT sites without custom plugins enabled, and on any themes.
@edwinho89 Thanks so much for your update! It turns out I still need a little more handholding, I'm afraid :)
I looked at the store admin of the reported user to switch to the user to reproduce the bug. Once I’m logged in to Calypso, I switched the site specified in chat. Clicking on Plugins to get to their wp-admin drops me in a SSO error page.
Am I doing something wrong?
I looked at the store admin of the reported user to switch to the user to reproduce the bug. Once I’m logged in to Calypso, I switched the site specified in chat. Clicking on Plugins to get to their wp-admin drops me in a SSO error page.
@obenland you'd need to:
In other words, the WordPress.org toolbar will be the one you see on the front end of the site until you visit WP Admin at least once.
Investigate a work around, potentially mock the first load if we can't find another solution.
Seems this is happening because the remote login process that is performed when a user logs in from wordpress.com/log-in
does not work currently on Atomic sites.
The 3rd party cookies pod is currently working on improving these flows, so I asked them if they can take over this issue (see p1621586041027700-slack-C01V2160U15).
cc @niranjan-uma-shankar
potentially mock the first load
I wouldn't recommend this, since it can degrade the performance as the result of making a wp-admin request for each logged out visitor visiting the frontend. The ideal fix would be to perform a remote login when the user logs in from wordpress.com/log-in
.
The 3rd party cookies pod is currently working on improving these flows, so I asked them if they can take over this issue (see p1621586041027700-slack-C01V2160U15).
Just to clarify, the 3rd party cookies pod is currently focused on simple sites. We haven't yet reached the point of discussing or triaging atomic site issues. I've added this issue to our project board for tracking, but I don't have a time frame defined at the moment on when we can get to this.
Thanks @niranjan-uma-shankar. I'll also keep it in our board, in case we have room for working on it first. We are currently prioritizing small issues (and there are plenty of them), so it's likely that we won't be able to fix this before the end of the "Back to Basics" plan.
Would that be something that might be worked on in the near future? The same user is asking for an update and maybe I can give them some information regarding this.
This also impacts "Edit" links as they won't appear until the cookie is set.
This also forces site owners that have Private or Coming Soon sites to use the provided "log in" buttons or access their WP-Admin in order to view the site.
Recent internal discussion:
Just FYI, we have removed the Nav Unification label as this issue is about the masterbar rather than the unified sidebar. If it was an error on our part, please feel free to readd the label! 🙇♂️
I think this bug is also affecting the "Edit" link seen at the bottom of pages and posts on the front end.
By default, the link does not show:
After visiting WP Admin and reloading the same page, I can see the link:
Reported in 5206358-zen
I can reproduce this, but I only see the WordPress.org masterbar when I'm proxied.
@Automattic/build Can y'all look into this? It's been open for quite some time and seems like a pretty big annoyance/missing feature for our Atomic users (who might not use wp-admin).
Support References
This comment is automatically generated. Please do not edit it.
This is what I discovered so far, I realise that the masterbar.css
file along with other wp-com css files not loading when I visit an AT site that hasn't yet access wp-admin. I suspect some of the jetpack modules might not be loaded so I append _cli
to the url, run the command jetpack module list
I see the masterbar is active. After I return to my site url now the correct admin bar is present. I suspect this might have something to do with when the masterbar module is activated, I'll continue to check.
I'd like to highlight https://github.com/Automattic/wp-calypso/issues/52046#issuecomment-945901653
I suspect this might have something to do with when the masterbar module is activated, I'll continue to check.
Overall, this is due to users not being in a logged-in state until they visit a /wp-admin/
resource -- which sets the necessary cookie.
Once they have the cookie, they'll get the bar and other admin/editor features, like page/post edit links. We force the masterbar module active and utilize it for nav unification, so it should be cookie rather than module @vykes-mac.
This is because the 3rd party cookies pod work didn't include Atomic and we aren't setting cookies for Atomic sites by just logging into WPCOM, like we do for Simple.
The cookie is wordpress_logged_in_xxxxxxxxxxxxxxxxx
Thank you @JoshuaGoode for that information, It would seem that accessing cli
executed whatever codepath is executed from wp-admin
to set the necessary cookie and caused it to work.
Just checking if this is still being looked into? I had a very confused user who couldn’t figure out how to access their dashboard after upgrading to the Business plan and the site went Atomic. Previously they always accessed it by going directly to their site’s URL and then clicking on My Sites. This is no longer possible if they have not yet been to a WP Admin page.
@tanjoymor This is on hold. There aren't any active plans to address it, largely because of the technical limitations discussed earlier in the thread.
@danielbachhuber I just moved one of my sites over to dotcom, and ran into this issue. It's very confusing as a user to not understand why things aren't showing up as expected.
Any chance we could revisit fixing this issue?
@cometgrrl No plans to spend time on this in the near future. When a solution comes, it will likely come with work around authentication + third-party cookies.
📌 ACTIONS
High
to Normal
to better reflect it's status.Going to remove this from the Quake board.
This issue came up in 8255814-zd-a8c More context in p1717667575189049-slack-C03TY6J1A
Steps to reproduce the behavior
What I expected to happen
I expected to see the WordPress.com admin bar as long as I was logged into WordPress.com.
What actually happened
I saw the WordPress.org bar instead of the WordPress.com admin bar if I didn't visit WP Admin
Does this happen on simple or atomic sites or both?
AT sites
User reported: 29090049-hc