WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 7 years ago

#13021 closed defect (bug) (wontfix)

Function got_mod_rewrite brakes nginx, lightttpd, cherokee rewrite rules (causes infinite loop redirection)

Reported by: dz0ny Owned by: ryan
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Permalinks Keywords:
Focuses: Cc:

Description

Hi,

today I've been testing new version of WP and noticed that old permalinks (rewrite rules(http://codex.wordpress.org/Installing_WPMU) for other servers than Apache ), stopped working and that Wordpress assumes it's only run on Apache.

After investigating I figured out, that for time being the best way is to define constant in config.php which overrides the detection, and assumes that you taken care of URL rewriting by yourself.

Proposal:

in wp_config.php

define ('FORCE_MOD_REWRITE', true );

and in wp-admin/includes/misc.php

function got_mod_rewrite() {
   if ( defined ( 'FORCE_MOD_REWRITE' ) )
		$got_rewrite = true;
	else
		$got_rewrite = apache_mod_loaded('mod_rewrite', true);
	return apply_filters('got_rewrite', $got_rewrite);
}

Attachments (1)

0001-Support-for-other-servers.patch (1.3 KB) - added by dz0ny 8 years ago.
patch

Download all attachments as: .zip

Change History (7)

#1 @nacin
8 years ago

  • Keywords reporter-feedback added

I'm generally in favor of filters over constants except for server-related config such as this. But, there is a filter there already. I'm not sure I see the infinite loop issue. What's to prevent you from doing:

apply_filters( 'got_rewrite', '__return_true' );

#2 follow-up: @dz0ny
8 years ago

Well suppose we could also rewrite detection function, but I also prefer constats for such things and it "just works".

#3 in reply to: ↑ 2 @dz0ny
8 years ago

Possibly also fixes http://core.trac.wordpress.org/ticket/12973, http://core.trac.wordpress.org/ticket/12255.

Clarification about infinite loop. If someone uses

rewrite ^(.+)$ /index.php?q=$1 last;

the Wordpress generated URL would be somesite.tld/index.php/about which would causes browser infinite loop.

I'am also writing better patch, to detect servers and offer user option to choose whether he is using custom rewrite rules.

#4 @sivel
8 years ago

  • Cc matt@… added
  • Keywords close added
  • Priority changed from high to normal
  • Severity changed from major to normal

I have never experienced any problems with this, and have been running my site on nginx for over 2 years. I have tested using the rewrite that you listed, I have tried removing the checks if the $request_filename exists, and no matter what I haven't been able to duplicate.

I have used both:

if (!-e $request_filename) {
    rewrite . /index.php last;
}

and

if (!-e $request_filename) {
    rewrite ^(.*)$ /index.php?q=$1 last;
}

I have since added the very filter that nacin mentioned so that it does not include the index.php.

In addition we try to use filters for things such as this. I am -1 for a constant.

I am also -1 for rewriting the detection functions. The detection function works the way that it does so that it can without a doubt determine that rewriting is enabled. nginx and lighttpd as well as many others can be compiled without rewrite functionality. In addition rewrites for such servers also requires modification to the server config, and you cannot assume that a user will have access to it.

If you want to give a user the option to choose whether he/she is using custom rewrite rules, I feel that is plugin territory. In general if you think we should add another option to the admin, the rule of thumb is generally that it shouldn't go into core but be implemented as a plugin.

#5 @butuzov
8 years ago

I am using wp with nginx

if (!-e $request_filename) {
     rewrite ^(.+)$ / last;
}


#6 @sivel
7 years ago

  • Keywords reporter-feedback close removed
  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing this ticket as wontfix.

Note: See TracTickets for help on using tickets.