Viel zu oft wird die Frage “Wie lösche ich ein Verzeichnis rekursiv?” mit einem 100-Zeilen Skript beantwortet. Schade eigentlich, denn viele Programmierer haben sich immer noch keine Mühe gemacht die Änderungen von PHP5 wahrzunehmen. Dabei würde sich ein genauerer Blick lohnen, die Antwort auf diese Frage ist seither sehr kurz und einfach geworden:

function recursive($dest)
{
	$list = array_diff(scandir($dest), array('.', '..'));
	foreach ($list as $value) {
		$file = $dest.'/'.$value;
		if (is_dir($file)) { recursive($file) } else { unlink($file) }
	}
	return rmdir($dest);
}

Wie wir sehen, passt das sehr einfach in 9 Zeilen. Was geschieht denn genau? Zuerst lesen wir das Verzeichnis, das wir beim Funktionsaufruf mitgegeben haben aus (scandir()) und entfernen danach “.” (aktuelles Verzeichnis) und “..” (übergeordnetes Verzeichnis). Das muss sein, denn sonst würden wir bei ersterem in eine Endlosschleife geraten und bei letzterem über das Ziel hinaus schiessen und übergeordnete Dateien löschen. Sobald wir also unsere Liste haben, gehen wir sie durch und prüfen ob es sich um ein Verzeichnis handelt oder nicht. Ist es eins, so wird die gesamte Prozedur nochmal darauf angewandt – andernfalls wird die Datei einfach gelöscht und das geht dann so lange bis nichts mehr übrig ist.

Verwendet wird es übrigens folgendermassen:

if (recursive('./bilder')) {
	print "super, hat geklappt.";
} else {
	print "ohje, bestimmt hab ich keine berechtigung dazu.";
}

Schlägt der Funktionsaufruf fehl, erscheinen (je nach tiefe der Verzeichnise) von PHP generierte Fehlermeldungen.

Ein ganz wichtiges Kapitel, vorallem wenn es um die Planung eines etwas grösseren Projektes geht, ist das Thema Fremdschlüssel. Fremdschlüssel verbinden (meist tabellenübergreifend) Einträge. Nehmen wir an, wir haben eine “Mitglieder”-Tabelle. Diese Tabelle besitzt die Spalten “id” und “name” wobei ersteres der Primärschlüssel ist:

Nun fügen wir eine weitere Tabelle namens “Tagebuch” hinzu. Sie beinhaltet die Spalten “id”, “mitglied_id” und “eintrag”. Der Primärschlüssel ist “id” und auf “mitglied_id” liegt ein Index:

Der Index ist (je nach DBS) optional aber dringend empfohlen, da es sonst (vorallem mit wachsender Anzahl an Daten) zu starken Geschwindigkeitseinbussen kommen kann. Wir befüllen also die erste Tabelle:

INSERT INTO Mitglieder (id, name) VALUES (42, 'A. Merkel');

und dann noch die zweite:

INSERT INTO Tagebuch (id, mitglied_id, eintrag) VALUES (1, 42, 'I am beautiful, no matter what they say...');

Damit es nicht zur Verwirrung kommt habe ich unserem Mitglied die “id” 42 gegeben. Doch was passiert wenn wir den Eintrag löschen? Nichts. Und genau das ist das Problem: Sobald wir das versuchen würden, müssten wir dafür sorgen dass in allen Untertabellen sämtliche Relationen aktualisiert werden. Da sowas aber je nach Umfang des Projektes sehr kompliziert enden kann, geben die Datenbanksysteme uns eine sehr nützliche Funktionalität:

ALTER TABLE Tagebuch ADD FOREIGN KEY (mitglied_id) REFERENCES Mitglieder(id) ON UPDATE CASCADE ON DELETE CASCADE;

Wir haben soeben erfolgreich einen Fremdschlüssel von “Tagebuch:mitglied_id” zu “Mitglied:id” definiert. Bildlich würde das ganze so aussehen:

Wenn wir jetzt unserem Mitglied eine neue “id” verpassen oder es komplett löschen, geschieht es seinen Tagebucheinträgen gleich. Ausserdem ist es jetzt nicht mehr möglich einen Eintrag mit ungültiger “mitglied_id” in das Tagebuch einzufügen.

Es gibt 5 Reaktionen bei Fremdschlüssel:

** NO ACTION, Verweigert die Änderung und löst ein Fehler aus.
RESTRICT, Verweigert die Änderung und löst ein Fehler aus.
CASCADE, Reagiert gleich wie sein Parent.
SET DEFAULT, Setzt den Standardwert.
SET NULL, Setzt NULL.

