Non-standard htaccess filename breaks mod-rewrite setup

[thedotproduct]

I use a non-standard .htaccess filename and thus the mod-rewrite for permalinks didn't work for me as the admin script wrote to a file called .htaccess - this also made my wordpress site throw an HTTP 500 error due to the "missing" .htaccess file

I think it would be worth adding a check to see what the .htaccess filename is before writing it (the Apache config var is called "AccessFileName")

I have worked around the problem by creating a symlink from the filename I use to .htaccess.

[nacin]

IIRC, it's not possible to check the Apache value via PHP. Best we could do is add a filter in WordPress that would allow you to tell WP to look elsewhere.

[meheranandk]

I could not create a patch for wp-config.php because it is generated on install. One can add the following code to the file and change .htaccess to the desired name to fix the issue.

/** .htaccess filename. Change only if your webserver is using a different htaccess filename */
define('HTACCESS_NAME','.htaccess');

[meheranandk]

Replying to meheranandk:
@Ryan: Sorry. Goofed up a little bit. I'm a bit new to all this source code management stuff.

[nacin]

Three things:

I'm pretty sure we use .htaccess in more places than that. A very quick grep finds 33 matches in five files, though many of those are in strings, variable names, or inline documentation. (Strings probably could use an edit in this case.)

We may want to use a filter instead of a constant, as we have been gravitating in that direction in general. Constant IMO probably makes more sense here, but it's just a thought.

If we do use a constant, though, then we would add it to default-constants.php (see syntax/examples there) and allow it to be optionally set first in wp-config.php. Among other things, wp-config.php is not overridden or touched in upgrades, so your constant would be unavailable to existing installs.

[meheranandk]

Replying to nacin:
If we use a constant in default-constants.php, the constant will get overridden after an upgrade, right? Correct me if I am wrong. It makes more sense in wp-config for this reason: All server related constants such as DB server, host etc reside in that file. htaccess file name too is server related so all of them fit well.

And yes, .htaccess can be changed in strings as well. Shall I upload a new patch for that?

[dd32]

If we use a constant in default-constants.php, the constant will get overridden after an upgrade, right? Correct me if I am wrong. It makes more sense in wp-config for this reason

default-constants would be wrapping it in a if ( ! defined()) check.

The way the constants work is that they're optionally defined in wp-config.php, else they're defined in default-constants.php to the WordPress default value.

I'd prefer a filter over a constant however myself

[aaroncampbell]

Here are my thoughts:

1. Apache doesn't supply "AccessFileName" to PHP, so there's no way to detect it.
2. While .htaccess occurs 21 times, most of those are in comments or strings.
3. I agree with dd32 that I would prefer a filter. I propose using 'access_file_name' and I'm attaching a patch that will take care of this.
4. Since I think think this will only affect a very small group of people, I don't really think we need to change the strings. However, since this is a filename, we could just drop a %s into those strings (probably the right way to do this anyway) and pass the filtered filename. There are currently 5 translated string that would need to be adjusted.

[nacin]

1, 2 had reiterated what was stated above. :-)

3. A constant honestly makes more sense here. I also asked Ryan, FWIW, and he agreed. It's a server-level and server-specific configuration, and we shouldn't be requiring an mu-plugin for this, it makes sense as a constant -- as much as I agree we should otherwise be moving away from them. (This was briefly discussed in IRC, I just never posted here.)

4. I'm actually hesitant to change the strings, so I agree with your assessment there. Administrators should know when they're using a custom access file name and make the connection.

[aaroncampbell]

Here's the patch as a constant.

[aaroncampbell]

Patch using constant

[nacin]

From IRC, which I'd tend to agree with:

[19:22] <AaronCampbell> sivel said "if you want my honest opinion I don't think any of the patches shoudl go in. if you are running a custom apache install like that you should probably be sticking the rewrite rules in the vhost config instead of a .htaccess file to begin with"

[dd32]

Based on all of the above, which I'm agreeing with, wontfix for now.