Hi @aronu
Thank you for response!
Let me add up to what my colleague wrote previously.
It seems that we are actually dealing here with two separate issues. The default and expected behavior of Defender with login masked is:
1. if a visitor (not logged-in user) goes to site.com/friend they should see login form and be able to login; once they should immediately be taken to relevant back-end page (e.g. “profile” in case of subscriber-role users).
2. if already logged-in user visits site.com/friend they would see login form – this is because this is a default/standard WordPress behavior and Defender does not change it.
With login masking disabled going to wp-login.php page as a logged-in user would also show the same login form.
So this isn’t a bug but rather “lack of feature” that the other plugin has.
The additional code that my colleague shared is a “patch” to add that feature so already logged=in users wouldn’t see login form again but instead would be redirected to /wp-admin.
3. However, the fact that on your site already logged-in user doesn’t see login form but instead gets “404 Not found” message – this is unexpected issue. Usually such behavior is caused (if not by permalinks which you’ve already ruled out) by a conflict caused by some other plugin or some theme feature.
Most often, it’s happening if there’s at the same time some other plugin attempting to redirect user upon login ar in other way affects login functionality at the same time when Defender does it.
To fix it, it would be necessary to find what exactly is causing such conflict first and first step to do this would be to perform full conflict test on site. It goes like this:
– disable all the plugins except Defender
– switch theme to one of “core” themes, e.g. Twenty Twenty Two
If it’s a conflict, at this point issue should be gone and logged-in users visiting site.com/friend should see login form instead of being taken to “404 not found” page.
If so, then switch original theme back and check again. If it still works, start enabling your plugins back one by one until you get “404 not found” again and the last enabled plugin would be the cause of conflict.
Knowing about that we could then take it to our developers so they’d check it further and if it’s something that can be fixed on our end, we’d include fix in one of upcoming Defender releases.
Kind regards,
Adam