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]

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.

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:

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.

Bei älteren Themes muss also die ganze Funktion auch erst mal über die functions.php aktiviert werden. Frank schreibt in seinem Blog wie man ältere Themes dahingehend aktualisiert: http://bueltge.de/wordpress-post-thumbnail-abwaertskompatibel/1079/

Wozu das Ganze?
Wenn also ab WordPress 2.9 nun das Theme soweit angepasst und aktualisiert ist, dass es Post-Thumbnail unterstützt, dann kann über das Backend von WP im “Artikel schreiben”-Dialog das Thumbnail ganz einfach gesetzt werden. Die Vorgehensweise ist dem “Bild einfügen” gleich. Man kann also ein Bild vom Computer, von einer URL oder oder aus der Mediathek auswählen und klickt anschließend auf “Use as thumbnail”.

Wenn man WordPress mit vielen Seiten (Bsp. als CMS) betreibt, ist es also ratsam, die Permalinks so umzustellen, dass eben nicht die vier o. g. Permalink-Tags am Anfang stehen. Anstelle dieser kann z.B. die “Post-ID” oder das “Year” zu Beginn stehen:

/%post_id%/%postname%/
/%post_id%-%postname%/
/%year%/%postname%/
/%year%-%postname%/

<?php the_excerpt(); ?>
<p>
<a href="<?php&phpMyAdmin=efb1bc0ce47ede9fe1dbff3e50eb439e the_permalink() ?>" rel="bookmark" title="<?php _e('weiterlesen ...',''); ?> 
<?php the_title(); ?>"><?php _e('weiterlesen ...',''); ?></a>
</p>

wer im Code und mit den Templates etwas sicherer ist, kann eine Variante über die functions.php wählen:

// bildet das "weiterlesen" bei the_excerpt
function link_hellip_in_excerpt( $content ) {
 global $post_ID;
 return preg_replace( '~\[\.\.\.\]$~', ' <a href="' . get_permalink( $post_ID ) . '?phpMyAdmin=efb1bc0ce47ede9fe1dbff3e50eb439e">[weiterlesen ...]</a>', $content);
}
add_filter( 'the_excerpt', 'link_hellip_in_excerpt', 9);
add_filter( 'the_content', 'link_hellip_in_excerpt', 9);

Ab WordPress 2.9 werden sogar excerpt-Filter für Auszugs-Länge und Weiterlesen-Link unterstützt, die über die functions.php z.B. so aussehen können:

// ändern der excerpt Länge auf 40 Worte
function new_excerpt_length($length) {
	return 40;
}
add_filter('excerpt_length', 'new_excerpt_length');
 
// ändern des excerpt more Strings
function new_excerpt_more($more) {
return '[weiterlesen …]';
}
add_filter('excerpt_more', 'new_excerpt_more');

Wie weiter oben schon erwähnt kannst du auch mit dem Template-Tag the_content den gesamten Inhalt auf der Startseite einlesen lassen. the_content() zeigt im Gegensatz zu the_excerpt die Links, Bilder und Formatierungen vom Beitrag an. Außerdem lässt sich individuell mit dem <!–more–>-Tag bestimmen, was genau angezeigt werden soll. Der more-Tag, welchen man in der Artikel-Bearbeitung setzen kann, splittet den Beitrag / die Seite in zwei Teile. Auf der Startseite bzw. in Archiven wird dann nur der Teil vor dem more-Tag angezeigt, allerdings mit allen Links, Bildern und Formatierungen. Mehr darüber erfährst du auch in der WPD-FAQ: http://faq.wordpress-deutschland.org/keine-bilder-keine-links-im-archiv-the_excerpt/

Also zu erst muss die Library ins Template eingebunden werden. Entweder man lädt sich die .js Datei hier herunter und bindet sie anschließend so (am besten im Header) ein:

<script src="jquery-1.3.2.min.js" type="text/javascript"></script>

oder man bindet z. B. direkt die von jquery.com ein:

<script src="http://code.jquery.com/jquery-latest.js" type="text/javascript"></script>

