Het standaard .htaccess-bestand van WordPress, en veilige toevoegingen
Gids voor .htaccess in WordPress
Standaard .htaccess-bestand van WordPress (één site en multisite) | We.Inc
De standaard .htaccess-regels van WordPress voor één site, multisite met submappen en met subdomeinen, plus veilige toevoegingen die wp-config.php blokkeren en HTTPS afdwingen. Maak en kopieer de uwe.
WordPress op Apache heeft een kort .htaccess-blok in de hoofdmap van de site nodig dat elk verzoek voor een bestand of map die niet bestaat naar index.php stuurt. Daardoor werken nette permalinks. Plak het blok tussen # BEGIN WordPress en # END WordPress en zet uw eigen regels boven die markeringen.
Herschrijvingen zijn relatief aan de hoofdmap van de site
RewriteRule ^index\.php$ - [L]
Verzoeken voor index.php zelf blijven ongemoeid
RewriteCond %{REQUEST_FILENAME} !-f
Alleen als er geen echt bestand overeenkomt
RewriteCond %{REQUEST_FILENAME} !-d
En er geen echte map overeenkomt
RewriteRule . /index.php [L]
Geef al het andere aan WordPress
Een kapotte .htaccess zie je meestal doordat elke pagina behalve de homepage een 404 geeft, of doordat de hele site na een wijziging door een plugin een 500-fout geeft. Kies hieronder uw installatietype, kies de extra's die u wilt en kopieer een compleet bestand. Het WordPress-deel komt overeen met de regels in de ontwikkelaarsdocumentatie van WordPress.
Kies één site, multisite met submappen of multisite met subdomeinen.
Vink de extra's aan die u wilt. Elk ervan komt boven de WordPress-markeringen, zodat WordPress het nooit overschrijft.
Kopieer het bestand, maak een back-up van uw huidige .htaccess en upload het nieuwe naar de map met wp-config.php.
Laad een bericht en het beheergedeelte om te controleren, ga dan naar Instellingen, Permalinks en klik op Opslaan zodat WordPress zijn regels controleert.
Bewaar een kopie van het werkende bestand voordat een plugin eraan komt. Een bestand herstellen waarvan u weet dat het werkt, gaat sneller dan een 500-fout debuggen.
Als u de hoofdconfiguratie van Apache kunt bewerken, zet deze regels dan daar. Volgens de documentatie van Apache kost .htaccess bij elk verzoek een opzoeking in elke map.
Bewerk nooit met de hand tussen de markeringen BEGIN en END WordPress. WordPress kan dat deel herschrijven als de permalinkinstellingen worden opgeslagen.
Nginx negeert .htaccess volledig. Op een Nginx-host doet een try_files-regel in het server-blok hetzelfde werk.
Veelgestelde vragen
Waar staat het .htaccess-bestand in WordPress?
In de hoofdmap van de WordPress-installatie, naast wp-config.php en de map wp-content. De naam begint met een punt, dus bestandsbeheerders en FTP-clients verbergen het vaak tot u verborgen bestanden zichtbaar maakt.
Hoe herstel ik de standaard .htaccess van WordPress?
Vervang de inhoud van het bestand door het blok voor één site op deze pagina, of hernoem het kapotte bestand, ga in het beheer naar Instellingen, Permalinks en klik op Opslaan. WordPress schrijft een nieuw blok als het naar het bestand kan schrijven.
Waarom krijg ik 404-fouten op elke pagina behalve de homepage?
Bijna altijd ontbreken de rewrite-regels of staat mod_rewrite uit. De homepage laadt omdat die index.php zelf is; elke nette permalink heeft de regel nodig die onbekende paden naar index.php stuurt.
Welk multisite-blok heb ik nodig?
Het blok dat past bij hoe het netwerk is geïnstalleerd. Sites op example.com/shop gebruiken het blok voor submappen; sites op shop.example.com gebruiken het blok voor subdomeinen. Ze verschillen in hoe ze het siteprefix uit wp-admin en bestandspaden halen.
Is het veilig om toegang tot wp-config.php te blokkeren in .htaccess?
Ja. PHP leest wp-config.php van de schijf, niet via het web, dus webverzoeken ernaar weigeren heeft geen invloed op de site. De documentatie van WordPress raadt dezelfde FilesMatch-regel aan als hier.
Hoe het herschrijven werkt
Apache leest de voorwaarden van boven naar beneden. Een verzoek voor een echte afbeelding of stylesheet past bij -f en wordt direct geserveerd, een verzoek voor een echte map past bij -d, en al het andere valt door naar index.php, waar WordPress het bericht, de pagina of het archief voor dat adres opzoekt.
De HTTP_AUTHORIZATION-regel kopieert de Authorization-header naar een variabele die PHP kan lezen. Bij sommige serverinstellingen ziet PHP die header anders nooit, waardoor logins via die header niet werken.
Waar uw eigen regels komen
Zet redirects, HTTPS-regels en toegangsblokkades boven # BEGIN WordPress. Regels worden op volgorde uitgevoerd, dus een redirect na het WordPress-blok zou voor de meeste URL's nooit worden bereikt.
Houd toevoegingen beperkt en getest. Elke regel draait bij elk verzoek, en een typfout waar dan ook in het bestand haalt de hele site onderuit met een 500-fout.
De drie officiële WordPress-blokken
Dit zijn de regels die WordPress per installatietype documenteert. Gebruik er precies één.
Eén site
Het blok voor een normale WordPress-site die in de webroot is geïnstalleerd.
Multisite met submappen
Voor netwerken waarin elke site op een pad staat zoals example.com/shop/.
Multisite met subdomeinen
Voor netwerken waarin elke site een eigen subdomein heeft zoals shop.example.com.
Veilige toevoegingen
Elk hiervan komt boven # BEGIN WordPress. Voeg er één tegelijk toe en laad de site na elke toevoeging opnieuw.
Webtoegang tot gevoelige bestanden weigeren
Gebruikt de Require-directive van Apache 2.4, dus een oudere 2.2-server heeft in plaats daarvan de oude Order- en Deny-syntax nodig.
HTTPS afdwingen
Een permanente 301-redirect die host en pad behoudt. Als uw host een HTTPS-schakelaar in het paneel heeft, gebruik die dan en sla dit over.
.htaccess-builder
Installatietype van WordPress
Eén site
Multisite, submappen
Multisite, subdomeinen
Extra's boven het WordPress-blok
Webtoegang blokkeren tot wp-config.php, .htaccess, .htpasswd en debug.log
Elk http://-verzoek doorsturen naar https://
Voorkomen dat Apache de inhoud van mappen zonder indexbestand toont
Uw .htaccess-bestand
Zet de HTTPS-redirect pas aan als uw certificaat werkt, anders krijgen bezoekers een browserwaarschuwing.