** Bei dieser Option ist eine verzögerte Überprüfung möglich um so einer Verletzung der Regel zuvorzukommen.

Information 1: Der Datentyp TEXT gehört nicht zum SQL-Standard. Deshalb wurde VARCHAR ohne Längenangabe verwendet.

Information 2: Das Datenbanksystem MySQL macht keinen Unterschied zwischen “NO ACTION” und “RESTRICT”.

Information 3: Unter MySQL sind Fremdschlüssel nur mit der Datenbankengine InnoDB möglich. Standard: MyISAM.

PHP bietet unter foreach eine Möglichkeit an, die Werte des originalen Arrays direkt anzusprechen. Programmierer die von dieser Möglichkeit nicht bescheid wissen, bauen dann oftmals Konstrukte wie:

foreach ($array as $key => $value) {
	$array[$key] = funktionsname($array[$key]);
}

Bei diesem Beispiel wird der Wert des Arrays einer Funktion übergeben und danach überschrieben. Dabei ginge es viel einfacher:

foreach ($array as &$value) {
	$value = funktionsname($value);
}

Hier wird eine Referenz auf “value” gesetzt. Eine Referenz ist eine weitere Variable die auf den gleichen Wert im Speicher zeigt. Im Umkehrschluss wird der Speicher auch erst dann wieder freigegeben, sobald keine Variable mehr auf den Wert zeigt.

Was man öfters bei grossen Seiten wie PayPal o.ä. sieht, ist das deaktivieren von Formularen nach dem Versand. Das ganze wird mit JavaScript realisiert und dient dazu dem herkömmlichen Benutzer Doppelpostings zu verbieten. Ein wirklicher Schutz ist das natürlich nicht denn JavaScript ist deaktivierbar. Es hat aber dennoch seine Existenzberechtigung:

function troughForms(sent)
{
	var len = document.forms.length;
	for (var i = 0; i < len; i++) {
		var elem = document.forms[i];
		if (sent) { disableForm(elem) } else { appendEvent(elem) }
	}
}
function disableForm(form)
{
	var len = form.elements.length;
	for (var i = 0; i < len; i++) {
		var element = form.elements[i];
		element.disabled = true;
		element.blur();
	}
}
function appendEvent(form)
{
	form.onsubmit = function ()
	{
		this.submit();
		troughForms(true);
		return false;
	}
}
window.onload = function () { troughForms(false) }

Erstmal tief Luft holen. Das sieht kompliziert aus – ist es aber nicht. Dreh- und Angelpunkt des ganzen ist troughForms(). Diese Funktion geht das gesamte Dokument durch und entscheidet anhand des Parameters ob er ein onsubmit-Event an das Formular anhängt oder es komplett deaktiviert. Beim ersten mal wird es natürlich dazu benutzt allen Formularen auf der Seite ein Event zu verpassen. Beim Versand passiert dann genau das Gegenteil. Die gleiche Funktion ist also für das Setup und den Gebrauch zuständig.

Die Vorteile an diesem Beispiel sind:
- nichts muss am Markup geändert werden.
- nicht nur der “Senden”-Knopf wird deaktiviert sondern das gesamte Formular.
- nicht nur das versandte sondern jedes Formular auf der Seite wird deaktiviert.

Um das ganze zu verwenden, müssen wir den JavaScript-Code (oben) in eine Datei speichern. In unserem Fall wählen wir deactivate.js, die wir dann im HTML-Dokument folgendermassen einbinden:

<script type="text/javascript" src="./deactivate.js"></script>

Geschafft. Übrigens wäre das ganze mit addEventListener('submit', ...) sicher moderner gewesen aber nicht jeder Browser unterstützt es. Und bei eingefügter Browserkompatibilität wäre der Code dann mindestens gleich gross aber nicht gleich schön.

Jeder kennt es, keiner will es: Race-Conditions. Ein Benutzer registriert sich und versendet versehentlich zweimal hintereinander das gleiche Formular. Wer jetzt zuerst zählt:

SELECT COUNT(*) AS total FROM tabelle WHERE mail = 'user@example.com';

und danach gleich einfügt:

INSERT INTO tabelle (mail) VALUES ('user@example.com');

läuft Gefahr Opfer einer Race-Condition zu werden.

Was ist das und was passiert genau?

