WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 6 months ago

#27624 new enhancement

Add a filter to override the location of htaccess file

Reported by: Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: General Keywords: needs-patch
Focuses: multisite Cc:
PR Number:

Description

It's a bit convoluted to override the location of the htaccess file when WP is installed in a subfolder and fails to identify that it is so. One basically needs to override the entire save_mod_rewrite_rules() function after disabling the default call.

Would it be possible to add a filter in save_mod_rewrite_rules(), or perhaps even more ideally in get_home_path(), so as to be able to do this in a simpler manner?

Change History (6)

#1 follow-up: @jesin
6 years ago

when WP is installed in a subfolder and fails to identify that it is so.

I have not come across this problem. When I install WordPress inside a sub directory the RewriteBase directive contains the sub directory path.

Please describe what you did that prevented WordPress from identifying the subfolder.

#2 in reply to: ↑ 1 @Denis-de-Bernardy
6 years ago

Replying to jesin:

Things are thornier in multisite, or were at any rate until 3.8.1 (might be fixed now). At any rate, get_home_path() returns an invalid path in some cases, and it's an unfiltered one at that. In particular if you add rewrite rules to make WP urls look like /wp-admin instead of /wp/wp-admin using a plugin.

#3 @johnbillion
6 years ago

  • Focuses multisite added
  • Keywords reporter-feedback added
  • Version changed from trunk to 3.0

Does this only affect Multisite?

As jesin mentioned, I've never seen this problem before either. Do you have some steps to reproduce?

#4 @Denis-de-Bernardy
6 years ago

  • Keywords reporter-feedback removed

To reproduce, install WP in a subfolder, use the MS rewrite rules of a subfolder install in a normal install to make the wp-admin area available without the wp subfolder prefix (/wp-admin instead of /wp/wp-admin), and then filter siteurl so it returns the home url.

Admittedly, it's an edge case that hardly effects anyone, and I'd have never run into it had I not sought to fix the bloody /wp-admin/network urls that WP is returning when WP in a /wp subfolder.

Regardless of that fact, the matter at hand is that get_gome_path() often returns an incorrect value in a number of use-cases with WP in a subfolder when trying to fix WP for various reasons -- as does guess_url(). I found means to fix most of the bugs I ran into using a plugin, and opened or subscribed to tickets that related to the heaps issues I ran into while probing into this. The only bit I failed to resolve in a satisfactory manner is the get_home_path() part: I end up hooking on the rewrite_flush_hard hook, or whatever it's called, and returning false after essentially rewriting the insert_with_markers() function, in order to prevent WP from polluting a git repo where it doesn't ignore the htaccess file it creates.

#5 @Denis-de-Bernardy
6 years ago

Actually there *is* another "rip my hair out and curse at WP" issue I ran into in point of fact: the mod_rewrite_rules are returned by $wp_rewrite as an unfiltered empty string when permalinks are off.

So as part of the ticket, another filter on the rules that *actually* get written would be sweet.

I'll post the final plugin in here for reference to show a concrete use-case -- which frankly, should be wholesale WP patches, but the WP trac has a well-deserved reputation of being a place where good things go to die, and indeed the numerous patched I submitted in tickets to my bug fixes plugin are rotting as I write...

Last edited 6 years ago by Denis-de-Bernardy (previous) (diff)

#6 @chriscct7
4 years ago

  • Keywords needs-patch added

This seems super edge case.

Note: See TracTickets for help on using tickets.