define( 'WP_PLUGIN_DIR', '/srv/www/htdocs/html/plugins' );
define( 'WP_PLUGIN_URL', 'http://subdomain.example.org/plugins' );

http://codex.wordpress.org/Determining_Plugin_and_Content_Directories#Constants

Dafür müssen wir analog zum Uploads Ordner auf der angelegten Subdomain (subdomain.example.org) einen Ordner “plugins” anlegen. Dorthin würde dann der ganze Inhalt des ursprünglichen Plugins Ordner verschoben.
Außerdem Voraussetzung: Alle Plugins müssen vernünftig von den Plugin-Autoren geschrieben sein.

Für uns klären wir erst noch, ob Nutzen oder Aufwand überwiegt.

Verwandte Artikel

• WordPress: CDN und cookieless domain (3)
• gzip-Komprimierung aktivieren (1)
• Etwas Sicherheit durch die .htaccess (1)
• Caching mit Expires (0)
• WordPress-Plugin: Remove Dashboard Widgets (14)

RewriteEngine on

Jetzt kann die Datei vor externen Zugriffen geschützt werden, um die es sich die ganze Zeit dreht … die .htaccess:

# htaccess Schutz
<Files ~ "^.*\.([Hh][Tt][Aa])">
Order deny,allow
Deny from all
</Files>

ORDER bestimmt in welcher Reihenfolge Allow und Deny ausgewertet werden.
Die Direktive DENY (=verweigern) bestimmt, wer vom Zugriff auf eine Ressource ausgeschlossen wird
Die gegensätzliche Direktive ALLOW (=erlauben) würde es ermöglichen, bestimmten Hosts den Zugriff ausdrücklich zu gestatten.

Das ganze ließe sich so erweitern, dass alle Dateien die mit einem Punkt anfangen, wie z.B. auch eine .htusers oder .htpasswd, gesperrt werden:

# Dateien mit . am Anfang sperren
<FilesMatch "^\." >
Order deny,allow
Deny from all
</FilesMatch>

So, die Dateien sind schon mal vor einem Fremdzugriff gesperrt. Jetzt kommt es ja immer mal wieder vor, dass man die eigenen Bilder auf anderen Seiten verlinkt sieht. Das ist doppelt ärgerlich:

1. wird der eigene Inhalt wo anders abgebildet
2. wird der eigene Traffic geklaut, denn die Bilder werden ja nur verlinkt … also vom eigenen Server auf fremder Seite ausgeliefert.

Auch dafür gibt es einen Trick:

