Taghtaccess

CoSchni#3: htaccess Minified Version für TYPO3 CMS Projekte

Standardmäßig ist die htaccess von TYPO3 mit vielen Kommentaren versehen in denen weitere Optionen erklärt werden. Wer dies nicht braucht und zudem die seit der TYPO3 CMS Version 4.7 Komprimierung nutzen möchte, für den sind die unten stehenden Zeilen vollkommen ausreichend.

[PHP]
// File: typo3conf/localconf.php

$TYPO3_CONF_VARS[‘BE’][‘compressionLevel’] = ‘5’;
$TYPO3_CONF_VARS[‘FE’][‘compressionLevel’] = ‘5’;
[/PHP]

[PHP]

AddType “text/javascript” .gzip


AddType “text/css” .gzip

AddEncoding gzip .gzip

RewriteEngine On
RewriteRule ^typo3$ – [L]
RewriteRule ^typo3/.*$ – [L]
RewriteRule ^uploads/.*$ – [L]
RewriteRule ^fileadmin/.*$ – [L]
RewriteRule ^typo3conf/.*$ – [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* /index.php
[/PHP]

[random_content group_id=”211″ num_posts=”1″]

CoSchni#2: htaccess Expire Header für Caching von Dateien

Der untere Code eingefügt in die htaccess sorgt zum einen dafür das gepackte JavaScript (JS) Dateien vom Browser entsprechend erkannt werden. Der zweite Absatz ist verantwortlich dafür dem Browser mitzuteilen, wie entsprechende Datei-Endungen im Browser gecached werden sollen. Überprüft können die Einstellungen bspw. mit dem Chrome im Tab “Network”.

[PHP]

AddType “text/javascript” .gzip


AddType “text/css” .gzip

AddEncoding gzip .gzip



ExpiresActive on
ExpiresDefault “access plus 7 days”
Header append Cache-Control “public”

FileETag MTime Size


SetOutputFilter DEFLATE


[/PHP]

CoSchni#1: htaccess Domain immer mit www und SSL

Für eine einheitliches Tracking bzw. ein besseres Ranking in den Suchmaschinen ist es wichtig, das Inhalte nur unter einer Domain erreichbar sind, Stichwort: Duplicate Content und Canonical Tag. Daher sollte u.a. darauf geachtet werden, das die Inhalte nur mit www oder ohne www erreichbar sind. Für mehr Komfort werden die Parameter zudem automatisch wieder an die Domain angehängt.

[PHP]

# Immer mit www
RewriteEngine on
RewriteCond %{HTTP_HOST} ^example.de$ [NC]
RewriteRule ^(.*)$ https://www.example.de/$1 [R=301,L]

# Immer über SSL
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [L]


[/PHP]

Letzteres kann man im TYPO3 CMS auch direkt aktivieren, jedoch hatte dies nicht gewünschten Erfolg bzw. kam es, glaube ich, zu einem Konflikt mit RealURL.

[random_content group_id=”211″ num_posts=”1″]

Usability: www ist nur eine Subdomain

Für viele Menschen sind Domains, Firstleveldomains und Subdomains immer noch ein Buch mit sieben Siegeln. Oft fällt auch die Unterscheidung zwischen Domain und URL schwer. Dabei ist es, wie immer wenn man weiß wie es geht, ganz einfach.

Eine Domain ist alles ohne die Subdomains und Verzeichnisse bzw. Dateien. URLs sind dagegen der gesamte String.

[html]

google.de
web.de


www.google.de
www.google.de/verzeichnis/datei.html
google.de/verzeichnis/datei.html
[/html]

Die Domain kostet Geld. Je nach Endung (.de / .com / .net) mehr oder weniger. Wundert mich, das es die in Deutschland nicht schon beim Aldi gibt. Mittlerweile ist, glaube ich, schon der ganzen Duden registriert.

Die Subdomain kostet aber kein Geld und hier geht die Usability weiter, wenn man davon ausgeht, das sie bei der Domain anfängt. Als SysAdmin kann man an der Domain nichts verändern. Die kommt vom Kunden oder hat die Firma bereits eingekauft, an der Subdomain dagegen schon.

Wie oft kommt es vor, das man mal ein W zuviel oder zu wenig eintippt? Wäre es dann nicht fantastisch, wenn man trotzdem auf die Seite kommt. Der Kunde ist König, warum sollte man ihn also für seinen kleinen Fehler bestrafen, wenn wir es ohne Probleme korrigieren können?

Damit der Kunde trotz falscher Subdomain, auf der richtigen Domain landet, gibt es zwei Angriffspunkte. Zuerst einmal muss man die falsche Anfrage akzeptieren, getreu dem Motto, es gibt keine dummen Fragen nur Dumme antworten, können wir ihn jetzt gleich korrigieren oder dies später per htaccess tun.
Aufgrund von Serverkonfigurationen kann es sein, das zwar alle Subdomains zum Ziel führen, aber man den Server nicht direkt konfigurieren darf und dies mittels htaccess machen muss.

Sollte htaccess auch nicht möglich sein, weil damit im Prinzip die Einstellungen vom Apache überschrieben bzw. erweitert werden, könnte man noch auf PHP zurückgreifen.

© 2021 BugBlog.de

Theme by Anders NorénUp ↑