WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 19 months ago

#12670 closed enhancement (wontfix)

Non-standard htaccess filename breaks mod-rewrite setup

Reported by: thedotproduct Owned by: ryan
Milestone: Priority: normal
Severity: normal Version: 2.9.2
Component: Administration Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (3)

htaccess.diff (1.5 KB) - added by meheranandk 5 years ago.
12670.001.diff (2.2 KB) - added by aaroncampbell 5 years ago.
12670.002.diff (2.5 KB) - added by aaroncampbell 5 years ago.
Patch using constant

Download all attachments as: .zip

Change History (20)

comment:1 @thedotproduct5 years ago

  • Component changed from Administration to Rewrite Rules
  • Owner set to ryan

comment:2 @thedotproduct5 years ago

  • Component changed from Rewrite Rules to Administration

comment:3 @nacin5 years ago

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.

comment:4 @nacin5 years ago

  • Keywords needs-patch added; htaccess mod-rewrite removed
  • Milestone changed from Unassigned to Future Release
  • Type changed from defect (bug) to enhancement

@meheranandk5 years ago

comment:5 @meheranandk5 years ago

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');

comment:6 @meheranandk5 years ago

  • Keywords has-patch added; needs-patch removed

comment:7 @meheranandk5 years ago

  • Owner changed from ryan to meheranandk
  • Status changed from new to accepted

comment:8 follow-up: @meheranandk5 years ago

  • Owner changed from meheranandk to ryan
  • Status changed from accepted to assigned

comment:9 in reply to: ↑ 8 @meheranandk5 years ago

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

comment:10 follow-up: @nacin5 years ago

  • Keywords needs-patch added; has-patch removed

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.

comment:11 in reply to: ↑ 10 @meheranandk5 years ago

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?

comment:12 @dd325 years ago

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

comment:13 @aaroncampbell5 years ago

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.

@aaroncampbell5 years ago

comment:14 @nacin5 years ago

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

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

comment:15 @aaroncampbell5 years ago

  • Keywords has-patch added; needs-patch removed

Here's the patch as a constant.

@aaroncampbell5 years ago

Patch using constant

comment:16 @nacin5 years ago

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"

comment:17 @dd3219 months ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.