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]

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.

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.

Trotzdem wollen wir auch auf die Lösung des Problems hinweisen. In der functions.inc.php im includes-Ordner vom chCounter muss nach folgendem Code gesucht werden:

function chC_login( $name, $pw, $cookie = 0, $admin_required = FALSE )
{

Dieser Code muss um eine Zeile ergänzt werden:

function chC_login( $name, $pw, $cookie = 0, $admin_required = FALSE )
{
$name=mysql_real_escape_string($name);

Also einfach die Zeile $name=mysql_real_escape_string($name); hinzufügen.

noindex verhindert also bei den “freundlichen” Suchmaschinen (es ist nur ein Hinweis woran sich aber nicht alle Crawler halten), dass die Seite in ihren Index aufgenommen werden. Als Beispiel könnte man hier die Impressums-Seite oder den Disclaimer nennen.

nofollow ist für die Blogsysteme oder Internetforen eingeführt worden. Spammer kamen früh auf die Idee über die Kommentarfunktion sämtliche Links zu hinterlassen, die die Webcrawler dann natürlich abgegrast haben und als positive Verweise (Linkpopularität) auf die Spamseiten gewertet haben. Das sollte natürlich nicht Sinn und Zweck der Kommentarfunktion sein. Also wurde ca. 2005 das rel=”nofollow”-Attribut erfunden. Das Attribut kann den Weblinks angehängt werden. Bei WordPress u.a. wird dies z.B. automatisch für die Kommentar-Links angefügt.

<a href="http://example.com" rel="external nofollow">Example</a>

Für ganze Archive oder Seiten steht das Meta-Tag robots mit den Werten noindex und nofollow zur Verfügung.
Wer also, z. B. in WordPress für die Tages-Archive, die Suche, die 404-Seite, die Authoren-Archive und die Impressums-Seite die Indexierung verhindern aber trotzdem die Weiterverfolgung der Links aktivieren will, kann folgenden Code in die header.php seines Themes schreiben:

<?php if( is_day() || is_search() || is_404() || is_author() || is_page('impressum') ) { echo "<meta name="robots" content="noindex,follow" />"; } ?>

grobe Übersetzung:
–> wenn es sich um ein Tages-Archive ODER die Suche ODER die 404-Seite ODER die Authoren-Archive ODER die Impressums-Seite handelt
–> dann setzte den Meta-Tag: name=”robots” content=”noindex,follow” (keine Indexierung aber bitte den Links folgen)

Auch gibt es noch den Wert “noodp”. Mehr dazu: Wikipedia.

Es geht aber auch etwas einfacher. Auf der Website http://browsershots.org kann man die Browser-Kompatibilität der Website mit momentan ca. 60 Browsern testen und bekommt sogar von jedem Browser einen Screenshot.

Wer nicht ganz so viel testen will und sich nur auf den IE in den verschiedenen Versionen beschränken will kann sich den IETester von DebugBar installieren. Damit lassen sich lokal die IE Versionen von 5.5 bis 8 testen.

für Beiträge:
Inhalt | Beiträge
Voreinstellungen -> z.B. Author-Anzeige, PDF/Print/Email etc.

für Weblinks:
Komponenten | Weblinks
Voreinstellungen -> z.B. Zugriffe etc.

für Kontakte:
Komponenten | Kontakte
Voreinstellungen -> z.B. eMail o. Mobilfunknummer anzeigen etc.

Die Erweiterung scheint für eine frühere Version entwickelt zu sein. Zum Fertigstellen muß der Kompatibilitätsmodus in der “Konfiguration” aktiviert sein.

dann kannst Du so den Kompatibilitätsmodus aktivieren:
Erweiterungen | Plugins
Plugin “System – Legacy”