Irgendwann stand oder steht wohl jeder PHP-Entwickler einmal vor dem Problem der Auswahl eines geeigneten PHP Frameworks. Bis vor einigen Monaten habe ich mich primär mit selbst erstellten Frameworks herum geschlagen. Nicht das die Frameworks schlecht waren, jedoch verspürte ich mehr und mehr den Drang, bekannte PHP-Frameworks kennen zu lernen. Dies ist nicht zuletzt dem Umstand geschuldet, dass am Markt befindliche Ressourcen nicht kompatibel zu selbst erstellten Frameworks sind (der Aufwand und somit die Kosten sind zu hoch).

So fiel meine Wahl zunächst auf ZEND Framework – das Flaggschiff unter den PHP Frameworks. ZEND ist ein sehr mächtiges aber leider auch ein unterirdisch performantes Framework. Die eigenartige auf Grund von PHP Abwärtskompatibilität angewendete Namespace-Implementierung mit Unterstrichen sowie die Komplexität des ZEND-Monsters haben mich jedoch zunehmend abgeschreckt. Mit ZEND gehen viele Dinge, wirklich sehr viele, aber in der Regel brauche ich diese Dinge nicht. Insofern bestand tief in mir der Wunsch nach einem schlankeren, Ressourcen schonendem und gut dokumentierten Framework Ausschau zu halten. Das Framework sollte zudem einfach konfigurierbar und modular verwendbar sein. Die Möglichkeit Extensions zur Erweiterung des Frameworks einzubinden, setze ich als gegeben voraus.

Folgende Komponenten sollte das Framework unbedingt an Board haben:

• MVC
• modular erweiterbar (Module)
• i18n (Mehrsprachigkeit)
• einfache Konfiguration
• ORM einfach austauschbar (falls erforderlich)
• gut aufgestellte Community (wichtig für Extensions und Support)
• gute Dokumentation (sowie im Code als auch im User Guide)
• Access Control & Rights Management
• Unit Tests
• gute Erweiterbarkeit und somit Flexibilität in jeglicher Hinsicht
• Benutzer definiertes URL-Design (Routing)

Sicherlich erfüllen sehr viele PHP-Frameworks oben genannte Ansprüche, allerdings wollte ich nach ZEND einem noch jungen Projekt meine Aufmerksamkeit schenken. So viel mein Blick eher zufällig als gezielt auf Yii. Angestachelt durch den Yii Performance Vergleich mit diversen anderen Frameworks begann ich mich also in Yii einzulesen. Die ersten Tests verliefen zügig und funktionierten ohne Wehwechen – das kannte ich von ZEND auch anders. Module funktionieren von Haus aus, ohne das ich mich in Konfigurationsdateien tot wuseln muss. Selbst Module in Modulen in Modulen … funktionieren ohne groß Schnickschnack veranstalten zu müssen. Das hat mich dann doch sehr beeindruckt.

Das implementierte ORM (AR) ist sehr leistungsfähig, jedoch wie ich finde für Cloud Entwicklung nur bedingt geeignet. Das Problem des ORM ist schlichtweg, dass aus dem Code kein Datenbankschema generiert werden kann (zumindest nicht von Haus aus). Abgesehen davon beherrscht das ORM jedoch alles, was die tägliche Entwicklung benötigt. Mit Dcotrine2ORM, einer Extension zum Implementierung von Doctrine 2.0 in Yii, gibt es die für mich bessere Alternative, die sich ohne Probleme einbinden und nutzen lässt und diesen Missstand behebt.

Nun kann man denken was man will, die Leistungsfähigkeit und Performance eines Frameworks ist lediglich in einem realen Projekt sinnvoll einschätzbar. Von “Hello World” Tests halte ich persönlich nicht viel. Es gilt also ein Exempel zu statuieren, um über zuvor genannte Punkte eine gute Aussage treffen zu können. Ein Vergleich zu anderen Frameworks ist dadurch jedoch auch nur bedingt möglich.

Wie es der Zufall so will, holte ich also eine meiner Ideen aus der Schublade und begann zusammen einem Freund daraus ein Konzept zusammen zu tragen – zunächst alles ohne Yii . Nachdem wir festgestellt hatten, dass sich die Idee umzusetzen lohnt, haben wir sämtliche erforderliche Seiten und Masken als Prototypen Sketches entworfen und von meinem Designer auf Basis dieser Grundlage ein Layout erstellen lassen. Kosten für weitere Dienstleistungen haben wir im Budget natürlich einfließen lassen, denn wenn man etwas macht dann richtig (-> no money no honey).  genug gesülzt…

