When an article's access is set to Registered, when a visitor tries to read the article, he is asked to log in and should be redirected to the article afterwards. But he is redirected to a 404 Error page because in the redirection URL, slashes '/' where replaced by '%2F'.
Note that this was working perfectly on Joomla! 2.5.6.
Opened On:
13 Mar 2013, 6:32 by N. Richard
Closed On:
8 Aug 2014, 8:26

Filed Under

  • Apache 2.2.x
  • Authentication and Login
  • First
  • MySQL 5.0.x
  • No Platform Implications
  • PHP 5.4.x
  • Second


Posted on 27 Apr 2013, 8:15 by Valentin Despa
When I try to set the access to "Registered", even if "Show Unauthorized Links" is active both in menu / article, the article itself does not appear in the list.

Trying to access the article by link, give an error, but no login.

Can you give me a hand replicating this issue? Thanks
Posted on 8 May 2013, 2:05 by N. Richard
Sorry for the delay of my response, I was on holidays.

I reproduced the problem again with a fresh install of, with default sample data. Then I set the "Beginners" article access to "Registered" and set "Show Unauthorised Links" to yes on both article and menu link (of type "Featured Articles", used as homepage).

Then on the homepage I can see the "Beginners" article intro without being logged in, and the more link (displayed as "Register to read more...") is:

(that is a link to the login page with a return URL)

After logging in I'm redirected to:

and obviously that the '%2F' things that generate the 404 Error.

I have this problem both on my local server, and on the server of my hosting company (1&1). I find it strange that nobody found it, but I know that the "Show Unauthorised Links" option is hardly ever used.
Posted on 29 May 2013, 1:39 by Jisse Reitsma
I can confirm this issue, and it seems to be related to a change in Joomla! 2.5.10. Within the file components/com_content/views/featured/tmpl/default_item.php around line 149 locate the following code:

$link->setVar('return', base64_encode(urlencode($returnURL)));

The addition of urlencode() is out of place because the return-URL itself is not passed through the resulting article-link. but the base64-encoded version of the return-URL is. Replacing that line with the following fixes this issue:
$link->setVar('return', base64_encode($returnURL));

I checked out the GitHub sources of Joomla! 3.1 and can tell that the issue is not occurring with Joomla! 3.1 and that the fix described by me here is already available in Joomla! 3.1.
Posted on 1 Jun 2013, 17:24 by Hans Kuijpers
I can reproduce the issue mentioned without the patch.
After apply the patch as mentioned by Jisse Reitsma I cannot reproduce the issue anymore. I receive the article I clicked on just the way as it supposed to do. The patch from Jisse solves the issue.
Posted on 1 Jun 2013, 18:08 by Hans Kuijpers
I also can confirm that this patch works for components/com_content/view/category/tmpl/blog_item.php
Since there is no pull request available I will create one... two. One for each file
Posted on 1 Jun 2013, 18:12 by Hans Kuijpers
@test succesfully tested proposal from Jisse.
created two pull requests in J2.5.x branch

Posted on 1 Jun 2013, 18:37 by Sander Potjer
@test successful. Ready to commit.
Posted on 1 Jun 2013, 19:38 by Brian Teeman
Two good tests - Marking RTC
Posted on 31 Jul 2013, 9:52 by Jean-Marie Simonet
This patch should also be applied to beez5 I guess.
Posted on 31 Jul 2013, 10:52 by Jean-Marie Simonet
Hmm, folks
this code was implemented in
and completed in

I see indeed that it is no more in 3.1, but I can't see any log of this change.
let me ask Nicolas Antimisiaris about this
Posted on 9 Aug 2013, 5:53 by Nicholas Antimisiaris
Ok, the fix in question was applied to the J25 code because of this bug:

You need to first check if removing the fixed line breaks the initial reported bug fix.

I am thinking that there is a urldecode missing somewhere that handles the case of stored url when permissions are not valid.

I would need to spend a couple of hours reproducing a test environment and going though the code to see what is happening.
Posted on 8 Aug 2014, 8:26 by Brian Teeman

After 1 year with no update I am closing this as it is unclear from the comments if this is still an issue