No Code Attached Yet
avatar uglyeoin
uglyeoin
18 Jul 2016

Steps to reproduce the issue

Create a login/logout menu item.
Go to options.
Set it to "internal url".
Fill in a url from your website.
Save the field.

Open the menu item. Check the internal URL is there and the option is set to internal URL.
If it is (as it should be) change the option to "menu item".
Select a menu item.
Press save.

Expected result

It should save the item with the menu item as the new login or logout redirect.

Actual result

Instead it errors saying

"Only one of the login redirect fields should have a value."

Firstly, the error could be solved instead of there being an error. If you are checking if both fields are filled in, then perhaps you could check which one is set, and only use that one. Thereby you could still keep both settings but only implement one. Secondly I did not understand the error message initially and worked it out through trial and error.

If you have an internal URL set, and a menu item was previously selected, you must select "default" for the menu item or else you will not be able to set an internal URL and will have the same error message. It is very unclear that default is the right solution.

System information (as much as possible)

J3.6
systeminfo-2016-07-18T08-22-47-05-00.txt

Additional comments

Votes

# of Users Experiencing Issue
0/1
Average Importance Score
3.00

avatar uglyeoin uglyeoin - open - 18 Jul 2016
avatar thomaslanger
thomaslanger - comment - 21 Jul 2016

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).

avatar infograf768
infograf768 - comment - 21 Jul 2016

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.

avatar designbengel
designbengel - comment - 21 Jul 2016

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?

avatar uglyeoin
uglyeoin - comment - 21 Jul 2016

@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.

avatar infograf768
infograf768 - comment - 21 Jul 2016

@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.

avatar uglyeoin
uglyeoin - comment - 21 Jul 2016

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.

avatar brianteeman
brianteeman - comment - 21 Jul 2016

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

avatar uglyeoin
uglyeoin - comment - 21 Jul 2016

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.

avatar infograf768
infograf768 - comment - 22 Jul 2016

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

avatar physalia
physalia - comment - 23 Jul 2016

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).

avatar physalia
physalia - comment - 23 Jul 2016

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=


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11176.

avatar infograf768
infograf768 - comment - 23 Jul 2016

@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

avatar physalia
physalia - comment - 23 Jul 2016

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)?


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11176.

avatar infograf768
infograf768 - comment - 23 Jul 2016

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

avatar infograf768
infograf768 - comment - 23 Jul 2016

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
?

avatar physalia
physalia - comment - 23 Jul 2016

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.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11176.

avatar brianteeman brianteeman - change - 23 Jul 2016
Category UI/UX
avatar physalia
physalia - comment - 23 Jul 2016

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.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11176.

avatar infograf768
infograf768 - comment - 23 Jul 2016

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

avatar physalia
physalia - comment - 23 Jul 2016

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.

avatar physalia
physalia - comment - 23 Jul 2016

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'))); ?>" /


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11176.

avatar infograf768
infograf768 - comment - 24 Jul 2016

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.

avatar supergrug
supergrug - comment - 1 Aug 2016

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.

avatar cpfeifer
cpfeifer - comment - 1 Aug 2016

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?

avatar supergrug
supergrug - comment - 1 Aug 2016

@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.

avatar cpfeifer
cpfeifer - comment - 1 Aug 2016

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?

avatar supergrug
supergrug - comment - 1 Aug 2016

@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.

avatar cpfeifer
cpfeifer - comment - 1 Aug 2016

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

avatar brianteeman
brianteeman - comment - 2 Aug 2016

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

screen shot 2016-08-02 at 07 19 20


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11176.

avatar supergrug
supergrug - comment - 2 Aug 2016

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 (


). I'm missing something obvious, but can't find the site login options...if they aren't in the menu item or module (as I've turned these off), where do I check my settings?

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.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11176.

avatar brianteeman
brianteeman - comment - 2 Aug 2016

@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

avatar cpfeifer
cpfeifer - comment - 2 Aug 2016

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

avatar brianteeman
brianteeman - comment - 2 Aug 2016

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/

avatar cpfeifer
cpfeifer - comment - 7 Dec 2016

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

avatar coolcat-creations
coolcat-creations - comment - 7 Dec 2016

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

avatar uglyeoin
uglyeoin - comment - 7 Dec 2016

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.

avatar cpfeifer
cpfeifer - comment - 7 Dec 2016

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.

avatar cpfeifer
cpfeifer - comment - 7 Dec 2016

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.

avatar coolcat-creations
coolcat-creations - comment - 7 Dec 2016

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

avatar brianteeman
brianteeman - comment - 7 Dec 2016

Closed as we have a pr see #13113

avatar brianteeman brianteeman - change - 7 Dec 2016
The description was changed
Status New Closed
Closed_Date 0000-00-00 00:00:00 2016-12-07 22:24:25
Closed_By brianteeman
avatar brianteeman brianteeman - close - 7 Dec 2016

Add a Comment

Login with GitHub to post a comment