Die Landingpage zur Registrierung, zum Login, Passwort zurück setzen etc. ist fertig gestellt und ich erlaube mir an dieser Stelle ein Zwischenfazit. Die Entwicklung mit dem Yii Framework macht einem erfahrenen Entwickler wie mir nicht zuletzt wegen der ausgezeichneten Dokumentation sehr viel Spaß. Das Framework erweist sich als sehr gelungen und flexibel erweiterbar. Komponenten und Erweiterungen lassen sich nach Bedarf sehr trivial ein- beziehungsweise abschalten.

Mit einem Speicherverbrauch (LAMP, inklusive Doctrine, i18n, Verwendung von Modulen, APC=on) von 3,5-5,5 MB pro Request für die bisher entstandenen nicht sonderlich komplexen Seiten ist Yii in meinen Augen sehr Ressourcen schonend. Zum (ungleichen) Vergleich – eine WordPress Installation benötigt ohne Zusatzfeatures 14 MB. Mit einigen Plugins sind 32 MB schnell geknackt. Ein Drupal langt mit 15-40MB ebenfalls üppig zu. Zu bedenken ist, dass unter anderem der Arbeitsspeicher die Anzahl synchroner Requests begrenzt. Wenn das System zum Beispiel 30GB für Apache-Prozesse einräumt (entspricht Anzahl Apache max. Connections multipliziert mit PHP memory_limit) komme ich mit meinem Messergebnis auf 30*1024 / 5,5 = 5.585 maximale mögliche Connections zur gleichen Zeit – das ist verglichen mit WordPress (14 MB, 2.194) oder Drupal (20 MB, 1.536) sehr viel. Dieser Wert ist rein rechnerisch zu betrachten und nicht praxistauglich. Hier spielen noch andere Faktoren (IO, Datenbank Connections, etc.) eine Rolle. Allerdings zeigt der Vergleich durchaus auf, dass Ressourcen für andere wichtige Dinge aufgespart werden.

Warum ich meine jungfräuliche Yii-Applikation mit WordPress/Drupal vergleiche? Weil beide geläufige und zuhauf eingesetzte Softwares sind und jeder diese Softwares kennt. Wie bereits geschrieben ist der Vergleich sehr ungleich. Meine Yii Applikation ist natürlich lange nicht so funktionell wie ein WordPress oder ein Drupal. Wenn ich allerdings bedenke, dass Doctrine schon eine fette Sau ist und die Messergebnisse im Debug Modus zu Stande kommen (Logging, Debug Toolbar, etc.), so kommt mir der Speicherverbrauch doch sehr niedrig vor.

Ich nehme dieses erste Posting zum Yii Framework zum Anlass, weiter über meine Erfahrungen mit dem Yii Framework zu berichten.

Stay tuned!

Links:
http://www.yiiframework.com - Yii Framework
http://framework.zend.com/ - Zend Framework

Dabei ist das Updaten von Datensätzen mittels bei MySQL sehr trivial. Folgende Abfrage aktualisiert alle Datensätze von tabelle1 (aktiv wird auf 1 gesetzt) welche in tabelle2 existieren.

Mysql: Update mittels Join

UPDATE 	tabelle1 AS a
JOIN 	tabelle2 AS b
ON 	a.id = b.id
SET 	a.aktiv=1

Folgende Abfrage setzt das Flag “aktiv” in beiden Tabellen bei Datensätzen, die in beiden Tabellen vorkommen.

Quelltext

UPDATE		tabelle1 AS a
JOIN		tabelle2 AS b
		ON a.id = b.id
SET		a.aktiv=1,
		b.aktiv=1

Die Verknüpfung der Tabellen ist beliebig erweiterbar. Selbst Subselects oder Derived Tables sind kein Problem.

Folgende Operation löscht den Datensatz auf lediglich aus Tabelle 1. Gelöscht werden Datensätze von tabelle1 bei welchen die Bedingungen tabelle1.id = tabelle2.id erfüllt.

Mysql: Löschen mittels Join

DELETE 	del
FROM 	tabelle1 AS del
JOIN 	tabelle2 AS sel
ON 	del.id = sel.id

Mysql: Löschen mittels Join 2

DELETE 	del,
	sel
