This is without any warranty, so please test.

Successful tested by @gwsdesk and @Tabelle moving to RTC

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

Breaks every single menu item for me... Removing RTC.

When testing, make sure you test with the various SEF settings.
This PR only works as long as you don't enable the SEF suffixes.

Confirm --> gives 404 and sorry for not testing that patch with SEF
suffixes enabled

On 10/30/2014 2:49 PM, Thomas Hunziker wrote:

When testing, make sure you test with the various SEF settings.
This PR only works as long as you don't enable the SEF suffixes.

—
Reply to this email directly or view it on GitHub
#4957 (comment).

Shouldn't the following rule actually take care of that already?

 # and the requested path and file doesn't directly match a physical file
 RewriteCond %{REQUEST_FILENAME} !-f

I wonder why that fails.

"When testing, make sure you test with the various SEF settings"

Those tests were not done before the fix either. There are posts in the thread forum requesting to test with '#RewriteBase /' uncommented (with path if in subdirectory). Also it was not tested with the live_var in the configuration.php given a value. If it was tested with those scenarios prior to applying the patch it may negate the need to adapt the .htaccess to suit specific server configurations.

I know you suggested that on the forums but that makes no sense and has
nothing to do with this issue as already stated, for sure not with my
test and setup. live_var has nothing to do with SEO but is used in case
the auto detection Joomla has of the root url fails. Than you enter the
live site variable. Since the live site is detected and works as such
also with the cPanel block active such test has no merit and is useless.
On 10/30/2014 5:48 PM, Webdongle wrote:

"When testing, make sure you test with the various SEF settings"

Those tests were not done before the fix either. There are posts in
the thread forum requesting to test with '#RewriteBase /' uncommented
(with path if in subdirectory). Also it was not tested with the
live_var in the configuration.php given a value. If it was tested with
those scenarios prior to applying the patch it may negate the need to
adapt the .htaccess to suit specific server configurations.

—
Reply to this email directly or view it on GitHub
#4957 (comment).

"I know you suggested that on the forums"
It was not just me that posted it. Nicholas also posted it but because it was in a post that included your vile remarks made in a PM to him that and other posts were deleted.

The fact remains that you confirmed it as a bug without fully checking all possible fixes. And you passed a patch without fully testing all the variations.

Well I did not check your solutions since they made no sense since those
suggestions were not applicable to this situation. I confirmed that I
did not check the Suffix indeed and apologized for that so what is my
penalty now?
Please refrain from judgement on events where you have only hearsay info
of and refrain from posting that on the Issue Tracker or Github? Where
is your patch or are you only here to flame and blame?
On 10/30/2014 6:26 PM, Webdongle wrote:

"I know you suggested that on the forums"
It was not just me that posted it. Nicholas also posted it but because
it was in a post that included your vile remarks made in a PM to him
that and other posts were deleted.

The fact remains that you confirmed it as a bug without fully checking
all possible fixes. And you passed a patch without fully testing all
the variations.

—
Reply to this email directly or view it on GitHub
#4957 (comment).

Hi everybody,
the reason why this pull request breaks menu items is that within the line which has been there once and was taken again for this pull request, the condition for valid extenstions has not been replaced by a condition for any extension, but it has been removed, and so the complete ruleset is not applied for URLs having an extension.
I can verify this, and suggest following correction, which I've succesfully tested not breaking the menus anymore:
RewriteCond %{REQUEST_URI} /component/|(/[^.]|.[^.]+)$ [NC]
The description in the comment should be changed as follows so it fits to the rule:
"and the request is for something within the component folder, or for an extensionless URL on the site root, or the requested URL ends with an extension".
Can someone of those who had the problem mentioned in #4955 now test if this still solves that problem?
And if my corrections is fine, how shall we bring it in? Shall the author of this pull request here do it, or shall I create an own one (would be my first one)?

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

Hmm, seems this editor removed the quote (backslash) for the dot.
Maybe it looks ok when i quote the backslash?
Preview looks ok.
RewriteCond %{REQUEST_URI} /component/|(/[^.]|\.[^.]+)$ [NC]

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