Das ist eigentlich ganz einfach erklärt. Wenn wir zweimal das gleiche Formular versenden, durchläuft der Server zweimal die gleiche Datei. Ist der zeitliche Unterschied zwischen den beiden Aufrufen genug klein, ergibt sich bei beiden bei der ersten Zählung 0 und es wird danach auch bei beiden eingefügt. Da Spalten wie “mail” aber üblicherweise einen “unique-constraint” oder eben einen “unique-functional-index” besitzen, kommt es zum schlimmsten: Der spätere der beiden Aufrufe schlägt fehl und wird mit einem Fehler quittiert: Der Datensatz ist bereits vorhanden.

Aber abgebrochene Aufrufe werden vom Server ja auch abgebrochen?

Mit den Standardeinstellungen schon. Oftmals entscheiden sich Programmierer aber dazu “ignore_user_abort” zu benutzen was ja auch seinen guten Grund hat. Beispiel Bilderupload: Dort wird üblicherweise ein SQL-Query versandt und danach die Datei im Dateisystem entsprechend untergebracht. (Das ganze geht auch umgekehrt) Wenn der Benutzer jetzt zwischen einer der beiden Aktionen seinen Aufruf abbricht, haben wir einen losen Datensatz in der Datenbank oder im Dateisystem. Die Integrität wäre verloren. Ein weiteres Beispiel wäre eine Tabelle in der alle Besuche eines Mitglieds bei einem anderen Mitglied gespeichert werden natürlich mit einem “unique-constraint” über from_id und dest_id:

UPDATE tabelle SET visited = NOW() WHERE from_id = 1 AND dest_id = 2;

Wer sich jetzt nur auf die betroffenen Zeilen verlässt und danach gleich einfügt:

INSERT INTO tabelle (from_id, dest_id, visited) VALUES (1, 2, NOW());

hat wieder eine wunderschöne und noch viel wahrscheinlich eintreffendere Race-Condition erstellt. Bei diesem Beispiel reicht es sogar aus ein Mitglied, welches noch nie besucht wurde, zweimal schnell hintereinander (Doppelklick) zu besuchen was ja nun wirklich nicht realitätsfremd ist.

Was kann ich dagegen tun?

Das ist jetzt eben der trickreiche Teil des ganzen. Er nennt sich “INSERT INTO … SELECT” mit einem Subquery und sieht aus wie folgt:

INSERT INTO tabelle (mail) SELECT 'user@example.com' WHERE (SELECT COUNT(*) FROM tabelle WHERE mail = 'user@example.com') = 0;

und für das zweite Beispiel:

INSERT INTO tabelle (from_id, dest_id, visited) SELECT 1, 2, NOW() WHERE (SELECT COUNT(*) FROM tabelle WHERE from_id = 1 AND dest_id = 2) = 0;

Das war es auch schon. Wenn wir jetzt noch sauberkeitshalber die betroffenen Zeilen abfragen, können wir eine schön formatierte Meldung über den (Miss-)Erfolg ausgeben.

Ein Projekt wird realisiert und dabei wird eines viel zu oft vergessen: Die richtige Handhabung der E-Mailadressen. Üblicherweise erstellt der Initiator des Projektes eine Tabelle mit der Spalte “mail”, setzt sie auf unique und gibt sich damit zufrieden. Doch aufgepasst: Je nach Einstellungen des Datenbanksystems oder der Verbindung ist die unique-Spalte case-sensitive. Das bedeutet sie unterscheidet zwischen Gross- und Kleinschreibung. Dann wird es möglich, sich mit ein- und derselben E-Mailadresse mehrmals zu registrieren. Zum Beispiel:

“user@example.com” und “User@example.com”

Ausserdem entfernen die meisten MTAs überschüssige Leerzeichen am Anfang und am Ende der E-Mailadresse.  MTAs (Mail Transfer Agent) sind Programme, die nach dem Aufruf von mail() eine E-Mail im Hintergrund versenden. Ein Beispiel für diesen Fehler:

“user@example.com” und ” user@example.com”

Für die Datenbank sind das nicht die gleichen Strings – für manche MTAs schon. Daraus ergibt sich, vorallem in Kombination beider Fehler, eine imense Anzahl an Möglichkeiten sich mit der gleichen E-Mailadresse zu registrieren.

Nun gibt es grundsätzlich 2 Varianten dem entgegenzutreten. Die erste wäre folgende Funktion:

function address($mail)
{
	$revised = strtolower(trim($mail));
	return $revised;
}

Bei diesem (durch PHP gesicherten) Beispiel muss einfach sichergestellt werden, dass die Funktion überall dort Verwendung findet wo eine E-Mailadresse entgegengenommen wird. Das zweite Beispiel wäre ein sogenannter “functional index” im DBS. Das sind Indizes die einer gewissen Regel (Funktion) obliegen:

CREATE UNIQUE INDEX name_vom_index ON tabelle(lower(trim(spalte)));

Ich bin mir nicht sicher ob MySQL letzteres unterstützt. PostgreSQL tut es zumindest.

Jeder Programmierer der früher oder später eine Registration erstellen will, wird um eines nicht herum kommen: Ein Passwortgenerator. Die meisten dürften wissen, wie zufällige Zahlen generiert werden – ganz anders sieht es jedoch bei Buchstaben aus. Hier ein Beispiel mit der Funktion chr():

function password($length = 10)
{
 
	$pass = "";
 
	for ($i = 0; $i < $length; $i++) {
 
		$rand = rand(0, 1) ? rand(65, 90) : rand(97, 122);
 
		$pass .= chr($rand);
 
	}
 
	return $pass;
 
}

Was passiert genau? Beim Funktionsaufruf wird erstmal ein leerer String namens “pass” erstellt. Danach wird in einer for-Schleife Buchstaben für Buchstaben an “pass” angehängt. Dazu wird eine zufällige Zahl zwischen 65-90 oder 97-122 generiert, die wir danach an chr() übergeben. Die Funktion chr() erwartet den Indexwert eines ASCII-Zeichens. Ein weiterer Weg um ein Zufallspasswort zu generieren sieht wie folgt aus:

function password($length = 10)
{
 
	$pass = "";
 
	$char = array_merge(range("a", "z"), range("A", "Z"));
 
	for ($i = 0; $i < $length; $i++) {
 
		$rand = array_rand($char);
 
		$pass .= $char[$rand];
 
	}
 
	return $pass;
 
}

Das zweite Beispiel ist ziemlich ähnlich wie das erste. Zuerst wird ein leerer String namens "pass" erstellt. Danach werden 2 Arrays (a-z, A-Z) zu einem zusammengeführt (array_merge()). In der Schleife wird dann jeweils ein zufälliger Index des neuen grossen Arrays ausgesucht und im nächsten Schritt den Wert von ihm an "pass" angehängt. Verwendet werden unsere Funktionen übrigens folgendermassen:

$pwd = password();
/*
In $pwd befindet sich jetzt ein zufälliges Passwort.
Die Standardlänge ist, wie oben ersichtlich, 10.
Mittels Argument können wir das ganze auch selber bestimmen:
*/
$pwd = password(12);
// Jetzt befindet sich in $pwd ein Passwort mit der Länge 12.

Welches der Funktionen du verwendest ist geschmackssache und somit letztlich dir überlassen. Es empfiehlt sich aber für das Verständniss mindestens einmal beide auszuprobieren.

Immer wieder wird in Foren oder im IRC strpos() empfohlen um zu prüfen ob etwas in einem String vorkommt. Sehen wir uns einmal an warum substr_count() besser dazu geeignet ist:

$str = "ich bin ein teststring";
 
if (strpos($str, "bin")) { // liefert die Position zurück, Integer: 4
	// Dieser Block wird ausgeführt.
} else {
 
}

Funktioniert ganz gut. Doch was passiert wenn wir nach “ich” suchen?

$str = "ich bin ein teststring";
 
if (strpos($str, "ich")) { // In dem Fall Integer: 0
 
} else {
	// Dieser Block wird ausgeführt.
}

Was ist passiert? Wir sehen im zweiten Beispiel, dass der else-Teil ausgeführt wird obwohl ein Vorkomniss gefunden wurde. Das liegt ganz einfach daran, dass strpos() eine Positionsangabe zurückliefert und wie wir alle wissen ist 0 für den Computer die erste Zahl. Da der Integerwert 0 aber auch für bool(false) steht, springt er in den else-Teil. Wir müssen bei strpos() also nicht nur den Wert sondern auch den Typ prüfen denn diese Funktion kann je nach Ergebniss 0 oder false zurückliefern was nicht das gleiche ist. Korrekt wäre also:

$str = "ich bin ein teststring";
 
if (strpos($str, "ich") !== false) { // Hier auch Integer: 0
	// Dieser Block wird ausgeführt.
} else {
 
}

Fazit: Wenn man einfach nur wissen will ob sich etwas in einem String befindet, sollte man substr_count() benutzen. Wer jedoch die Position braucht oder Gewicht auf (meiner Meinung nach vernachlässigbarer) Performance legt kann auch strpos() nutzen, sollte allerdings nicht vergessen den Typ der Rückgabe zu prüfen.