FROM 	tabelle1 AS del
JOIN 	tabelle2 AS sel
ON 	del.id = sel.id

SQL

SELECT COUNT(*) FROM tabelle WHERE feld = 'suchwort'

Die Lösung des Problems bietet MySQL selbst mit dem Befehl SQL_CALC_FOUND_ROWS.

SQL

SELECT 	SQL_CALC_FOUND_ROWS
	spalte1,
	spalte2
FROM 	tabelle
WHERE 	feld = 'suchwort'
LIMIT 	0, 10

SQL

SELECT FOUND_ROWS()

Mehr Informationen über SQL_CALC_FOUND_ROWS und FOUND_ROWS findet ihr in der offiziellen MySQL-Dokumentation.

Ein PHP Beispiel findet ihr im kompletten Beitrag.

PHP-Beispiel:

PHP Beispiel

$res = mysql_query ("
	SELECT 	SQL_CALC_FOUND_ROWS
		feld1,
		feld2,
		feld3
	FROM 	tabelle
	WHERE 	feld1 LIKE 'suchwort'
LIMIT 	0, 10
");
while (list ($feld1, $feld2, $feld3) = mysql_fetch_row ($res))
{
	echo "$feld1 $feld2 $feld3\n";
}
mysql_free_result ($res);
 
$res = mysql_query ("SELECT FOUND_ROWS()");
list ($cnt) = mysql_fetch_row ($res);
mysql_free_result ($res);
 
echo "Datensätze insgesamt: $cnt";

]]> http://www.webtubes.de/programmierung/sql/anzahl-betroffener-datensatze-unter-verwendung-von-limit-ermitteln-mysql/feed/ 2 http://www.webtubes.de/programmierung/fake-google-bots-mittels-htaccess-aussperren/ http://www.webtubes.de/programmierung/fake-google-bots-mittels-htaccess-aussperren/#comments Thu, 19 Feb 2009 14:43:53 +0000 Robert Bernhard http://www.webtubes.de/?p=114 Dass neugierige Dritte eigene Projekte analysieren (Konkurrenzanalyse) ist ja nicht neu. Immer häufiger treffe ich in letzter Zeit beim Stöbern durch meine Logs auf manipulierte Header. Grundsätzlich spricht ja nichts dagegen, sich bei anderen etwas abzugucken. Wenn jedoch der User Agent absichtlich in der Form manipuliert wird, dass sich der Analysator als Googlebot ausgibt, hört mein Verständnis auf.

Wie ein Fake Google Bot mittels .htaccess ausgesperrt wird, möchte ich euch nun kurz aufzeigen. Zuvor möchte ich jedoch auch davor warnen – es wird niemals eine zu 100 Prozent vollständige Liste aller Google IP Adressen geben. Nahezu täglich erweitert Google die eigenen Serverfarmen und somit auch die Anzahl der im Netz befindlichen Crawler (Bots). Jeder neuer Crawler hat eine eigene und unter Umständen euch nicht bekannte IP-Adresse. Die Folge kann sein, dass ihr ungewollter Weise Google aussperrt und das ist nicht Sinn der Sache.

Gut fangen wir an – zunächst benötigen wir eine Liste der Googlebot IP Adressen. Derartige Listen lassen sich bei Google finden. Falls nicht bereits vorhanden, legen wir nun im Root-Verzeichnis der zu schützenden Webseite eine .htaccess Datei mit folgendem Inhalt an (falls bereits angelegt, überspringen).

RewriteEngine On

Nun sind mittels der angelegten .htaccess Datei noch die IP Adressen des die Webseite aufrufenden Benutzers gegen seinen User Agent zu prüfen. Kommt im User Agent “googlebot” vor und die IP Adresse ist in unserer Liste nicht vorhanden, wird der Besucher kurzer Hand ausgesperrt (nix nada niente).

RewriteEngine On

# ACHTUNG!!! Die IP Adressen sind nur exemplarisch
# und gehören nicht zu Google
RewriteCond %{HTTP_USER_AGENT} googlebot
RewriteCond %{REMOTE_ADDR} !^1.1.1.1 [OR] # IP Adresse 1
RewriteCond %{REMOTE_ADDR} !^2.2.2.2 [OR] # IP Adresse 2
RewriteCond %{REMOTE_ADDR} !^2.2.3. [OR] # IP Bereich 2.2.3.1 - 2.2.3.255
RewriteRule ^.* - [F]

