Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets
Wozu ist die .htaccess? In dieser Datei sind die Regeln zur Konfiguration für den Server, hier des namens Apache. WordPress speichert da die Anweisungen, die für die URL-Struktur zuständig ist. Ebenso für die Sicherheit und die Ladezeit der Website gibt es Regeln für die .htaccess Datei. – D. h. sofern diese nicht schon vom Host optimiert sind. Und das ist mit Share-Webhosting-Services dabei. Das ist so ähnlich wie das sogenannte ‘Manget’ für V-Server oder Root-Server. Somit ist folgendes meist, zur Interesse. – es ist evtl. etwas dabei, das dir von Nutzen sein kann.
S. gleich mal .htaccess – Einführung. Es geht hier um das Verständnis zu Funktionsrelationen.
Für firmen Internetsurfer allgegenwärtig, nämlich die Autoren:
Die Artikel von AH (Dr.Web) und DK (FastWP) stellen durchgehende Info, dessen sind hier “Funktion der Befehle (Snippets)” als Merkzettel beinhaltet.
Die
🎼 h’t-a-cc-e-ss Datei – , so-in-etwa: h’t-ac’cess Datei, wie ht.access, im Slogan auch “ha’tǝ-datei”. Also, .htaccess (engl. hypertext access „Hypertext-Zugriff“).
Grundlegend:
Die .htaccess wo Servers einpflegen?
marc bei Dr.Web: Hallo, wenn meine WordPress-Installation in einem Unterverzeichnis liegt, z.B. /wordpress, lege ich die .htaccess dann dort rein oder in das Server-Rootverzeichnis / (und dann zusätzlich auch nochmal in /wordpress?)
Antwort AH: Die .htaccess muss immer in das Rootverzeichnis der WordPress-Installation. Also dahin, wo die Ordner wp-content, wp-admin, wp-includes liegen. Wenn eine Ebene höher dann ein weiterer Ordner /Beispiel mit einer anderen .htaccess liegt, hat das keine Auswirkungen.
Meine Anmerkung: Wenn die .htaccess eine Ebene höher ist als der “wordpress” Ordner, also die .htaccess nicht in einem anderen Ordner, sondern im Serverrootverzeichnis liegt, ist diese für alle unteren Ordner wirksam. Dies gilt des Beispiels für die 6G Firewall und wäre somit ab dem Serverrootverzeichnis für alle Unterordner wirksam. Diese .htaccess ist auch mit #Beginn WordPress … #End WordPress zu erstellen. Weitere .htaccess erstellt sich von selbst im Root vom Ordner “wordpress” mit #Beginn WordPress … #End WordPress – s. Plug-in BBQ und 6G Firewall in .htaccess ⇔ dort Info Button anklicken.
Safety und speed: die optimale .htaccess
Eine optimale Kurzbeschreibung zum Thema finde ich im Titel “WordPress: Die optimale .htaccess” mithin Beitrag von Carsten D. schließt mit den Worten: “Es muss ja nicht jeder das Rad immer wieder neu erfinden”, und auf die .htaccess von AH leitet.
Die sog. ultimative* WordPress .htaccess
nach FastWP
* d. h. endgültig definitive (2018)
Meines Artikel versuche ich die ultimative .htaccess u. ff. nach FastWP aufzuschlüsseln, um ein wenig die Funktionsrelationen zu verstehen.
Browser Caching – Performance
WP-Sicherheit
Beginn zur .htaccess Datei hier folgenden Link: fastwp.de, gerade ist des Links auf den ersten Hinweis betreffs eigenen URL-Namen in <IfModule mod_rewrite.c> zu achten.
.htaccess
# GZIP
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
</IfModule>
<IfModule mod_headers.c>
Header append Cache-Control "public"
Header append Vary Accept-Encoding
Header set Connection keep-alive
Header unset ETag
FileETag None
</IfModule>
# CACHING
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access 60 seconds"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType text/css "access 1 month"
ExpiresByType text/javascript "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{REQUEST_FILENAME} .(jpg|jpeg|png|gif|ico|css|js)$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://([^.]+.)?fastwp. [NC]
RewriteCond %{HTTP_REFERER} !^https?://([^.]+.)?feedly. [NC]
RewriteRule .(jpg|jpeg|png|gif|ico|css|js)$ - [F,NC,L]
</ifModule>
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressDas Obige von .htaccess-Datei
# GZIP IfModule mod_deflate.c und # CACHING mod_headers.c + (Browser Cache) IfModule mod_expires.c, siehe Browser-Cache richtig konfigurieren, fastwp.de.
- Zum Bowser-Cache passt evtl. diese Plug-in-Empfehlung: fastwp.de (Busted: Browser-Cache Reload erzwingen).
IfModule mod_rewrite.c “Hotlinking verbieten”, fastwp.de. Tool zum Überprüfen, und interner Hinweis zum Titel Hotlinking verbieten vs. Translation Website hapert Visualisierung darf nicht fehlen.
Nachfrage Host-Support
Erlaubt bitte die Durchsicht zur .htaccess anzufragen: inwiefern dies zu performen Funktioalität gereicht, oder ob man welches weglassen sollte.
Die Antwort:
… also generell würde ich Caching erst gar nicht benutzen, das mag manchmal helfen, oftmals hat es aber auch negative Auswirkungen. Unsere Systeme sind sicherlich auch so schnell genug.
deflate ist bereits soweit gesetzt und nicht nötig, der Rest kann bleiben und ist wohl WP-Standard. Hinsichtlich HTTP2 muss man nichts dazu optimieren, da tun wir schon alles machbare 🙂
… und des Weiteren:
Dies stellt eine Übersicht für Gebrauch spezifischen Anforderungen.
Cache-Control Headers nutzen
Browser Caching – Performance
Cache-Control Headers nutzen, diesen Codes fastwp.de (im obigen Bereich).
.htaccess
<IfModule mod_headers.c> <filesMatch ".(jpg|jpeg|png|gif|ico)$"> Header set Cache-Control "max-age=31536000, public" </filesMatch> <filesMatch ".(css|js)$"> Header set Cache-Control "max-age=2628000, public" </filesMatch> Header set Cache-Control "max-age=3600, public" </IfModule>
Fonts: Caching und Komprimierung
Browser Caching und Komprimierung – Performance
Für selbst gehostete Webfonts, hierzu Punkt drei nach fastwp.de
.htaccess
AddType font/ttf .ttf AddType font/otf .otf AddType font/woff .woff ExpiresByType font/ttf "access plus 1 year" ExpiresByType font/otf "access plus 1 year" ExpiresByType font/woff "access plus 1 year" AddOutputFilterByType DEFLATE font/ttf AddOutputFilterByType DEFLATE font/otf AddOutputFilterByType DEFLATE font/woff
XML-RPC deaktivieren + XML-RPC aus dem HTTP-Header entfernen
WP-Sicherheit und Performance
Hierzu separater Beitrag in WordPress absichern.
Für die htaccess-Datei bleibt dessen Zusammenhangs:
.htaccess
<Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
Schutz vor Script Injections Options +FollowSymLinks
WP Sicherheit
Originär: Betrifft GET- und POST-Anfragen, welche meist sorgfältig geschützt sind, aber was ist mit den GLOBALS und _REQUEST-Variablen? Die werden meistens nicht sunderlich behandelt, weshalb folgender Befehl in der .htaccess für mehr Sicherheit sorgt. Dieser blockt Script Injections und Versuche, die entsprechenden Variablen zu verändern.
.htaccess
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]Bemerkung: Dieses Snippet Options +FollowSymLink in der .htaccess-Datei Server-Rootverzeichnises erfolgt meiner Website ein Server-Error, wie ebenso in Ordner “wordpress” befindlichen .htaccess-Datei ungeeignet, da zwar kein Error erfolgt, aber das jQuery Accordion Menü ungeeignet dargestellt ist –. des Letzterem logo.
Dateien wp-config.php und
.htaccess vor Zugriff schützen
WP-Sicherheit
Wichtige Dateien vor fremden Zugriff zu schützen. Die „wp-config.php“ und die „.htaccess“ sind wichtige Dateien, die man mit folgendem Befehl absichern kann:
.htaccess
# Dateien vor Zugriff schützen <Files wp-config.php> Order Allow,Deny Deny from all </Files> <Files .htaccess> Order Allow,Deny Deny from all </Files> <files readme.html> Order Allow,Deny Deny from all </Files>
Ordneransicht verbieten
WP-Sicherheit
Durchsuchen von Verzeichnissen deaktivieren.
Hier am Host “bplaced-Server” nicht als “Options All -Indexes”, wie es meist empfohlen ist:
.htaccess
Options -Indexes
… ist funktionell.
WP Content schützen mit eigener .htaccess-Datei im Ordner “wp-content”
WP-Sicherheit
Für potenzielle Angreifer gibt es weitere Schlupflöcher. Dies kann auch im Ordner „wp-content“ geschehen, weshalb diese eigene .htacess-Datei erhalten sollte, welche selbst erstellt werden muss. Des Ordners wp-content Problem ist, dass auch Plugins etc. auf Dateien zugreifen dürfen.
Auf Bilder, xml, sowie CSS-Dateien darf mit folgenden Befehl weiterhin zugegriffen werden, alle anderen Anfragen werden geblockt. Das kann Uneinsichts Probleme verursachen, je nachdem welche Erweiterungen innerhalb von WordPress genutzt werden.
Ordner/Verzeichnis wp-content .htaccess
Order Deny,Allow Deny from all <Files ~ ".(xml|css|jpe?g|png|gif|js)$"> allow from all </Files>
Bemerkung: Im Ordner „wp-content“ entsprechende .htaccess mit dessen Snippet funktioniert im Gesamten das “jQuery Accordion Menü” nicht! – d. h. auch ohne js usw.
XXS Security, nosniff und mehr
WP-Sicherheit
Nächst, informativ: Punkt 7. Datei-Bearbeitung verhindern: fastwp.de. Der Link ist nicht mehr aktiv!
Um einfache XXS-Attacken abzuwehren, Clickjacking zu verhindern und ähnliches. Ein kleiner Rundumschutz:
.htaccess
# XXS Security, nosniff und mehr <ifModule mod_headers.c> Header set X-XSS-Protection "1; mode=block" Header always append X-Frame-Options SAMEORIGIN Header set X-Content-Type-Options: "nosniff" </ifModule> # WP-Include Dateien blocken <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^wp-admin/includes/ - [F,L] RewriteRule !^wp-includes/ - [S=3] RewriteRule ^wp-includes/[^/]+.php$ - [F,L] RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F,L] RewriteRule ^wp-includes/theme-compat/ - [F,L] </IfModule>
Block Bad Queries (BBQ) Plug-in
WP-Sicherheit
Siehe WordPress absichern – Entsprechendes in die .htaccess oder (besser, FastWP) das Plug-in anwenden.
SEO
Implementierung von X-Robots-Tag mit Apache für pdf-Dateien und Bilder
Das X-Robots-Tag kann man den HTTP-Antworten einer Website hinzufügen. Hierzu ist die .htaccess– und httpd.conf-Dateien zu verwenden (standarts auf Apache-basierten Webservern). Die Verwendung eines X-Robots-Tags in Verbindung mit HTTP-Antworten hat den Vorteil, dass Crawling-Anweisungen angeben werden, die für die gesamte Website gelten. Die Unterstützung regulärer Ausdrücke ermöglicht Flexibilität.
Wer zum Beispiel das X-Robots-Tag noindex, nofollow für alle PDF-Dateien auf einer Website der HTTP-Antwort hinzufügen möchte, folgende Snippet in die .htaccess- oder httpd.conf-Stammdatei der Website einfügen:
.htaccess
<Files ~ ".pdf$">
Header set X-Robots-Tag "noindex, nofollow"
</Files>Das X-Robots-Tag bei Nicht-HTML-Dateien wie z. B. Bilddateien kann man anwenden, bei denen die Verwendung von Robots-Meta-Tags nicht möglich ist. Beispiel für das Hinzufügen einer noindex-X-Robots-Tag-Anweisung für PNG-, JPEG-, JPG- und GIF-Bilddateien auf einer ganzen Website.
.htaccess
<Files ~ ".(png|jpe?g|gif)$">
Header set X-Robots-Tag "noindex"
</Files>Siehe, Google Search: Spezifikationen.
Aktualisiert im Jahr 2021-Dezember
Wird geladen ...