@richard67 Please create a PR against my branch. That way, I can accept that change, it is automatically included in this PR and your changes can not be mangled by the markdown editor. You should be able to simply go to my branch and click on edit for that file.

@Hackwar: Hmm, I haven't done this before. Seems I have to install GitHub for Windows first, right? And then just click your file's name and select "Open this file in Github"? The edit symbol for the file is disabled because I do not have push access to the path-12 branch, I guess. Maybe you can give me a few short instructions?

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

@Hackwar: Ah, I see, when I view the whole file, then I have enabled edit button, which says it will fork this project so I can edit. Is that the right way?

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

@Hackwar: I did as you suggested, made 2 pull requests (1 for each file) against your branch, with my suggested changes. I hope I did all well and in the right way. But someone who has the password-protection issue (#4955) has to test if this now still helps.

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

Seems I did well. Who tells the guys now to retest?

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

You just did ;)
On 10/30/2014 8:30 PM, richard67 wrote:

Seems I did well. Who tells the guys now to retest?

/This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at
issues.joomla.org/joomla-cms/4957
http://issues.joomla.org/tracker/joomla-cms/4957./

—
Reply to this email directly or view it on GitHub
#4957 (comment).

Leo Lammerink
MD GWS - Enterprise Ltd
Skype: gwsgroup
www.gws-desk.com http://www.gws-desk.com | www.gws-host.com
http://www.gws-host.com | www.gws-deals.today http://gws-deals.today

You just did ;)
On 10/30/2014 8:30 PM, richard67 wrote:

Seems I did well. Who tells the guys now to retest?

/This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at
issues.joomla.org/joomla-cms/4957
http://issues.joomla.org/tracker/joomla-cms/4957./

—
Reply to this email directly or view it on GitHub
#4957 (comment).