Das war es dann auch schon. Fake Google Bots sind ab sofort ausgesperrt. Bitte achtet unbedingt auf die Aktualität eurer Ip Adressen Liste! Wer eine halbwegs aktuelle Liste von Google IP Adressen findet, kann sie gerne in einem Kommentar bekannt geben.

Bevor man sich nun die Arbeit macht, jedes im Quellcode eingebettetes Bild (<img src=”" … >) an das auserwählte Plugin anzupassen, macht ein regulärer Ausdruck hier viel mehr Sinn.

Beim Einsatz von PHP genügt folgender regulärer Ausdruck, um alle Bilder eines Quelltextes für Lightbox beziehungsweise Slimbox anzupassen:

PHP-Snippet

$str = preg_replace (
	"#()#siU",
	"$1",
	$str
);

Worauf kommt es bei einem guten Quelltext an?

Nun zunächst einmal sollte das Dokument möglichst nicht mehrere 1000 Zeilen groß sein. Quelltexte dieser Größe lassen sich nur schwer überblicken. Mehrere kleine Dokumente lassen sich. Nach meiner Erfahrung in Hinsicht auf Teamarbeit und Dokumentation hat es sich oft gezeigt, dass sich das Aufdröseln unterm Strich gelohnt hat. Allerdings trifft das nicht immer zu!

Sinnvolle Benennung von Variablen

Weiterhin sollte ein Programmierer sich bei der Benennung von Variablen lieber 10 Minuten zeit nehmen, anstatt die Programmierung mit Sinn entleerten Variablen Bezeichnungen fort zu setzen. Nehmen wir zum Beispiel an, eine Variable für die Gesamtsumme eines Warenkorbes deklariert werden muss.

PHP-Snippet

$b = 999999.99;

Nehmen wir uns doch etwas mehr Zeit bei der Findung des Variablennamens:
Welchen Wert enthält die Variable? Die Gesamtsumme aller Waren im Warenkorbes…
Inklusive oder exklusive Mehrwertsteuer? inklusive Mehrwertsteuer…

Demzufolge ist es doch ein Einfaches die Variable schlüssig zu benennen oder?

sprechende Variablennamen

$basketSumBrutto = 999999.99;

Einrückung Einrückung und nochmal Einrückung

In vielen Programmiersprachen hat es sich durchgesetzt, mittels Tabulator einzurücken. Das hat den Vorteil, dass ein TAB vom Programmierer in der Regel in seiner Entwicklungsumgebung frei konfigurierbar ist. So kann ein TAB bei einem Programmierer, welche auf Quetschkommode steht, 2 Leerzeichen entsprechen und bei den meisten anderen wird der TAB genau 4 Leerzeichen entsprechen. Es ist jedoch zu beachten, dass der Editor die Entwicklungsumgebung die Tabs beim Speichern nicht in Leerzeichen konvertiert. Denn das wäre dann fatal! Einige Unix Programmierer werden mich jetzt schlagen, aber ich lege mich nachfolgend auf die Einrückung mittels TAB fest.

Betrachten wir uns folgendes Snippet:

unübersichtlicher Quellcode

$sprache="deutsch";
$vorname="Max";
$nachname="Mustermann";
$strasse="Musterstraße";
$hausnr="10";
$plz="01234";
$ort="Musterstadt";

übersichtlicher Quellcode

$sprache  = "deutsch";
$vorname  = "Max";
$nachname = "Mustermann";
$strasse  = "Musterstraße";
$hausnr	  = "10";
$plz	  = "01234";
$ort	  = "Musterstadt";

Und was liest sich jetzt besser? Klar macht es etwas Arbeit, den Code wie eben gezeigt etwas schöner zu gestalten, aber eins ist sicher: Nachfolgend über den Code blickende Dritte haben sehr viel mehr Vergnügen beim Lesen. Und auch der Autor des Quelltextes wird selbst nach Jahren noch sagen – super übersichtlich! Für Entwickler, die innerhalb eines größeren Teams arbeiten, sollte dieser Stil zu guten Pflicht gehören.

Kommentare

Mit dem Kommentaren haben es die wenigsten Programmierer. Die meisten setzen der Einfachheit gar keine Kommentare. Autsch! Viele Programmierer, die dann doch Kommentare setzen, meinen es mit dem Kommentieren aber leider zu gut. Zum Beispiel sind solche Kommentare hier völliger Blödsinn und können getrost weg gelassen werden.

unsinnige Kommentare

// Sprache des Clienten
$sprache  = "deutsch";
// Vorname des Clienten
$vorname  = "Max";
// Nachname des Clienten
$nachname = "Mustermann";
// Straße des Clienten
$strasse  = "Musterstraße";
// Hausnummer des Clienten
$hausnr      = "10";
// Postleitzahl des Clienten
$plz      = "01234";
// Ort des Clienten
$ort      = "Musterstadt";

Kommentar für gesamten Block

// Clientendaten für Musterdatensatz
$sprache  = "deutsch";
$vorname  = "Max";
$nachname = "Mustermann";
$strasse  = "Musterstraße";
$hausnr	  = "10";
$plz	  = "01234";
$ort	  = "Musterstadt";

Doch wo machen Kommentare eigentlich Sinn?

Ganz einfach. Kommentare sollten Codestrukturen beschreiben, die nicht selbsterklärend sind. Das können zum Beispiel Funktionen, Klassen oder größere Codeblöcke sein. Hier bietet es sich jedoch an, die Kommentare zu konsolidieren beziehungsweise zu bündeln (der Code und der Kommentar sind examplarisch zu sehen).

Beispiel sinnvoller Kommentare

// Berechnung der Gesamtsumme aller Waren innerhalb des Warenkorbs
// Die Beträge in Array $basketItems liegen netto vor! Das Array
// $basketItems enhält folgende Struktur:
// 	[][item] =>
//		[
//			[id] 	=> int,
//			[menge] => int,
//			[preis] => double
//		]
$basketSumNetto  = 0;
$basketSumBrutto = 0;
foreach ($basketItems as $key => $item_x)
{
$basketSumNetto += $item_x ['menge'] * $item_x ['preis'];
}
$basketSumBrutto = $basketSumNetto * 1.19;

• PHPDoc für PHP
• Javadoc für Java
• Rubydoc für Ruby
• PythonDoc für Python

Es gibt quasi für nahezu jede Programmiersprache ein passendes Pendant. Der Vorteil dieser Tools ist neben der Standardisierung die entstehende Quelltext Dokumentation in Form einer übersichtlichen Ansammlung von sämtlichen dokumentierten Quellcode. Beispiel für PHPDoc

Was wir gelernt haben

Es ist nicht entscheidend, eine Quellcode möglichst schnell zu programmieren, sondern möglichst gut lesbar, dokumentiert, durchdacht und fehlerfrei. Die Zeit, die man zur Optimierung des Quelltextes verwendet, spart man sich später beim Debugging oder bei anstehenden Erweiterungen am Quelltext. Man sollte sich als Programmierer einen programmierten Quellcode nach etwas längerer Zeit mit etwas Abstand nochmals ansehen und nach dokumentieren. Das Problem ist nämlich eine Betriebsblindheit. Seinen eigenen Quellcode kennt man zum Zeitpunkt des Schreibens immer. Daher erscheinen viele Dinge logisch, sind es jedoch ganz und gar nicht.

Ich habe mir all diese kleinen Dinge in einem tollen Team angelernt. Natürlich sollten beim gemeinsamen Arbeiten innerhalb eines Teams viele weitere kleine Details schriftlich fixiert und als Style Guide oder wie auch immer man dieses Dokument bezeichnen mag zur Verfügung gestellt werden. Ansatzpunkte könnten hier sein:

• Variablen Buckelschreibweise oder Unterstrichschreibweise
• Festlegung der zu verwendenden Kommentarsyntax (z.B. PHPDoc)
• Codestruktur (z.B. oben Logik unten Ausgabe)
• Instanzen von Objekten mit großen ANfangsbuchstaben

Ein Brainstorming innerhalb eines lockeren Teammeetings wird noch viele weitere Punkte auf die Liste bringen.

HTTP/1.x 200 OK

der Header

HTTP/1.x 301 Moved Permanently

gesendet wird. Und genau diese Modifikation des Header können META REFRESH und Javascript location.href=”bla.html” nicht. Soweit so gut…

Oftmals spricht man der Kürze wegen auch von einem 301 Redirect … mehr über Header kann man bei Wikipedia nachlesen. Das dauerhafte Umleiten von Links kann aus verschiedensten Beweggründen wichtig sein. Einer der Gründe ist das Vermeiden von Duplicate Content, ein anderer könnte eine veränderte Internetadresse sein, …. es gibt sicherlich 1000 Weitere Gründe.

Wie man nun einen Permanent Redirect realisiert und was es dabei zu beachten gibt, habe ich nachfolgend kurz zusammen gefasst.

Wie wird ein Permanent Redirect realisiert?

Kommen wir nun zum eigentlich wichtigen. Zunächst einmal muss sicher gestellt sein, dass man auf dem eigenen Webspace  .htaccess Dateien verwenden kann und das Modul mod_rewrite aktiviert ist. Dies ist in der Regel der Fall. Andernfalls ist der Kurs an dieser Stelle zu Ende lediglich informativer Natur.

Sofern noch keine .htaccess Datei auf dem Webspace angelegt ist, ist das jetzt zu tun. Im Kopf der Datei sollte dann folgendes stehen:

RewriteEngine On
RewriteBase /

Diese HTACCESS Datei wird nun vom Webserver bei jedem Seitenaufruf geladen und konfiguriert diesen quasi nachträglich um. Die Direktive (so nennt man diese Eigenschaften) RewriteEngine weist den Webserver mit dem Wert On an, das Modul mod_rewrite zu aktivieren. RewriteBase ist der relative Startpfad der Webseite (für http://www.schulungs-kurse.de demnach ein einfacher Slash oder liegt die HTACCESS Datei in einem Unterverzeichnis /meinUnterverzeichnis – immer relativ von der Domain gesehen).

Der 301 Redirect für einen Aufruf einer Webseite ohne www auf die gleiche Seite aber mit www könnte so aussehen:

RewriteCond %{HTTP_HOST} !^www\.webtubes\.de$
RewriteRule ^(.*)$ http://www.webtubes.de/$1 [L,R=301]

Kopiert meine Domain http://webtubes.de (ohne www) einfach in ein neues Fensterchen und drückt ENTER. Anschließend wird im Browser die Seite mit www angezeigt. Das Besondere an dieser Umleitung ist, dass aufgerufene Pfade und angehangene Query Strings Parameter an die neue Seite übergeben werden. Ein Aufruf der Seite

http://webtubes.de/bla/huhu.php?q=1

wird also nach

http://www.webtubes.de/bla/huhu.php?q=1

permanent umgeleitet – probiert es ruhig aus (euch grinst ein 404 Error an, da die Zielseite natürlich nicht existiert).

Wichtige Tipps und Beispiele

1. Sollen Query Strings Parameter nicht an die Zielseite angehängt werden, ist an die Zielseite ein Fragezeichen (?) anzuhängen
   

   RewriteRule ^(.*)$ http://www.webtubes.de/$1? [L,R=301]

2. Soll der aufgerufene Pfad beziehungsweise die aufgerufene Datei nicht an die neue Seite angehängt werden, ist die Variable $1 zu entfernen
   

   RewriteRule ^.*$ http://www.webtubes.de/ [L,R=301]

3. Soll nur eine bestimmte Seite umgeleitet werden und nicht blind links alle Seiten, ist die Regel durch Conditions Bedingungen zu erweitern
   

   # bitte nur doofe-seite.html umleiten ok?
   RewriteCond %{REQUEST_URI} ^doofe-seite\.html$
   RewriteRule ^.*$ http://www.webtubes.de/ [L,R=301]
   # … Yes sir

4. Sollen bestimmt Seiten von der Umleitung ausgeschlossen werden – also entgegen gesetzt zu Tip 3 – ist die Regel ebenfalls durch Conditions Bedingungen zu erweitern
   

   # ALLES, aber bitte nicht meine-beste-seite.html umleiten ok?
   RewriteCond %{REQUEST_URI} !^meine-beste-seite\.html$
   RewriteRule ^.*$ http://www.webtubes.de/ [L,R=301]
   # … alles klar Capitano

   Man beachte bei dieser Regel das Ausrufezeichen (!) in der Bedingung, welches die Bedingung im Grunde einfach rum dreht: wenn Seite nicht meine-beste-seite.html mittels 301 Redirect umleiten…

Anmerkungen

Für das permanente Umleiten gibt es weitere Schreibweisen, die jedoch nur auf einem anderen Weg nach Rom führen.  Sollte ich etwas vergessen haben, werde ich diesen Beitrag ergänzen.

Fazit

Das  dauerhafte Umleiten eines Links ist total einfach, vorausgesetzt die Grundlagen werden beherrscht.