Sujatha Fernandes cannot edit her site
Sujatha Fernandes is having problems with her re-directed site. She writes:
I log in at https://commons.gc.cuny.edu/ . Then I go to my site (https://sujathafernandes.commons.gc.cuny.edu,) and I am still logged in. But when I try to move from this page to click on and edit one of my pages, there is no "Edit page" function that allows me to go in and make changes to the page. It automatically logs me out again When I try to log in, it takes me back to my profile page and it's just a never-ending circle.
#1 Updated by Boone Gorges almost 3 years ago
Is the user able to visit https://sujathafernandes.commons.gc.cuny.edu/wp-admin and navigate to Dashboard > Posts or Dashboard > Pages? This is the recommended method.
Ray, it may be worth looking to see whether there's an issue with the Edit links in the toolbar or near the bottom of post content when on a mapped domain.
#4 Updated by Boone Gorges almost 3 years ago
- Assignee set to Raymond Hoh
Thanks, Marilyn! Ray, when you get a chance, could you have a quick look at the Edit link situation? If there's something simple we can do (like filtering the edit link that appears on posts when looking at a mapped domain) it may be worth the effort.
#6 Updated by Raymond Hoh almost 3 years ago
- Category name set to Authentication
- Status changed from New to In Progress
- Target version changed from 1.14.7 to 1.14.8
Ray, when you get a chance, could you have a quick look at the Edit link situation?
I just checked the "Edit Post" link in the toolbar and it correctly shows the subdomain link instead of the mapped domain link when the logged-in user is on their subdomain or on their mapped domain.
If there's something simple we can do (like filtering the edit link that appears on posts when looking at a mapped domain) it may be worth the effort.
I'm not sure what her workflow is, but I'm assuming the following:
- If Sujatha is logged into her mapped domain, this means she must have forced login to the domain with the
www.sujathafernandes.com/?force. (See https://redmine.gc.cuny.edu/issues/5525#note-28).
- If she is logged in and viewing a single post from her mapped domain, the "Edit Post" link in the WP toolbar will still use the subdomain URL and not the mapped one. If she is not logged into the Commons at this time, she will be prompted to login again. This might be causing the confusion.
- At this point, when she logs into the Commons, she should be redirected to the subdomain's dashboard "Edit Post" page.
The last point is where I've found a problem. I previously only tested with a super admin account.
For non-super-admins, they get redirected back to the Commons homepage instead of the "Edit Post" dashboard page. I pinpointed the problem to the login redirect filter in BuddyPress,
bp_core_login_redirect() - https://github.com/buddypress/BuddyPress/blob/4.0-branch/src/bp-core/bp-core-filters.php#L279.
Once I remove this filter and I try logging in again as a regular user, I get redirected properly to the "Edit Post" dashboard page.
Boone, I wanted to remove the BP's login filter in
bp-custom.php, but there is a tiny bit of logic in that function that does checks for the dashboard and activation pages. If a user does not have the rights, they get redirected back to the root blog homepage. I think it's safe to remove the BP login filter, but wanted your thoughts before I do so.
For now, I'm bumping to 1.14.8.
What would be worth the effort is switching to SSO, now that Lihua has figured out Let's Encrypt for our mapped domains. This would also solve a bunch of other related user reports.
Maybe it's time we turned SSO back on for 1.15? See https://redmine.gc.cuny.edu/issues/5525#note-26
#10 Updated by Raymond Hoh almost 3 years ago
- Status changed from In Progress to Staged for Production Release
I think it's probably fine to remove it altogether, as long as users are not redirected to wp-admin when logging in by default.
That's true for those that use the login form on the frontend to login.
If a user tries to go directly to
commons.gc.cuny.edu/wp-admin/ when not logged in, then this would not be covered. I've just written a filter to make sure we cover this use-case and have also removed the
bp_core_login_redirect() filter at the same time.