A problem is that I cannot reproduce the password-protection issue (#4955), and I am still not sure if this rule which I modified is really neccessary or even makes sense. I only fixed it so it does not break the menu items anymore with SEF extensions on.

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

It is not working I regret. Error persists
On 10/30/2014 9:32 PM, richard67 wrote:

A problem is that I cannot reproduce the password-protection issue
(#4955 #4955), and I am
still not sure if this rule which I modified is really neccessary or
even makes sense. I only fixed it so it does not break the menu items
anymore with SEF extensions on.

/This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at
issues.joomla.org/joomla-cms/4957
http://issues.joomla.org/tracker/joomla-cms/4957./

—
Reply to this email directly or view it on GitHub
#4957 (comment).

Hmm, maybe we should make the rule like it was once, with list of valid extensions?

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

Found this if it helps

"In this condition the Web server thinks that the HTTP data stream sent by the client (ex. a web browser) was correct, but access to the URL requires user authentication which has not yet been provided or which has been provided, but failed authorization tests. This is commonly known as “HTTP Basic Authentication” or HTTP Error 401 Unauthorized.

Generally this error message means you need to log on (enter a valid user ID and password) somewhere first. If you have just entered these and then immediately see a 401 error, it means that one or both of your user ID and password were invalid for whatever reason (entered incorrectly, user ID suspended etc.)."
http://www.myguysolutions.com/2010/02/10/how-to-fix-wordpress-404-errors-on-password-protected-directories/

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

Hmm, maybe we should make the rule like it was once, with list of valid extensions?

No, because it's not the real issue.
There is no issue directly accessing any file within folders. So the redirect rules are actually correct and should allow accessing any file. The following two rules say to not redirect if the URL is a valid file or folder. And those work fine.

So we first have to find out why Apache thinks that the authentication files (or at least one of them) are not valid files and thus redirects.

Maybe because of this (from Your text to link here...):
REQUEST_FILENAME
The full local filesystem path to the file or script matching the request, if this has already been determined by the server at the time REQUEST_FILENAME is referenced. Otherwise, such as when used in virtual host context, the same value as REQUEST_URI. Depending on the value of AcceptPathInfo, the server may have only used some leading components of the REQUEST_URI to map the request to a file.

Maybe it is a virtual host context, so REQUEST_FILENAME does not work?

Also from Apache mod_rewrite help:

Other things you should be aware of:

The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same value - the value of the filename field of the internal request_rec structure of the Apache HTTP Server. The first name is the commonly known CGI variable name while the second is the appropriate counterpart of REQUEST_URI (which contains the value of the uri field of request_rec).

If a substitution occurred and the rewriting continues, the value of both variables will be updated accordingly.

If used in per-server context (i.e., before the request is mapped to the filesystem) SCRIPT_FILENAME and REQUEST_FILENAME cannot contain the full local filesystem path since the path is unknown at this stage of processing. Both variables will initially contain the value of REQUEST_URI in that case. In order to obtain the full local filesystem path of the request in per-server context, use an URL-based look-ahead %{LA-U:REQUEST_FILENAME} to determine the final value of REQUEST_FILENAME.

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

I mean I assume the RewriteBase has been set if necessary. If not, this is the problem. I cannot reproduce the problem here, for me the standard 3.3.6 works fine.


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

Bakual wrote:
"So we first have to find out why Apache thinks that the authentication files (or at least one of them) are not valid files and thus redirects"

Looks like cPanel puts the .htpasswd file in the /username/.htpasswds/ with the same structure as the path to the site. When it writes the .htpasswd file it writes in in a folder that is parallel to and mirrors the one .htaccess is put in

gwsdesk wrote:
"The cPanel protection consists of 2 elements. A password file which is located outside the root in home/username/.htpasswds/public_html/administrator/passwd" and the htaccess file which is located in the ../administrator file (which loads the passwd from the link given and stores the pw)."
http://issues.joomla.org/tracker/joomla-cms/4955

So it would be interesting (When cPanel creates the password protection for the directory) to see what path is given in the .htaccess authentication file to where the .htpasswd authentication file is written

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

Well, can it be that if the password file is outside the joomla root, and the .htaccess in the joomla root uses RewriteBase set to the joomla root, what should be the case for SEF, then the REQUEST_FILENAME might be set to the REQUEST_URI, like Apache help describes, and then the %{REQUEST_FILENAME} !-f and %{REQUEST_FILENAME} !-d might not return true?

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

I have tested the situation on my siteground server running cpanel without making any changes or patches

the .htaccess was created in
/home/xxxxx/public_html/xxxx/administrator/passwd"
the .htpasswd was created in
/home/xxxx/.htpasswds/public_html/xxxx/administrator/passwd"

Using the core htaccess file and setting a passwd on the administrator folder I had NO problems at all.

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

As I have mentioned in my very first post we were investigating. I have repeated that regularly and my hosting team has been in contact with our datacenter at Liquidweb as well to get hold of the issue. If you go to http://gwsdev3.info and http://gwsdev3.info/administrator you will notice that the admin shows the cPanel popup as expected and beieve me when entering the credentials you get to the Joomla login

The frontend works fine with Suffix or without Suffix. You can see it working here with suffix without any errors. Liquidweb and GWS-Host.com have been testing the issue on 3 different accounts and on different servers and it comes very simply down to the change which was made in the htaccess file in the previous version. I have attached the message of a LW representative with our hosting team for those who question everything.........

This is changed in .htaccess (as posted before me think)

## Begin - Joomla! core SEF Section.
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#RewriteRule ./ /index.php [L]
#
## End - Joomla! core SEF Section.

And as I stated it worked perfectly without making any changes at all to the core.

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

I'm not a server guru myself, so bear with me when I'm asking stupid things.
But from my understanding the rewrite rules apply to the HTTP request coming from a browser to the Apache server. This request will be rewritted to the proper file (index.php in our case).

When we are talking about password authentication, this is not a file the browser requests itself. It's something Apache does. The browser has no way to request/access the password file anyway since it is stored outside the webroot (thus also outside Joomla root) in your case. So in my theory, the mod_rewrite should have no impact anyway.

Also the rules as they are allow to access any file which is physically present in a folder. So this itself can't be an issue as well.

That is why I wonder why the change in .htaccess makes a different. In my understanding it shouldn't matter at all for the HTTP basic authentication.
I'm sure I miss something important and that bit most likely is the key to the issue.

@gwsdesk

Apart from including your original message in his reply and thanking you for your time ... has the LW representative got back to you to confirm it was the change in the .htaccess ?

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

@ all who have been so kind to test this issue. It has been helpful. Here is the final verdict and the solution we have created and all works fine now:

Linux System Admin (Liquid Web) to one of our system admins:
Oct 31 06:49 AM

I have removed the htaccess-adjustment. This is a known issue with various joomla installs in different server settings, it may well be that a recent update to joomla does not work as expected under apache 2.4.

That Apache version does have some slightly syntax changes to the way it interprets rewrite rules compared to Apache 2.2. Issue you experience is caused by the way the Joomla permalink redirects can intercept the normal 401 response code and replace it with the internal joomla 404 page. You can easy resolve this behavior when you add to public_html a 401.shtml upon account creation and a copy of the 401.shtml would simply need placed in this directory:

/root/cpanel3-skel/public_html

The contents of that location are copied on account creation to 'public_html'. In the shtml the message like "This page requires authentication." will be called

This resolves this indeed

So when somebody in the future experiences this they should contact their host and ask them to implement this unless we find a modification of the rules that causes the 401 response to be recognized

Thanks all

So the link from Kevin (http://www.myguysolutions.com/2010/02/10/how-to-fix-wordpress-404-errors-on-password-protected-directories/) may also be a solution? To add

ErrorDocument 401 ./error.html
ErrorDocument 403 ./error.html

before the rewrite rules start. Obviously we would need something different than error.html in our case, because we don't have such a file.

At least it explains why it does not behave the same for everyone.

That is not seriously your proposal to solve this. So instead of fixing the rewrite rule, you want us to add a static error page to Joomla somewhere? Seriously?

That is not seriously your proposal to solve this. So instead of fixing the rewrite rule, you want us to add a static error page to Joomla somewhere? Seriously?

No. it's not what I meant.

I found a good explanation of the issue here http://www.myriadinteractive.com/blog/view/id/29/conflict-between-apache-url-rewriting-and-basic-authentication

For basic authentication, the server writes a "401 Unauthorized" header and then looks for an error document based on a pre-defined path. Most of the time, the error document won't exist in the directory that you want to protect, so the request gets handled by the rewrite engine which throws a 404 error.
The solution to this problem is pretty straightforward. You need to add a single line of code to your .htaccess file instructing Apache to ignore the error document. When you're done, the code should look something like this:

ErrorDocument 401 "Unauthorized Access"
RewriteEngine off
AuthType Basic
AuthName "Administration"
require valid-user
AuthUserFile "/home/user/.htpasswds/public_html/admin/passwd"

The solution proposed there would have to be added into the .htaccess file in the protected subdirectory which first says to not search for that default error file and then disables rewrite for that subdirectory.
That's obviously not an ideal solution and not something we can do from our end.

So the solution would have to be to rewrite the error pages to something that works. That could be a proper Joomla error page somehow. Or we disable the rewriting for those requested default error pages and let apache handle it from there. If that works.

Hi Leo

Does "I have removed the htaccess-adjustment. " mean they removed the code that you added to the .htaccess ?
And does " You can easy resolve this behavior when you add to public_html a 401.shtml" mean that RedEye was correct when he said (in the forum) about the 401.shtml

The part in the middle
"This is a known issue with various joomla installs in different server settings"
Is not quite accurate because wordpress also suffers the same problem. And it is entirely probable that a .htaccess with only 'RewriteEngine On' in it would also trigger the error.

If http://www.myguysolutions.com/2010/02/10/how-to-fix-wordpress-404-errors-on-password-protected-directories/ is correct then
ErrorDocument 401 .templates/system/error401.html
ErrorDocument 403 .templates/system/error403.html
In .htaccess with the two files created in templates/system/
should work.

If that did work then it would make Joomla more flexible as it would counteract the error that happens on servers with a conflict between Rewrite on and directory password protect.

Summary:

Test needed with .htaccess containing only Rewrite on .. to narrow down the error.

Test needed with .htaccess containing Rewrite on
and
ErrorDocument 401 .templates/system/error401.html
and
ErrorDocument 403 .templates/system/error403.html
with error401.html and error403.html in templates/system/.

This would confirm or eliminate the cause of the error being a conflict between Rewrite on and directory password protect. And would confirm or eliminate the the possibility of producing a patch that would allow for servers that has a conflict between Rewrite on and directory password protect. A decision could then be made as to if Joomla core should allow for those servers configuration or declare the error 'Not Joomla core'

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

What if we add something like that to the rules?

RewriteCond %{REQUEST_URI} !=/401.shtml
RewriteCond %{REQUEST_URI} !=/403.shtml

Maybe needs a regex to also take care of files in subfolders?
Hard to test without having the issue myself.

@Bakual

Not sure a rewrite condition should be used because it looks like a clash between rewrite and a server setting. I can not reproduce the error either. It would be good for a test to be done with a .htaccess that only contains Rewrite on that would once and for all show whether it was mod_rewrite or something else in Joomla's .htaccess that caused the 404

There is definitely a problem because Leo is experiencing it. But imho the two main questions are:

1. Is the 404 caused by a conflict with the server settings and mod_rewrite or with the server settings something in Joomla's .htaccess ?

2. If a patch is created how can it be tested thoroughly when normal bug testing protocol requires 2 testers performing successful test but only one of us is having the issue ?
   
   This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4957.

As far as I understood the issue (from reading various links) it comes from the fact that Apache tries to see if there is a custom error page defined for showing the 401/403 authentication error responses.
That's this 401.shtml file that was mentioned in one of the links.
Apparently Apache now takes into account our redirect rules when searching if said file exists.
And thus gets redirected to our index.php. Which then fails to generate a proper 401 response and thus the authentication fails.

If we now can make sure the rewrite rules are not applied for those two files, then Apache should detect that there is no such file and use the default behavior to send out the response.

With the old rule of only rewriting for specific extensions that worked as well. Since "shtml" wasn't in the allowed list of extensions and thus there was no rewriting.

So in theory it should work if we add this conditions ("rewrite if requested file is not 401.shtml or 403.shtml") to the rewrite rule.

@Bakual Aaaaaaaahhhhhhhhhhhh yes I see

"Apparently Apache now takes into account our redirect rules when searching if said file exists.
And thus gets redirected to our index.php"

Perhaps 'Apparently Apache (depending on individual server settings) takes into account our redirect rules when searching if said file exists' would be more accurate ? I tested on a server that runs Apache/2.4.9 (Unix) with no errors.

I am trying to reproduce the error with little success. If I can manage to reproduce the error then I can test that addition.

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

This really sounds like a badly configured server and nothing to do with
joomla.
On 31 Oct 2014 21:25, "Webdongle" notifications@github.com wrote:

@Bakual https://github.com/Bakual Aaaaaaaahhhhhhhhhhhh yes I see

"Apparently Apache now takes into account our redirect rules when
searching if said file exists.
And thus gets redirected to our index.php"

Perhaps 'Apparently Apache (depending on individual server settings) takes
into account our redirect rules when searching if said file exists' would
be more accurate ? I tested on a server that runs Apache/2.4.9 (Unix) with
no errors.

I am trying to reproduce the error with little success. If I can manage to
reproduce the error then I can test that addition.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/4957
http://issues.joomla.org/tracker/joomla-cms/4957.

—
Reply to this email directly or view it on GitHub
#4957 (comment).

Should it be closed as Not Joomla core ?

You should read what the specialist of Liquidweb wrote Mr. Teeman. Please maintain your
impartial position and refrain from judgement when you have not the slightest idea?
On 11/1/2014 4:34 AM, Brian Teeman wrote:

This really sounds like a badly configured server and nothing to do with
joomla.
On 31 Oct 2014 21:25, "Webdongle" notifications@github.com wrote:

@Bakual https://github.com/Bakual Aaaaaaaahhhhhhhhhhhh yes I see

"Apparently Apache now takes into account our redirect rules when
searching if said file exists.
And thus gets redirected to our index.php"

Perhaps 'Apparently Apache (depending on individual server settings)
takes
into account our redirect rules when searching if said file exists'
would
be more accurate ? I tested on a server that runs Apache/2.4.9
(Unix) with
no errors.

I am trying to reproduce the error with little success. If I can
manage to
reproduce the error then I can test that addition.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at
issues.joomla.org/joomla-cms/4957
http://issues.joomla.org/tracker/joomla-cms/4957.

—
Reply to this email directly or view it on GitHub
#4957 (comment).

—
Reply to this email directly or view it on GitHub
#4957 (comment).

Well maybe we should make an addition to the documents "If anything
works on Siteground or on Xampp it is no Bug"
On 11/1/2014 5:26 AM, Webdongle wrote:

Should it be closed as Not Joomla core ?

—
Reply to this email directly or view it on GitHub
#4957 (comment).

Leo Lammerink
MD GWS - Enterprise Ltd
Skype: gwsgroup
www.gws-desk.com http://www.gws-desk.com | www.gws-host.com
http://www.gws-host.com | www.gws-deals.today http://gws-deals.today

Everyone does know ... If you have a directory protected with .htaccess but lack a 403 file, whether it is server set or .htaccess set, you will get a 404 error.

There is a preliminary check for a 403 file in case the password is entered incorrectly and if it isn't globally configured(or .htaccess) you will get a 404 file not found.

@Bakual
"it comes from the fact that Apache tries to see if there is a custom error page defined for showing the 401/403 authentication error responses.
That's this 401.shtml file that was mentioned in one of the links.
Apparently Apache now takes into account our redirect rules when searching if said file exists.
And thus gets redirected to our index.php. Which then fails to generate a proper 401 response and thus the authentication fails."

This is exactly what the people from LW stated in their conversations with my server people as posted. So what is the correct piece to add to the .htaccess so I can test this on one of our boxes?

Based on some examples found using Google, I would try something like this:

# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# and the requested non-existant file isn't a custom error file
RewriteCond %{REQUEST_URI} !^401.shtml$
RewriteCond %{REQUEST_URI} !^403.shtml$
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]

I have no clue if that would work but it's the direction I would try.

System administrators at Liquidweb have gone all out (kudo's!) to define what is causing this issue. First reply from a Linux System Admin:

Here is a sample curl session I see when trying to access the URL "gwsdev3.info/administrator/" with the 401.shtml moved.

[I have stripped some potentially identifying information from this]
You can quite clearly see that the 404 message is coming from inside joomla by the "X-Powered-By" line.

HTTP/1.1 404 Article not found
Date: Sat, 01 Nov 2014 12:17:17 GMT
Server: Apache
WWW-Authenticate: Basic realm="administration"
X-Powered-By: PHP/5.4.34
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html

The 404 didn't come from apache but is being processed by a PHP script. Since the only logical php script that is getting ran is Joomla!, it must be coming from there.

The issue was successively taken on by another System Admin who gave the following feed-back to my hosting team:

I noticed from the posts you linked me that they were unable to recreate the error on their side. I was able to with my cPanel VPS install a plain version of Joomla!, password protect the directory and got the same error you have been seeing.

It seems Joomla! is not compatible with the default cPanel configuration in some way. From my poking around it seems the configuration line:
ErrorDocument 401 /401.shtml
was the thing that was breaking it. I removed it from the main conf (where my colleague put it earlier) and from the default include where cPanel adds it as well.

It is working now, but the Joomla! developers should look into exactly why this "bad configuration" broke their code.

"It seems Joomla! is not compatible with the default cPanel configuration in some way"
Not only Joomla but Word press and other scripts.

"it seems the configuration line:
ErrorDocument 401 /401.shtml
was the thing that was breaking it. I removed it from the main conf (where my colleague put it earlier) and from the default include where cPanel adds it as well. "
Would be interesting to know if the cPanel configuration at Siteground (where Brian tested) is standard or has also had that line removed.

"but the Joomla! developers should look into exactly why this "bad configuration" broke their code."
Why ? So that the code in Joomla files can be altered to run on what has been defined as a 'bad configuration' ?

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

@Bakual

The OP of the thread in the forum tested that code and posted back


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

I can only replicate this if I purposely break the httpd.conf ErrorDocument location, such as /401error.shtl instead of the real location /401.shtml. Even giving the wrong location of built in includes in the shtml file would not break it, but it would display the 404 for supporting includes not being found. Was this tried?

http://yourdomain.com/401.shtml

Typed directly into the URL bar? If the custom error message shows, not the new .htaccess file.

It wouldn't be the first time cPanel broke something and certainly not the last. a Few years back they pushed a new release with a syntax error in one of the mailbox config files. It would be helpful if you could provide the default httpd.conf when the VPS is a fresh install.

httpd.config could have something incorrect or a broken alias. The host could have their own customised virtualhost server config for the accounts on a box. Even testing this on a shared server, you can add a custom error page, but can't remove the

ErrorDocument 401 /401.shtml

from the httpd.config once you enable it. So once you create the custom error pages, all you can do is edit them or break your site errordoc pages if you delete them.

Unfortunately, some hosts dump their standard custom error pages into the root of the domains, add-ons and sub-domains automatically. Mainly to add in their links, brand name, whatever. My testing was in no way broken with the standard cPanel setup, it was using the default core ErrorDocuments. It wasn't until I enabled custom ErrorDocuments, then tried to disable them because the custom ErrorDocument wasn't being removed from the httpd.conf file or specific host file for the domain.

If I had to make a guess, I'd bet it is config issue with the Alias of default error messages vs the set location. Something along those lines.

So after 2 months with no progress on this issue can we close it as not Joomla core

Closing as requested by @brianteeman

Set to "closed" on behalf of @zero-24 by The JTracker Application at issues.joomla.org/joomla-cms/4957

I'm reopening this based on some feedback from @nikosdion where apparently the original removing PR

Unfortunately, on some servers this makes it impossible to access /administrator OR /administrator/index.php

Nic's shipped this patch out with the latest admin tools versions so I'm going to await feedback and merge assuming there were no issues.

This PR is far from having no issues. It breaks the site. That's why it has been closed and since there was no progress to actually fix the PR. Imho makes no sense to have a non-working PR open for such a long time. If the issue is valid, create a new one or reopen the old one.

Can you try replicating that again please? I just implemented this on my site (http://joomjunk.co.uk/) and as you can see there are no menu issues. If so can you list server details please?

Ah true, the later commits fixed it. I can't say if it fixes the 401 issue but at least it doesn't look like it's breaking URLs.

I have tested this code on my Mac (Zend Server), Apache on Windows (custom build per my blog’s instructions), Ubuntu Server (per my published Vagrant setup scripts), another Ubuntu Server with Zend Server and two live sites on Rochen and SiteGround. I had no issues with SEF URLs, with and without redirections, with and without suffixes. I am waiting for my clients to give me feedback since I have applied the same change on Admin Tools’ .htaccess Maker.=

As this change was reverted in admintools as it was found to not be a good solution I am therefore closing tis PR once again

@Bakual @Webdongle

In Apache configuration,
"RewriteEngine Off" is introduced by Apache to explicitly disable all "RewriteRule" and "RewriteCond".
The default value of “RewriteEngine" is already an "off", so adding “RewriteEngine off" is quite unnecessary and it may cause confusion to users. :)

Thereby, simply leaving off the configuration parameter "RewriteEngine"
would be enough and ideal.

Related Apache source code snippet:

run_rewritemap_programs(server_rec *s , apr_pool_t *p){
if (conf->state == ENGINE_DISABLED) { // usage of "RewriteEngine"
  return APR_SUCCESS; // early return
rewritemap_program(...); // usage of "RewriteRule" 
}