Its a bug!
/components/com_user/user.php
class UsersControllerUser

Method menulogout() gererat a redirect with the param return like "index.php?Itemid=123".
In the same class the method logout() check if this param is an Number. The string "index.php?Itemid=123" is not a number so the method ignore the redirect (line: 165).

It is indeed possible to enter values in both fields, forget it and try to save, thus getting the message, but there is NO bug here.

If Internal URL is left empty and you use Menu Item, the result is not directly index.php?itemid=123
(isnumeric() gives 123
It becomes $data['return'] = 'index.php?Itemid=' . $data['return'] . $lang; further down and therefore is considered as internal and used such for redirecting.

Similar for logout.

I had an issue with this redirecting always to userprofile until i choosed a page with is a sublevel menu-item (first level didn´t work). Can someone crosscheck this?

@infograf768 I don't know whether it is a bug or not, it's kind of confusing and probably bad UX @cpfeifer. Surely there could be an if statement which would alleviate the issue.

@designbengel
In 3.6, it is advised to always use the Menu Item field and not the internal URL.
There can't be any error as it is simply the itemID of the menu item which is appended to the index.php? (+ the language in multilingual sites). If one has access to that menu item, then it will work fine.

That is understood, and that is the way I prefer to work. The issue is it wasn't this way previously, so anyone upgrading will possibly be as confused as I was. It's bad UX in my opinion, and frustrating things like that go a long way to damaging reputation.

It would have helped greatly if you had commented during the very extensive
testing period.

Unfortunately when I tested 3.6 I didn't spot this error or I would have done so. I reported any errors I did find.

Once more, it is not an error. It "could" be understood as a confusing UX although the message is pretty clear...
We had to keep the Internal URL option for obvious B/C reasons.

BTW, there was an issue with logout in 3.6.0 which is corrected in the 3.6.1 to be released
#11093

Joomla 3.6.0
T3 Framework
SP Page Builder

Using Menu Item field (selected item: "Home") and not the internal URL: still redirected to user profile page and not to homepage.

Login redirect works well with other modal module (good for my main menu, but not in off canvas menu, where I have to put a "Login" item, refferring the standard user login system element).

Logout, as well as Login through standard system module, doesn't redirect to the selected menu item ("Home", in my case).

This is what I can see on address line: index.php?option=com_users&task=user.logout&cc586cbb91638a7c2ef8345d65882c01=1&return=aW5kZXgucGhwP0l0ZW1pZD00Mzc=

@physalia
As I said above, Logout redirect was broken in 3.6.0
It is working in staging/3.6.1 to come...
See #11093

Understood, about Logout redirect issue.
But what about Login redirect to user profile page, instead the selected menu item (I've tried every single item of my menu)?

Question: have you set a redirect in the login module as well as in the Login menu item?

Also, have you got a template override for
components/com_users/views/login/tmpl/default_login.php
and
components/com_users/views/login/tmpl/default_logout.php
?

The Login item in my off canvas menu refers to the User/Login standard type and, therefore, has two redirects (login & logout, both set to the same menu item) in the setting page.
There aren't template's overrides for default_login.php and default_logout.php-

The module used in main menu for login purpose has its own settings about redirection: it brings a pop-up modal window up, then redirects to the right page.

I need to do a correction about my previous post: I'm using a template without manually added overrides, but using Protostar template for Login menu item - then "landing" on the standard Protostar login page - redirection works.

One may have issues when redirection is set both in the login module and the login menu item.
It is a bug I discovered recently that WAS present before 3.6.0

What is working in Protostar means that your template/framework is not fully updated to 3.6.x

I have temporary modified default_login.php in this way:

This is working in my case, without changing template for login page to Protostar.

Previous version of the code (not redirecting) was:
J!Tracker Application at issues.joomla.org/joomla-cms/11176.

I have temporary modified default_login.php in this way:
input type="hidden" name="return" value="NDM3" /

This is working in my case, without changing template for login page to Protostar.

Previous version of the code (not redirecting) was:
input type="hidden" name="return" value="<?php echo base64_encode($this->params->get('login_redirect_url', $this->form->getValue('return'))); ?>" /

The existing code is

            <?php if ($this->params->get('login_redirect_url')) : ?>
                <input type="hidden" name="return" value="<?php echo base64_encode($this->params->get('login_redirect_url', $this->form->getValue('return'))); ?>" />
            <?php else : ?>
                <input type="hidden" name="return" value="<?php echo base64_encode($this->params->get('login_redirect_menuitem', $this->form->getValue('return'))); ?>" />
            <?php endif; ?>

If you use the login_redirect_url and what you enter in the field is incorrect, i.e. has not got the right format according to JUri::isInternal() (see hint in field), you will get the redirection to the profile.

Thanks for putting some work into the login feature, which seems to cause my users quite a lot of confusion when they are re-directed to the profile page (live site: 3.5.1).

I've just patched a backup of my main site to 3.6.1rc2 and can confirm:

Log in and log out from a login module seem to work fine, keeping the user on the page they were on and redirecting to the homepage on logout, as I've specified in the module.

Whether it is expected behaviour or not, I note that if someone clicks the link at the bottom of an article, it takes them to the login page, which I've configured as /login as a hidden menu item on my site. You then authenticate and are returned to the /login/profile page if you specify 'default' as the place to re-direct to in the 3.6.1rc2 menu item.

You can also now specify a menu item which I've set to my homepage, and this works now which is a big improvement on what I currently have on my live site, which dumps people onto the profile page as described above.

HOWEVER...surely a much more logical place to re-direct to is the article from whence they came. I see that there is an extension devoted to this issue (I've purchased it today but haven't implemented successfully as yet) which traps the 'previous page' in a variable and then re-directs back to this page after a successful login from the login page, which I think should be added as core functionality while you are working on this area....lots of confusion scattered around forums over many years so it would be great to have this workflow built as an option if possible?

Or have I misunderstood how this is meant to be configured?

Thanks!

And yes, I came across that UX glitch in 3.6.0...the issue is that the data that is duplicated is hidden from the users view when they switch to redirect to a menu item and click save. Yes, the error message helps to resolve it pretty quickly, but perhaps having a visual toggle that shows the redundant URL data on screen so the user doesn't have to change the setting back to find it, or setting that field to null when the user selects menu item will tidy up that screen a bit.

I'm just getting the chance to look at this. From a UX standpoint, there hasn't been any feedback or other complaints relating to this issue that I am aware of until now, so it is not an issue we've been looking at previously.

I personally have not used this feature simply because I haven't had the need for it, so I'm not sure I understand what the real world use case scenario is. I believe the purpose is to allow a redirect to a URL that is not part of the menu system, otherwise you could use the menu item feature to assign it. I'm just wondering how often this feature is actually needed and in what cases it is necessary to use it as opposed to using menu items.

My general feeling is this issue / use case is probably more the exception than the rule. I'm not saying it can't be improved, I'm just curious as to how is this actually being used and why. Maybe someone can fill me in: What is the advantage of a internal URL over using a menu item, or in what cases would you not want, or be able to, create a menu item for use?

@cpfeifer The menu item option is the new option and it's good to have for sure. The URL option has been there for a while but didn't seem to work for me at all in 3.5.1 -- seems fine in 3.6.1rc2.

Bigger issue for me is the log in behaviour via 'read more' links as I've tried to explain above. If people click 'read more' at the bottom of an article, I think it's reasonable for them to expect to be able to read more of the page they are on after authenticating without having to click 'back' a few times or navigate back to the article some other way. Most of my traffic is from eNews, so people wouldn't have a clue how to find an article via the web site if they got there from eNews or any other website for that matter.

If you use the "default" redirect setting it stays on the same page where the login or logout occurs. I am testing on the 3.6.1 alpha and it works there for me.

Is that what you're looking for, or it is something else?

@cpfeifer I've identified two different behaviours:

1. If you log in using a module, including a module positioned in a menu item as many templates allow, then yes, it stays on the same page. This is fine.

2. If you log in using the read more link at the bottom of the visible text on a restricted article, it takes you to the login screen. You then authenticate and the default behaviour is to stay on the same page as you suggest. But as the 'same page' is now the log in screen, you aren't put back onto article you were trying to read which I don't think is very logical. Yes, you can set this method to go to any other page like the home page etc, but this is still not what users expect.

I was missing the part where it was a protected article. Let me look into it and get back to you.

@supergrug in your example then you should not be setting a redirect. I cannot confirm your point 2 - see movie below

Thanks @brianteeman, I've installed a fresh copy and can replicate the more logical behaviour you've demonstrated.

So I guess put this down as user ignorance / config error.

In my backup of my live site (also now running the latest RC) I've turned off my hidden menu item for the login page (/login) and turned off my login modules, but don't seem to be able to get the site to behave like the fresh install when I'm on a restricted article (ie an article showing the first couple of lines down to where we put in the read more code (

In the fresh install I can see a return parameter in the URL when hovering over all 'read more' links, but in my live site I don't see this when hovering over the 'read more' link in the locked view of the article (ie when on the page with it showing a couple of pars only). On the positive side, I do get the expected behaviour in my category list views.

@supergrug please use the forum for support. Your issue was nothing to do
with the reported issue here and its been the expected behaviour of joomla
for a long time

@brianteeman great video demonstration. We need more of that in general, super helpful.

I do it all the time when it is appropriate

On 2 August 2016 at 17:30, Cliff notifications@github.com wrote:

@brianteeman https://github.com/brianteeman great video demonstration.
We need more of that in general, super helpful.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11176 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8Va3vs242Wm8tDyW9Er02LqKuDXZks5qb3DDgaJpZM4JOtQY
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Can we close this issue if it is not actually an issue? I'm not sure how to do that :)

Is there a suggestion or PR how UX can be improved? Why would you like to close it?

I personally think if the Menu Item is set then the Internal URL option should be ignored. That would resolve this issue. For me, it's saying you can't set two items, and perhaps it's all in the interpretation, but by setting a menu item I feel like I have only set one item. In fact, the internal URL disappears, so I have no way of seeing that it is set.

For me it should not be an option to set two items. There's no point in allowing it and providing an error message, it should be an either/or option. I will have a look and see if it's within the realms of my ability to "fix" it.

For some reason it is only on the login menu item. The module only allows redirect by menu item, and the logout menu item only allows redirect by menu item.

Apologies, I haven't looked at this in a while. I thought it has been determined there wasn't an issue here, but there are a lot of people on this thread asking different things. I'll take another look at this today.

I can see the issue you're describing, I wasn't quite following what you were experiencing at first.

I agree there should be a simple solution to this and I'm investigating a potential fix. As soon as I can come up with up one I'll start a PR and we can go from there. Thank you for your patience.

There is already a PR, you can commit directly in my repo.

Closed as we have a pr see #13113