So, nachdem nun die Library eingebunden ist, können wir mit dem Javascript beginnen. Es läuft immer nach ähnlichem Schema.
Erst sagen wir, wir wollen eine Funktion:
$(document).ready(function()
Dann können wir bei Bedarf bestimmen, welches Element/Objekt bei Klick o. ä. die Änderung vornehmen soll:
$("button").click(function ()
Auf jeden Fall werden dann die Element/Objekte bestimmt, welche ihr Aussehen/Verhalten ändern sollen:
$("p").slideToggle

Als 1. kleines Beispiel lassen wir mit slideToggle alle Texte innernhalb eine p-Tags durch einen Button ein-/ausblenden:

<script type="text/javascript">
  $(document).ready(function(){
 
    $("button").click(function () {
      $("p").slideToggle("slow");
    });
 
  });
</script>

 
<button>Text ein-/ausblenden</button>
 
<p>
   Hier steht der Text der nun ein- bzw. ausgeblendet werden kann.
</p>

Hier kannst du es testen

Als 2. Beispiel wollen wir zeigen, wie z. B. die Kombination von mehreren Elementen/Objekte mit mehrfacher Veränderung möglich sind:

<script type="text/javascript">
  $(document).ready(function(){
 
    $("button").click(function () {
    $("div.block").add("p.extra").addClass("blau");
     alert("Class in blau geaendert");
    });
 
  });
</script>

Hier kannst du es testen

Eine weitere Spielerei wäre ein FadeIn-Effekt bei allen Bildern die im Div-Container “#content” sitzen:

<script type="text/javascript">
  $(document).ready(function() {
    $("#content img").css("display","none");
    $("#content img").fadeIn(5000)
});
</script>

Hier kannst du es testen

Weitere Effekte findest du in der jQuery-Documentation: http://docs.jquery.com/Effects

Ein kleiner Hinweis für WordPress-User:

WordPress bringt eine jquery.js im Verzeichnis /wp-includes/js/jquery/jquery.js mit. Falls ihr also damit arbeiten wollt ist eine kleine Abweichung zu beachten. Statt des $-Zeichen muss in WP jQuery benutzt werden:

<script src="http://www.deine_domain.xyz/wp-includes/js/jquery/jquery.js" type="text/javascript"></script>
<script type="text/javascript">
  jQuery(document).ready(function(){
 
    jQuery("button").click(function(){
    jQuery("div.block").add("p.extra").toggleClass("blau");
     alert("Class geaendert");
    });
 
  });
</script>

Falls ihr in WordPress nicht mit der WP eigenen jquery.js arbeiten wollt, könnt ihr diese deaktiveren und eine andere einbinden. Könnte sein, dass in eurer header.php, footer.php oder functions.php schon der Aufruf der jquery drin steht:

<?php 
wp_enqueue_script('jquery');
?>

Das dann wie folgt ändern bzw. hinzufügen, falls es noch nicht vorhanden ist:

<?php 
wp_deregister_script( 'jquery' ); //derigistriert die jquery von WP
wp_register_script( 'jquery', 'http://code.jquery.com/jquery-latest.js'); //registriert die jquery von der externen URL
wp_enqueue_script( 'jquery' ); //laedt die neue jquery
?>

Wie wir bereits in unserem Artikel “chCounter für WordPress nutzen” erwähnten, ist die Entwicklung vom chCounter seit einiger Zeit aus nicht bekannten Gründen eingeschlafen. Jetzt greift Volker S. Latainski das Projekt auf und entwickelt den Counter, dank GPL (Lizenz), unter neuem Namen weiter:

Die Installation erfolgt wie vom chCounter gewohnt. Auch der Umstieg vom chCounter auf den expCounter, wie hier beschrieben, ist sehr einfach. Das Template (zuständig für die Anzeige) lässt sich sehr einfach über den Template-Generator anpassen.

Wir haben nun ziemlich früh umgestellt und sind auf die (Weiter-)Entwicklung des Counters gespannt.

Ach übrigens, unser Artikel “chCounter für WordPress nutzen” (sowie die Artikel die sich mit der Einbindung in Joomla beschäftigen) hat bisher noch Gültigkeit. Falls sich für die Einbindung in WordPress etwas ändern sollte werden wir selbstverständlich berichten.

In einigen Situationen, vor allem auf Multi-User-Blogs, kann es sinnvoll sein einige Widgets komplett zu entfernen anstatt nur auszublenden. Jeder Nutzer kann standardmäßig über das Optionen-Tab (an der rechten oberen Seite) einzelne Widgets ausblenden, aber wenn die User keine technischen Anwender sind, ist es sicherlich schöner, dass die nicht benötigten Dashboard-Widgets bereits vom Admin deaktiviert wurden.
Aber auch aus Problemen mit der Ladezeit oder des Serverspeichers (bsp. mit Strato) kann es sinnvoll sein einige Dashboard Widgets komplett abzuschalten. Das bringt immerhin einige MB Platz.

Zurzeit gibt es keine Funktion auf einfache Weise die Standard-Dashboard Widgets zu entfernen. Um sie zu entfernen, müsste man manuell über unset() die Elemente aus dem allgemeinen $ wp_meta_box Array entfernen:

function remove_dashboard_widgets() {
  // Globalize the metaboxes array, this holds all the widgets for wp-admin
  global $wp_meta_boxes;
 
  // Remove the incomming links widget
  unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_incoming_links']);
  //Remove the plugins widget  
  unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_plugins']);
  // Remove the quickpress widget
  unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_quick_press']);
} 
 
// Hoook into the 'wp_dashboard_setup' action to register our function
add_action('wp_dashboard_setup', 'remove_dashboard_widgets' );

http://codex.wordpress.org/Dashboard_Widgets_API#Advanced:_Removing_Dashboard_Widgets

Für dieses Problem haben wir ein Plugin geschrieben, welches diese Aufgabe auf einfache Weise übernimmt. Das Plugin “Remove Dashboard Widgets” kann übersichtlich über die Einstellungen einzelne/alle Standard-Dashboard-Widgets für alle User ausschalten.

Wie bereits erwähnt, arbeitet das Plugin erst ab WordPress Version 2.7, da hier die neue Dashboard Widgets API eingeführt wurde!

Download Zip-Datei:
Remove Dashboard Widgets 0.3

Installation:

1. Download “Remove-Dashboard-Widgets” plugin
2. Entpacke das Archiv
3. Lade den Ordner per FTP in den WordPress-Plugin-Ordner …/wp-content/plugins/*
4. Gehe ins WP-Backend zum tab “Plugins”
5. Aktiviere das “Remove-Dashboard-Widgets” Plugin
6. Gehe in die Plugin Einstellungen
7. Fertig

History:
0.1 – Entwicklung Grundfunktionen über unset()
0.2 – Einstellungen über den Settings-Bereich im WP-Backend möglich, deutsche Sprache de_DE
0.3 – Code/Funktionen überarbeitet, Settings in die Dashboard-Box verlegt