Excludează o cale din WordPress folosind redirectări .htaccess (Apache)
Doresc să exclud o cale care se potrivește cu o regulă din încărcarea WordPress. Modul normal în care aș aborda această problemă este folosind flag-ul final [L]
într-o regulă înaintea tuturor celorlalte.
Pentru a păstra lucrurile simple în acest exemplu, voi pretinde că vreau să potrivesc o cale simplă /foo/
.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^foo/?$ - [L]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Totuși, aceasta nu funcționează. Câteva alte opțiuni sunt sugerate în acest post mai vechi de pe Stack Overflow, dar niciuna dintre ele nu funcționează (nici pentru mine, nici pentru alții în comentariile acelui post).
Am încercat și această condiție de rescriere în locul regulii:
RewriteCond %{REQUEST_URI} ^/?(foo/.*)$
Precum și adăugarea ErrorDocument 401 default
la sfârșitul documentului .htaccess
.
Ar trebui să folosești RewriteCond
în loc de RewriteRule
. Folosește acest lucru:
RewriteCond %{REQUEST_URI} !/foo/
De exemplu, codul complet ar putea arăta astfel:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_URI} !/foo/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

O mică problemă este că va trebui să actualizați RewriteRule ./
în penultima linie. Iată un fragment actualizat (și testat) pentru dumneavoastră:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_URI} !^/foo/.*$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ./ /index.php [L]
</IfModule>
# END WordPress
Am testat ambele:
Sper că vă ajută!!

Asta a fost, mulțumesc. Deși nu sunt sigur de ce .
nu ar fi putut să corespundă cu ./
, ar fi trebuit să se potrivească cu ambele. Pentru oricine altcineva care întâmpină această problemă în viitor: am optimizat ușor prin schimbarea la ./?
și am creat un serviciu rapid pentru a verifica fișierul .htaccess
și a mă asigura că unele pluginuri sau actualizări nu l-au suprascris/resetat.

@Orun nu este o idee bună să configurezi un serviciu care să interzică modificarea fișierului. în schimb, doar acea parte ar trebui monitorizată, deoarece multe pluginuri utile scriu alte blocuri, care nu ar trebui interzise.

Da, sunt de acord. Fișierul este încă complet modificabil. De fapt, aveam deja un serviciu care scrie propriul meu bloc în .htaccess
în cadrul temei mele, așa că doar l-am extins. Acesta caută doar o anumită linie, o modifică dacă o condiție este îndeplinită și apoi înregistrează modificarea într-un jurnal special.

Următoarea regulă funcționează pentru mine
RewriteRule ^(foo)($|/) - [L]
adică, orice cale care începe cu foo precum /foo/, /foo/bar/ sau orice altceva, duce la eroarea 404 a Apache în loc de eroarea 404 a temei; cu presupunerea că nu există un director real cu această cale.
Regula trebuie să fie înaintea ultimei linii standard a blocului WordPress:
RewriteRule . /index.php [L]
Și nu contează cu adevărat dacă este după RewriteBase /
, poate fi înaintea acesteia; anterior a fost formulată pripit și neglijent din partea mea.
Ceea ce v-ar oferi șansa de a lăsa blocul dintre # BEGIN WordPress
și # END WordPress
neatins, dacă doriți să faceți acest lucru. Prin plasarea
<IfModule mod_rewrite.c>
RewriteRule ^(foo)($|/) - [L]
</IfModule>
înaintea # BEGIN WordPress
.
S-ar putea să doriți să preveniți crearea căii /foo/ în WordPress, acest lucru mi-a venit în minte:
add_filter( 'wp_unique_post_slug', 'no_more_foo_wp_unique_post_slug', 2, 6 );
function no_more_foo_wp_unique_post_slug(
$slug, $post_ID, $post_status, $post_type, $post_parent, $original_slug
) {
if ( $post_parent === 0 ) {
$pattern = '/^foo$/';
$replace = 'bar';
$slug = preg_replace( $pattern, $replace, $slug );
}
return $slug;
}

Ai dreptate, ar fi trebuit să setez regula după baza, nu sunt sigur de ce am făcut-o înainte în acest post! De fapt, în fișierul .htaccess
de producție era setată după. Mulțumesc că ai menționat totuși. A fost o omisiune din partea mea când am editat markdown-ul aici.
