Diese Standardeinstellung, so dass nicht jedes mal wieder in den Spaltenköpfen von Thunderbird geklickt werden muss, lässt sich allerdings leicht ändern:

1. Extras – Einstellungen – Erweitert – Allgemein -> “Konfiguration bearbeiten”
2. Folgende Meldung mit “Ich werde vorsichtig sein, versprochen!” bestätigen
3. nach mailnews.default_sort_order suchen und mit Doppelklick den Wert auf 2 ändern.
   (1 = aufsteigen(default) | 2 = absteigend)
4. Thunderbird schließen

Diese Einstellung legt jetzt alle neuen Ordner mit absteigender Sortierung an. Bestehende Ordner werden leider nicht direkt geändert. Hierfür gibt es aber auch eine einfache Lösung:

1. Im Explorer den Profil-Ordner aufrufen (standardmäßig: C:\Dokumente und Einstellungen\xxxx\Anwendungsdaten\Thunderbird\Profiles\xxxxxxx.default)
2. Mit STRG+F oder über “Rechtsklick – Suchen” im Profilordner nach *.msf suchen und alle Dateien löschen

Jetzt sollte Thunderbird mit der neuen Einstellung starten.

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]

Website zum Buch: http://www.wordpress-buch.de/

Update: Die 2010 erschienene 3. Auflage von “WordPress – Das Praxisbuch” gibt es mittlerweile auch als E-Book.

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:

Selbst für Firebug gibt es mittlerweile schon Erweiterungen, wie z. B. YSlow.
Hierbei handelt es sich um ein Performance Tool, wobei das Y wohl für Yahoo steht.
YSlow führt Performance-Test durch und stellt die Ergebnisse mit Tipps und Grafiken zur Verfügung.

Update:
Ein ähnliches Werkzeug ist nun auch im Internet Explorer 8 (IE8) vorhanden und nennt sich “Entwicklertools”. Aktivieren kann man es auch mit F12 oder über Extras -> Entwicklertools
Im IE8 Entwicklertool lassen sich ebenfalls HTML, CSS und Scripts anzeigen und im Live-System testen. Außerdem lässt sich über das Entwicklertool der Browsermodus auf Internet Explorer 7, Internet Explorer 8 und Internet Explorer 8-Kompatibilitätsansicht einstellen.

Last but not least … auch der aktuelle Opera-Browser bringt unter Ansicht -> Entwicklerwerkzeuge (Opera Dragonfly) solch ein Tool mit.

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.

Wenn du aber die Anzahl in wievielen Themen das Schlüsselwort vorkommt bestimmen willst, musst du dich in die Tiefen von WordPress begeben.

Öffne die /wp-includes/category-template.php und suche nach folgendem Code:

$unit;'>$tag

oder

$unit;'>$tag_name

Die Variable $count ist für die Zählung verantwortlich. Also ergänze den oberen Ausschnitt wie folgt:

$unit;'>$tag ($count)

oder

$unit;'>$tag_name ($count)

Ab jetzt erscheint hinter jedem Tag die Anzahl der Themen.

ACHTUNG: Bei einem Upgrade von WP wird die category-template.php natürlich mit überschrieben, d. h. die Änderungen müssten immer wieder erneut vorgenommen werden.

• Alle Elemtente
• Dokumente
• Bilder und Videos
• Musikdetails
• Musiksymbole

Windows Vista / 7 versucht also jeden Ordner automatisch einem der 5 Typen zuzuordnen.
Um manuell den Ordnertyp festzulegen genügt es mit einem Rechtsklick auf den Ordner in die Eigenschaften des Ordners zu gelangen und dort den Typ festzulegen. Die Option “Vorlage für alle Unterordner übernehmen” sorgt dafür, dass die Einstellung an alle darunter liegenden Verzeichnisse vererbt wird.

Aaaber … sobald in einen Dokumente-Ordner überwiegend Bilder gelegt werden, wird der Explorer den Ordnertyp auf “Bilder und Videos” umstellen und somit auch wieder die Eigenschaften der Anzeige ändern. Diese “Automatik” lässt sich über die Registry deaktivieren:

Öffne den Registrierungseditor und navigiere zu
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell
Lösche dort die Schlüssel “BagMRU” und “Bags”. Nun legst du die soeben gelöschten Schlüssel wieder an (Sinn: die beiden Schlüssel sind nun komplett leer).
Lege im Schlüssel “Bags” einen neuen Schlüssel “AllFolders” an.
Lege im Schlüssel “AllFolders” wieder einen neuen Schlüssel “Shell” an.
Lege im Schlüssel “Shell” eine neue Zeichenfolge “FolderType” mit dem Wert “NotSpecified” an.

Nach einem Neustart des Rechners ist die Explorer-”Automatik” deaktiviert. Alle alten und neuen Ordner gehören nun zum Typ “Alle Elemente”. Ab jetzt kann der Ordnertyp über die Ordner-Eigenschaften manuell zugeordnet werden. Nach dem dann auch die Ansicht für diesen Ordner eingestellt ist, kann über “Organisieren” -> “Ansichts- und Suchoptionen” ->Register “Ansicht” -> Schaltfläche “Für Ordner übernehmen” die Ansicht für alle Ordner dieses Ordnertyps gespeichert werden.

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