CUNY Academic Commons

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.

Moving to a milestone so that Ray can have a brief look at the Edit link situation on mapped domains.

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 force parameter - 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

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.

Here's the commit - https://github.com/cuny-academic-commons/cac/commit/fe2607fc296926d512195648cad53fc68bb2d9ec