Die einfachste Lösung ist eine entsprechende Benennung der Dateien und darüber automatisiert die Einbindung vom Kalenderblatt des aktuellen Monats.
Du benennst die z.B. folgendermaßen: kb01.html, kb02.html, kb03.html etc.
Einbinden dann einfach mittels der date()-Funktion von PHP
http://php.net/manual/de/function.date.php
$file = "kb".date("m").".html";
if(file_exists($file)) {
include($file);
}
else {
echo "Kalenderblatt nicht gefunden.";
}Jetzt kommen wir ein bisschen zu den Feinheiten von Unittests. Aber etwas offtopic schadet ja nicht.
Es geht nicht nur darum, "feinere Testergebnisse" zu bekommen, sondern die evtl. Fehlersuche- und Erkennung so gut wie möglich zu halten.
Allerdings stehst du ja vor einem anderen Problem, dem Testen von Legacy-Code. Zu umfangreiche setup/teardown Methoden weisen meist auf ein verbesserungswürdiges Design des Programms hin.
Aber seis drum, wir sind kurz vor der Haarspalterei
Das Design ist eine ziemliche Katastrophe. 
Es geht aber darum die Software mit der aktuellen Funktionalität in eine stabile Version zu kriegen. Sobald die steht werden große Teile des Cores und einige Module sowieso komplett neu geschrieben.
Ist halt immer schön wenn sich bei einem großen Projekt im Laufe der Entwicklung die Zielsetzung grundlegend ändert und die geforderte Funktionalität sich stark erweitert auf Bereiche, die nie geplant waren. Ist ein ziemliches Flickwerk zur Zeit.
http://www.semanticblog.eu/2011/01/26/eve…ery-verhindern/
Erstes Ergebnis bei google für "jquery eventbubbling verhindern"
Ach ok, das fail() wird da nur ausgelöst wenn die Exception nicht geworfen wird? Ok, dann ist das eine platzsparendere Möglichkeit, auch wenn ich immer noch eher setExpectedException() nutzen würde, ich mag Anweisungen in Annotations nicht so gerne.
Zu den Testmethoden:
Klar, wenn ich für jeden assert eine eigene Testmethode schreibe habe ich gegebenenfalls genauere Angaben was alles bei einer zu testenden Methode nicht passt, weil ich alle fehlgeschlagenen asserts angezeigt bekomme, statt nur den ersten. Das finde ich aber nicht so wild. Entweder besteht eine Methode alle asserts, oder ich muss sie mir sowieso nochmal anschauen, egal ob nun ein assert fehlschlägt oder zwanzig. Ich verstehe aber grundsätzlich dein Argument, du bekommst so präzisere Fehlerberichte.
Ich schreibe zur Zeit tests für ein bestehendes System wo alleine der core weit über 100 zu testende Methoden hat, mit teilweise sehr umfangreichen setup() und teardown()-Methoden. Wenn ich da für jedes assert eine einzelne Methode schreibe komme ich nur für den core auf mindestens 500 test-Methoden. Und ich möchte die tests möglichst schnell halten.
Ja, es gibt auch
$this->setExpectedException()
Aber ich finde es vorteilhaft meine eigenen Ausgaben setzen zu können. Ich prüfe häufig verschiedene Fälle in einer Testmethode auf Exceptions.
Jo, nur Bing und Yahoo werten noch den keywords-Metatag aus und wenn der auch noch zu voll ist, als SPAM. Das macht Google übrigens auch - dass heißt, der Tag kann nur noch schaden, aber nicht helfen.
Bing und Yahoo sind zwei durchaus relevante Suchmaschinen, ganz besonders wenn es um internationale Seiten geht. Google ist natürlich die meistbenutzte Suchmaschine, aber Deutschland ist was das angeht ein Extremfall, in den meisten anderen Ländern liegt google zwar auch vorne, aber häufig bei weitem nicht mit so großem Abstand wie eben in Deutschland.
Also im einen Satz zu sagen, dass Bing und Yahoo die keywords beachten, um dann im nächsten zu sagen keywords könnten nur schaden und nicht helfen, ist doch leicht widersprüchlich.
Ich würde sagen: Setze vernünftige Keywords in einer begrenzten Anzahl, das schadet nicht, kann aber bei manchen Suchmaschinen nützlich sein.
Ein kleines Snippet für PHPUnit um in TestCase-Methoden auf Exceptions zu prüfen und gegebenenfalls eigene Fehlermeldungen ausgeben zu lassen:
$thrown = false;
try {
}
catch( ) {
$thrown = true;
}
if(!$thrown) {
$this->fail("");
}Du pollst doch eh vermutlich alle x Sekunden bei den eingeloggten Usern um zu prüfen ob eine neue Nachricht für sie da ist. Im gleichen Schritt aktualisierst du in deiner User-Tabelle (oder in einer eigenen Tabelle) ein Feld chatLastPolled mit dem aktuellen Timestamp. Gegen dieses Feld kannst du dann prüfen für deine Online-Liste, so in etwa:
SELECT id,name FROM user WHERE chatLastPolled+5>=NOW()Mit PHP 5.2.x gibt das einen Parse-Error und leider kannman sich nicht darauf verlassen, dass auf jedem Server PHP 5.3.x installiert ist.
Richtig, z.B. steht bei Strato (sofern man keinen eigenen Server hat auf dem man selber seine Version installiert) noch kein PHP 5.3 zur Verfügung, wie ich kürzlich feststellen durfte als ich dort nl2br() mit dem seit 5.3 implementierten zweiten Parameter nutzen wollte.
Daher kann ich für Projekte, bei denen man nicht 100% sicher ist, dass sie ausschließlich auf Servern mit PHP 5.3 laufen von der Nutzung entsprechender Features nur abraten - so schade das beizeiten sein mag.
Du kannst dein input type="submit" über CSS umstylen. Oder du verwendest das Button-Tag:
<button type="submit" name="submit">
<img src="../images/button_abschicken.png" alt="">
</button>Was genau klappt denn nicht? "Funktioniert nicht" ist keine adäquate Fehlerbeschreibung.
Reiner Schuss ins Blaue: Nimm statt deinem input type="image" mal input type="submit".
Ja, das wäre hilfreich 
Es sei denn du möchtest gerne, dass der Fehler weiterauftritt.
Und dann schleunigst die Datei löschen.
Ich geh natürlich davon aus, dass er diese Datei nur auf seinem (geschützten) localhost hat
Wenn du Accounts erstellen können willst, musst du schon beim Einfügen das Feld auf den Hashwert setzen, also sowas wie "INSERT INTO `users` (`name`, `pass`) VALUES ( '" . mysql_real_escape_string($neuername) . "', '". mysql_real_escape_string(myhash($neuespasswort)) . "')"
Das mysql_real_escape_string() beim Passwort stört zwar nicht, ist aber überflüssig, da myhash() keine potentiell gefährliche Strings zurückliefert.
<?php
// Funktion myhash() einbinden
echo myhash("meinPasswort");
?>
Damit kannst du dir erstmal dein Passwort so ausgeben lassen wie du es dann über phpmyadmin eintragen kannst, als myhash()-hash.
Die Schreibweise die er nutzt gibt es auch. Und ich gehe mal davon aus, dass er die Stelle an der eine schließende geschweifte Klammer fehlt mittlerweile gefunden hat.
Ich würde dafür auch zu einer Library raten. JQuery bietet beispielsweise fertige Draggable- und Droppable-Widgets.
http://jqueryui.com/demos/droppable/
Alles klar ihr habt Recht. 
Dann können wir die Diskussion ja abschließen.
Richtig. Allerdings müssen die configs, die bei mir in diesem Format vorliegen, nicht in andere sprachen ausser PHP. Darüber habe ich mir auch keine Gedanken gemacht sondern einfach gesagt, SO sollen die aussehen und dann den Parser geschrieben.
Wir drehen uns im Kreis.
Das ist ja auch vollkommen ok wenn bei dir solche Files auch von Leuten kommen denen du nicht gestatten willst PHP-Dateien anzulegen. Bei mir ist das eben nicht der Fall und daher bietet mir die Klasse keinen Mehrwert. Bei meiner ursprünglichen Kritik habe ich mich hauptsächlich an dem Wort ini aufgehangen, weil das ein standardisiertes Format impliziert und somit irreführend ist.
Ähm, nein, wenn du PHP zulässt zur Konfiguration, werden sich mit Sicherheit nicht alle darauf beschränken, eine ganz eingeschränkte Teilmenge von PHP zu benutzen (nur <?, array, Strings, Zahlen und Kommentare z.B.).
Das ist ein völlig anderer Aspekt als der von dir angesprochene Punkt der Sichtbarkeit (-> $GLOBALS) auf den ich eingegangen bin.
Zu dem Sicherheitsaspekt habe ich schon was geschrieben, nämlich, dass ich in meinen Systemen sowieso niemanden Konfigurationsdateien anlegen lasse, dem ich nicht auch genug vertraue um ihn PHP-Dateien anlegen zu lassen. Userspezifische Style-Definitionen o.ä. die offen für jeden Benutzer sind werden von den Usern über eine entsprechende Eingabemaske im Frontend gemacht und ich entscheide wie ich die dann ablege.
Genau, den Punkt hatten wir ja schon. Übrigens ist das mit dem PHP Parsen nochmal viel komplexer. Ich wette, die Klasse wäre (natürlich nur fürs array, Strings und Zahlen) mindestens 3mal so groß. Und wenn dann doch jemand anderen PHP Code reinschreibt, dann schlägt der parsrr fehl. Oder wenn jemand ein ($x!=$y ? "a" : "b") reinschreibt? Ein PHP Parser macht hier glaube ich keinen Sinn.
Wenn ich Vorgaben mache wie der PHP-Array notiert sein muss (wie es ja auch bei deinem File der Fall ist) ist das kein großer Unterschied, ich habe dann halt Hochkommata um die Keys und Values, eine Zuweisung per => statt per = und ein Komma am ende der Zeile.
Trotzdem würde ich für Konfig-Dateien die evtl auch in anderen Sprachen verwendet werden müssen ein standardisiertes Format verwenden, und nicht einen PHP-Array oder ein eigenes Format das auf eine bestimmt PHP-Klasse angewiesen ist.
Ach komm, wieso sollte ich das in $GLOBALS schreiben? Das ist doch Unfug. Ich schreibe das in einen ganz normalen Array den ich dan genau an der Stelle einbinde wo ich ihn brauche. Das ist NULL Unterschied zu so nem Config-File, das wird dann halt an der Stelle geparst und gibt mir den Array zurück. Das Ergebnis ist 100% identisch.
Und ganz ehrlich, wenn ich sowieso in einer anderen Sprache wieder ein neues Script zum parsen der Config-Datei schreiben muss, weil sie eben keine gängigen Konventionen nutzt, dann kann ich mir auch nen Script schreiben, das mir nen PHP-Array parst. Wenn der vernünftig geschrieben ist ist das genauso easy.