# Bilder-Klau
<ifmodule mod_rewrite.c>
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?im-tal\.net(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?images\.google\.de(/.*)?$ [NC]
RewriteRule \.(gif|jpg|png|pdf|zip|GIF|JPG|PNG|PDF|ZIP)$ - [F]
</ifmodule>

In Zeile 2 wurde die eigene Domain eingetagen.
In Zeile 3 wurde eine weitere “erlaubte” Domain eingetragen.
Diese Zeile kann kopiert werden und für jede weitere erlaubte Domain verwendet werden, Prinzip sollte hier klar sein.
Als letzte Zeile wird bestimmt, dass alle nicht aufgeführten und somit auch nicht erlaubten Domains eine Error 403 (Forbidden) Fehlermeldung bekommen, sobald sie eine Bild der genannten Dateitypen verlinken wollen.
Falls die o.g. Variante nicht funktioniert kann folgender Code probiert werden:

<Files ~ "\.(gif|jpe?g|png)$">
SetEnvIfNoCase Referer ^http\:\/\/.* Verboten
SetEnvIfNoCase Referer ^http\:\/\/(www\.){0,1}im-tal\.net.* !Verboten
SetEnvIfNoCase Referer ^http\:\/\/(images\.){0,1}google\.de.* !Verboten
Order Allow,Deny
Deny from env=Verboten
Allow from all
</Files>

In Zeile 2 werden erst mal alle Zugriffe verboten und durch die Zeile mit !Verboten werden dann die Ausnahmen definiert.

Ist die IP oder der USER_AGENT eines Angreifers bekannt oder ein Query_String der öfter von Angreifern an die URL gehangen wird, so kann auch dieser direkt ausgesperrt werden. Außerdem können auch Referer ausgesperrt werden:

<ifmodule mod_rewrite.c>
# alle Einträge mit [OR] abschließen außer der letzte
RewriteCond %{REMOTE_ADDR} ^123\.234\.3\.4 [OR]
RewriteCond %{HTTP_USER_AGENT} example.* [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{HTTP_REFERER} spamwort [NC]
RewriteRule .* - [F,L]
</ifmodule>

NC gibt an, dass kein Unterschied zwischen Gross- und Kleinschreibung gemacht werden soll
OR gibt an, dass ODER statt UND verwendet werden soll

So, zum Schluss noch 2 weitere Tipps, besonders für WordPress Benutzer. Bei WordPress ist es wichtig die Settings-Datei “wp-config.php” zu schützen. In anderen Systemen sind es vielleicht andere Dateien. Jedenfalls funktioniert dies genau so wie oben beim .htaccess Schutz:

# protect wp-config.php
<files wp-config.php>
Order deny,allow
Deny from all
</files>

Um jetzt noch externe Zugriffe auf WordPress PHP-Dateien zu blockieren, kann folgendes in die .htaccess geschrieben werden:

# Externer Zugriffe auf PHP-Dateien blockieren
RewriteCond %{QUERY_STRING} !error
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(wp-includes|wp-content)/(.+)\.php\ HTTP/
RewriteRule .* - [F]

Verwandte Artikel

• gzip-Komprimierung aktivieren (1)
• Caching mit Expires (0)
• WordPress: CDN und cookieless domain (3)
• WordPress Plugins verschieben (0)
• noindex und nofollow (1)

Wir haben den Artikel von Frank Bültge über Eigenes CDN in WordPress nutzen gelesen. Sehr schöner Artikel Frank. Bisher haben wir es mit dem selben Gedanken über Subdomains aber etwas undynamischer gelöst. Mal schauen wie wir es die nächsten Wochen weiter optimieren können. Aber erstmal stellen wir jetzt unsere bisherige Lösung vor:
Wie erwähnt haben wir auch den Uploads Ordner, der zur Mediathek von WordPress gehört, auf einer Subdomain ausgelagern. Dafür haben wir eine Subdomain angelegt (subdomain.example.org) und dort einen Ordner “uploads” mit den üblichen CHMOD-Rechten 777 anlegen. Dorthin wurde dann der ganze Inhalt des urspünglichen Upload Ordner verschoben.
In den Mediathek-Einstellungen haben wir dann den “Ordner-Pfad” auf den statischen Serverpfad geändert und den “Kompletter Pfad zu den Dateien” auf die URL geändert, z.B.
Uploads in folgendem Ordner speichern: /srv/www/htdocs/html/uploads
Kompletter Pfad zu den Dateien: http://subdomain.example.org/uploads

Dann müssen wir allerdings in der Datenbank die Einträge in der Tabelle “wp_posts” ändern, genauer dort die Felder “post_content” und “guid”. Das kann mit folgenden zwei “Replace” (ersetzen) SQL-Befehlen erledigt werden:

UPDATE wp_posts SET post_content = replace(post_content, 'http://www.example.org/wp-content/uploads/', 'http://subdomain.example.org/uploads/');
UPDATE wp_posts SET guid = replace(guid, 'http://www.example.org/wp-content/uploads/','http://subdomain.example.org/uploads/');

Somit hätten wir dann alle Mediatheken Bilder auf der Subdomain liegen und sie werden von dort abgerufen.

Als zweiten Schritt sind wir her gegangen und haben alle Bilder aus dem Theme (Images Ordner im Theme Ordner) auch auf die Subdomain in einen Images Ordner verschoben. Danach nur noch alle Templates des verwendeten Themes (style.css, header.php, footer.php, functions.php etc.) auf den korrekten Pfad ändern. Statt bloginfo() müssen dann die statischen Pfade angegeben werden.
Aus z. B.

src="<?php bloginfo('template_url'); ?>/images/

wird dann

src="http://subdomain.example.org/images/

Wie Frank auch in seinem Artikel schreibt, hat Google (PageSpeed) damit keine Probleme und hakt es im besten Fall mit der Note “A” ab. Leider verlangt Yahoo (YSlow) wohl nach einem “echten” CDN.

Verwandte Artikel

• WordPress Plugins verschieben (0)
• gzip-Komprimierung aktivieren (1)
• Etwas Sicherheit durch die .htaccess (1)
• Caching mit Expires (0)
• Schluss mit Kommentar-Spam (1)

Expires geben also die “Lebensdauer” einer Ressource (i.d.R. Datei) über den Cache-HTTP-Header an. Lebensdauer bedeutet, ein Zeitraum, in dem der Browser die gecachte Ressource ohne zu überprüfen, ob eine neue Version auf dem Web-Server verfügbar ist, anzeigt bzw. von der lokalen Festplatte lädt. Diese Expires sind “starke” Cache-Header und gelten unbedingt, das heißt, sobald sie gesetzt sind und die Ressource einmal heruntergeladen wurde, stellt der Browser keine GET-Anfragen für die Ressource bis das Verfallsdatum erreicht ist. Das kann Ladezeit und Traffic sparen.

Hier mal ein Beispiel für den Code, der so dann z. B. in die .htaccess geschrieben werden kann:

<IfModule mod_expires.c>
# BEGIN Expire headers
# Modul aktivieren
  ExpiresActive on
# Fav/Icons sind 1 Monat gültig
  ExpiresByType image/ico A2419200
  ExpiresByType image/x-icon A2419200
# übliche Dateien sind 2 Wochen gültig
  ExpiresByType application/pdf A1209600
  ExpiresByType application/zip A1209600
  ExpiresByType application/javascript A1209600
  ExpiresByType application/x-javascript A1209600
  ExpiresByType application/x-shockwave-flash A1209600
# CSS sind 3 Tage gültig
  ExpiresByType text/css A2592000
# übliche Grafiken sind 3 Tage gültig
  ExpiresByType image/jpg A2592000
  ExpiresByType image/gif A2592000
  ExpiresByType image/jpeg A2592000
  ExpiresByType image/png A2592000
# alle anderen Dateien sind 4 Stunden gültig
  ExpiresDefault A14400
</IfModule>

Über ExpiresByType bestimmt man den Dateityp. Die Lebensdauer wird in Sekunden angegeben, da gibt es 2 Schreibweisen:

• z. B. “access plus 2592000 seconds”
• z. B. A2592000 (wie oben gezeigt)

Wer nicht selber rechnen mag , eine Übersicht der Zeitangaben wird im Time Cheatsheet gezeigt. (z.B. 2592000 = 3 Tage * 24 Stunden * 60 Minuten * 60 Sekunden)

Neben den “Expires” gibt es noch “Header set Cache-Control max-age”. Hier wird auf ähnliche Weise, aber über das Apache-Modul Headers, das maximale Alter einer Datei bestimmt. Grundsätzlich gilt: Entweder Expires oder Cache-Control, nicht beides.

Im Zusammenhang damit sei noch kurz Last-Modified und ETag genannt. Beide geben charakteristische Spezifikationen über eine Ressource aus, sodass der Browser feststellen kann, ob Ressourcen gleich sind. Beim Last-Modified-Header ist dies immer ein Datum. Beim ETag wird die Ressource eindeutig über einen Wert (Datei-Versionen oder Content-Hashes sind typisch) identifiziert.
Last-Modified ist ein “schwacher” Cache-Header, er erlaubt dem Browser heuristisch zu bestimmen, ob das Element aus dem Cache zu holen ist oder nicht. Allerdings hat es den Vorteil, dass der Browser bei einem explizitem Neuladen der Seite, auch die Ressource neu ausgibt. Auch hier ist es wieder überflüssig, sowohl ETag und Last-Modified-Header anzugeben, entweder oder.

Wer also Last-Modified verwendet sollte ETag wie folgt über die .htaccess deaktivieren:

# Turn ETags Off
FileETag None

Alles zusammen könnte dann so in der .htaccess aussehen:

Verwandte Artikel

• gzip-Komprimierung aktivieren (1)
• Etwas Sicherheit durch die .htaccess (1)
• WordPress: CDN und cookieless domain (3)
• WordPress Plugins verschieben (0)
• noindex und nofollow (1)

1. Für mod_deflate muss folgender Code in die .htaccess

   <IfModule mod_deflate.c>
   <FilesMatch "\\.(js|css|x?html?|html|htm|php|xml)$">
   SetOutputFilter DEFLATE
   </FilesMatch>
   </ifModule>
   

   Die Datei-Endungen (js|css|x?html?|html|htm|php|xml) lassen sich beliebig ändern.

2. Für mod_gzip muss folgender Code in die .htaccess

   <ifModule mod_gzip.c>
     mod_gzip_on Yes
     mod_gzip_dechunk Yes
     mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
     mod_gzip_item_include handler ^cgi-script$
     mod_gzip_item_include mime ^text/.*
     mod_gzip_item_include mime ^application/x-javascript.*
     mod_gzip_item_exclude mime ^image/.*
     mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
   </ifModule>
   

   Auch hier lassen sich die Datei-Endungen (js|css|html|htm|php|xml) wieder beliebig ändern.

3. Für ob_gzhandler (zlib extension) muss folgender Code am Anfang einer Website stehen

   <?php
   ob_start("ob_gzhandler");
   ?>
   

   Tipp1: Für WordPress ist es sinnvoll den Code als allererstes in die functions.php des Themes zu schreiben.
   Tipp2: ob_gzhandler komprimiert nur php-Dateien. Falls also ob_gzhandler genutzt wird, können trotzdem auch die css Dateien komprimiert werden. Dazu kopiert man einfach die css-Datei (z.B. style.css) in eine neue php-Datei (z.B. style.php). In diese neue Datei fügt man ganz oben noch folgendes ein:

   <?php
   if (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false) {
   header('Content-type: text/css');
   ob_start("ob_gzhandler");
   }
   ?>
   

   und ganz unten noch diesen Code:

   <?php
   ob_end_flush();
   ?>
   

   Nach dem Upload der style.php in das selbe Verzeichnis wo auch die Ursprungs-CSS liegt, muss noch der Aufruf der css in php geändert werden. Dieses geschieht im head-Teil (z.B. header.php) der Website.

Ob mod_deflate, mod_gzip oder die zlib-extension auf dem Server konfiguriert ist, kann man feststellen, in dem man eine neue Datei phpinfo.php mit dem Inhalt

<?php
phpinfo();
?>

auf den Server hoch lädt und anschließend über den Browser aufruft.

Verwandte Artikel

• Etwas Sicherheit durch die .htaccess (1)
• Caching mit Expires (0)
• WordPress: CDN und cookieless domain (3)
• WordPress Plugins verschieben (0)
• noindex und nofollow (1)

In der Version 3 werden die Einstellungen aber erst mal nur im Benutzerprofil von Windows gespeichert. Mit einem kleinen Trick kann man die Speicherung der Einstellungen aber wieder im Ordner von FileZilla festlegen. Dazu muss nur eine fzdefaults.xml mit folgendem Inhalt im Ordner von FileZilla erstellt werden:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<FileZilla3>
<Settings>
<Setting name="Config Location">Einstellungen/</Setting>
</Settings>
</FileZilla3>

Das war es schon. Alle Einstellungen werden nun im Unterordner “Einstellungen” des FileZilla-Ordner abgespeichert. Dort findest Du insgesamt 6 Dateien.

Jetzt ist auch die Version 3 portabel.

Verwandte Artikel

• WordPress: CDN und cookieless domain (3)
• WordPress Plugins verschieben (0)
• Teamviewer (1)
• Private Daten und Cookies beim schließen von Chrome löschen (0)
• Netzwerkfreigaben mit Kaspersky (KIS) (0)

Einige Features:

• Abgebrochene Downloads wieder aufnehmen
• Keep-Alive-System
• Verbindungen trozt Firewall oder Proxy
• SSL
• Warteschlange für Up- und Downloads

FTP-Client LINK

Verwandte Artikel

• FileZilla 3 portabel machen (0)
• xp-AntiSpy (0)
• WordPress: CDN und cookieless domain (3)
• WordPress Plugins verschieben (0)
• VLC-VideoLAN Client Media Player portabel machen (0)