這個 wordpress .htaccess 規則有什麼作用?
在 WordPress 4.7 多站點子域安裝的預設 .htaccess 規則中,我試圖了解一個特定規則的目的。
首先,我將自行介紹規則
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
孤立地,對我來說,該規則似乎只是將 wp-content 或 wp-admin 或 wp-includes 中的任何 url 重寫為自身。由於它是在文件系統檢查之後出現的,我們知道它在文件系統上不存在,所以我不知道它試圖做什麼。
現在這裡是建議的 .htaccess 文件的全部內容。規則是倒數第三個。
RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] # add a trailing slash to /wp-admin RewriteRule ^wp-admin$ wp-admin/ [R=301,L] RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ - [L] RewriteRule ^(wp-(content|admin|includes).*) $1 [L] RewriteRule ^(.*\.php)$ $1 [L] RewriteRule . index.php [L]
任何人都可以擺脫的任何見解都會很棒。我收到一個錯誤 - “由於可能的配置錯誤,請求超出了 10 個內部重定向的限制。” - 每當有人試圖訪問 wp-content/ 之外不存在的任何目錄時。我希望改為404。
對於它的價值,這似乎是這張票的長期 WP 問題
https://core.trac.wordpress.org/ticket/20746
那裡有修復建議,但我想了解我在那裡部署的任何更改,因為它不會是“官方 WP”。我認為了解該規則如何導致除自我重寫之外的任何事情將有助於我對部署建議的更改之一充滿信心。
**編輯:**這是正在應用的規則的範例:
[rid#7f58a5a5dcb0/initial/redir#2] [perdir /var/www/wordpress/] applying pattern '^(wp-(content|admin|includes).*)' to uri 'wp-content/invalid_directory/nothing.png' [rid#7f58a5a5dcb0/initial/redir#2] [perdir /var/www/wordpress/] rewrite 'wp-content/invalid_directory/nothing.png' -> 'wp-content/invalid_directory/nothing.png' [rid#7f58a5a5dcb0/initial/redir#2] [perdir /var/www/wordpress/] add per-dir prefix: wp-content/invalid_directory/nothing.png -> /var/www/wordpress/wp-content/invalid_directory/nothing.png [rid#7f58a5a5dcb0/initial/redir#2] [perdir /var/www/wordpress/] trying to replace prefix /var/www/wordpress/ with / [rid#7f58a5a5dcb0/initial/redir#2] strip matching prefix: /var/www/wordpress/wp-content/invalid_directory/nothing.png -> wp-content/invalid_directory/nothing.png
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
我認為該指令的主要目的是在請求開始的
index.php
URL或./wp-content``/wp-admin``/wp-includes
通過重寫自身,URL 不變地通過並且處理停止。
但是,生成的替換也是relative,因此任何聲明為 的
RewriteBase
內容也將作為重寫 URL 的前綴。在這種情況下,它RewriteBase
是簡單的/
,因此它確實在第一遍時被重寫為自身(假設此.htaccess
文件位於文件根目錄中)。我認為這一定是故意的,否則他們會使用連字元 (-
) 作為替換,如上面的指令中所示。這個“不應該”導致重寫循環,因為如果 URL 未更改通過,處理應該停止(重寫本質上是“忽略”)。
但是,為了確保它沒有改變,您可以簡單地在替換中替換
$1
with 。-``RewriteRule
如果您啟用完全重寫調試,例如。
LogLevel rewrite:trace6
在 Apache 2.4+ 的伺服器配置中,您應該確切地看到正在發生的事情,因為它應該顯示重寫的每次迭代。