I have tested this item ✅ successfully on 4fa702f


Before PR -
No login menu => too many redirects
With login menu => login

After PR
No login menu => login
With login menu => login

(thanks for listening that the correct approach was to look at the cause of the bug)

I have tested this item ✅ successfully on ea67fe6

RTC

I successfully tested this as well J3.85.RC with and without login form performs as JM stated.

This is still incorrect as bypassing the use of the router is wrong.

I have tested this item ✅ successfully on ea67fe6

I successfully tested this as well J3.85.RC with and without login form performs as JM stated

@mbabker

This is still incorrect as bypassing the use of the router is wrong.

It is imho a special case and I did my best. Welcome to better coders. ;)

Bypassing the router means there's still a broken routing condition. That's what's concerning here. Ya, it might work, but it's avoiding another issue.

@mbabker
Found a way to keep JRoute AND keep Itemid to NULL. Is that OK for you?

Removing RTC as the code has changed

Please test anyway. Thanks.

I have tested this item ✅ successfully on a6530dd

hhmm, i am afraid that this PR is not enough

the redirection loop issue is fixed
... but the login form that appears has a target URL that includes an Itemid ...

• and it is the Itemid of that the home page which is inaccessible

so as soon as you submit the form, you get redirected back to the login form, to try to login (again)

thus you cannot login
So since we can not update login forms in overrides if 3rd party templates to use JRoute will null Itemid
this will

• either need to be fixed inside the router code
• or need to go back to the PR that displays the warning message inside the home page menu item

in any case it is a rare misconfiguration issue, no need for this to be addressed in J3.8.5

I can not confirm that - login works correctly for me

@ggppdk

I confirm your findings. The login form reloads.
Closing.

I can not confirm that - login works correctly for me

you will need to unpublish all 'com_users' menu items (of any type),
that way the menu item id (Itemid) that is selected for the form target URL will be the home page menu item id, which is not accessible

As the attached movie shows - I have no com_users menu items and with the patch applied it works perfectly

Make sure that SEF URLs are enabled (i tested with SEF URLs on),
and then please examine the HTML code login form and look at the form target URL,

the form target URL
if there are no com_users menu items published
-- it should have the menu item Id of the home page

only then you will not be able to login, because before login tasks executes, you will get redirected back to the login form due to the currently inaccessible menu item

Sef Enabled

I tested with current staging and this PR

Look at my target URL

/devel/joomla-cms2/index.php/component/users/?task=user.login&Itemid=435

435 is the home page menu item which is inaccessible

i don't know why you get a form target URL that does not have a menu item

@brianteeman
i think you did not apply correctly the last instance of the pr. look at the url you got. it does not inlude &itemid=

yeah - something went wrong locally. just did a clean install of everything and I see the problem