Eure PHP Snippets.

also im büro hab ich eigentlich net viel^^

ich hab ne helpers-klasse die mir auch nen pre mit print_r auswirft und das reicht eigentlich schon.
dann mach ich meist ne konstante debug am anfang des projekts auf true oder false und kombininiert mit dem debug-funktiönchen is des recht entspannt, denn ich kann an den stellen wo ich es brauch nen debug ausgeben lassen und muss es am ende nichma entfernen weil ich dazu nur die konstante wieder auf false setzen muss

so, hier haste ma 3 snippets

function vDebug($pmixValue) {
      if(DEBUG){
        echo "<pre>";
            print_r($pmixValue);
        echo "</pre>";
      }
}


function generateRandomCode($strLengt, $md5coded=null) {
        $intLength     = $strLengt;
        $strChars     = "abcdefghijklmnopqrstuvxwyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
        $strCode    = "";
        mt_srand ((double) microtime()*1000000);
        for ($i=0; $i<$intLength; $i++) {
            $strCode .= $strChars{mt_rand(0,strlen($strChars)-1)};
        }

        if ($md5coded != null) {
            return md5($strCode);
        } else {
            return $strCode;
        }
    }


    function cleanInsert($strDirty) {
        $strDirty = trim($strDirty);
        if(get_magic_quotes_gpc() == 1) {
            $strDirty = stripslashes($strDirty);
        }
        $strClean = mysql_real_escape_string($strDirty);
        return $strClean;
    }

Den verwend ich am Anfang von meinen Scripts:

if($_SERVER['SERVER_NAME']=='localhost')
{
	@ini_set('display_errors', 1);
	error_reporting(E_ALL);
}else
{
	@ini_set('display_errors', 0);
	error_reporting(E_NONE);
}

Hab das mal als Sticky eingerichtet, mal sehen, ob was aus der Sammlung wird

Zitat von Unregistriert

Das error_reporting auf 'localhost' umzusetzen ist genauo sinnvoll wie es auf einem webserver umzustellen. Auf einem lokalen server stellt man doch die sache in der php.ini ein und auf einem webserver sollte man die finger davon lassen. Das einzige, wozu der man das snippet von dodo nutzen koennte, waeren unterschiedliche konfigurationen.

Also ich bin mit dem Code bis jetzt immer gut gefahren.
Es passiert genau das, was es soll - und das, ohne in der Konfiguration rumpfuschen zu müssen - also absolut anfängertauglich und damit perfekt für ein Forum und einen solchen Thread geeignet - ich versteh dien Problem damit nicht.

Vor allem dein "auf einem webserver sollte man die finger davon lassen"...
Warum sollte mir beim Webauftritt - der ja immerhin Kunden anwerben soll - eine Fehlermeldungen mein Design zerstören.
Lokal ist das okay - da will man es ja sogar.

Zitat von Unregistriert

Weil man fehler abfangen sollte?! Da sollte es keine fehlermeldung von php geben

Und da es als Grundsatz gilt, dass Software nicht fehlerfrei erstellt werden kann und niemals alle Eventualitäten berücksichtigt werden können - vor allem bei komplexeren Aufgaben und aufwändigeren Algorithmen, wirds sich beinahe immer irgendwo, irgendwie eine Fehlermeldung befinden - und die sollten gerade bei potentiellen Kunden nicht auftauchen.

Zitat von Unregistriert

Und deshalb sprach ich von der php.ini.

Und genau deshalb sprach ich von Anfängertauglichkeit.

Zitat von Unregistriert

Zur not kann man das bei problemen bei einem script einbauen, dann kann man aber auf die if-abfrage verzichten.

...und das bringt genau? Komm jetzt bitte nicht mit Performance oder "schlankerem Quelltext".
Der Vorteil an der Lösung ist,d ass man das Problemlos drin lassen kann und trotzdem beide Möglichkeiten hat.

Zitat von Dodo

Den verwend ich am Anfang von meinen Scripts:

PHP

if($_SERVER['SERVER_NAME']=='localhost')
{
	@ini_set('display_errors', 1);
	error_reporting(E_ALL);
}else
{
	@ini_set('display_errors', 0);
	error_reporting(E_NONE);
}

Diese Beispiel sollte auf keinen Fall im tatsächlichen Live-Betrieb verwendet werden (und lokal kann man sich die Prüfung dann auch schenken).
Der Wert in $_SERVER['SERVER_NAME'] ist nicht sicher und kann über den per HTTP gesendeten Host geändert werden. Damit kann dann prinzipiell jeder an die PHP-Fehlermeldungen kommen.
http://shiflett.org/blog/2006/mar/…ersus-http-host

Zitat von SinnlosS

Diese Beispiel sollte auf keinen Fall im tatsächlichen Live-Betrieb verwendet werden (und lokal kann man sich die Prüfung dann auch schenken).
Der Wert in $_SERVER['SERVER_NAME'] ist nicht sicher und kann über den per HTTP gesendeten Host geändert werden. Damit kann dann prinzipiell jeder an die PHP-Fehlermeldungen kommen.
http://shiflett.org/blog/2006/mar/…ersus-http-host

Noch nicht gewusst, danke!
Eine Alternative: Die IP-Adresse des Servers prüfen.

Zitat von Dodo

Noch nicht gewusst, danke!
Eine Alternative: Die IP-Adresse des Servers prüfen.

Ich hatte es auch nicht sicher gewußt, hatte nur im Hinterkopf mal etwas über Unsicherheit bei $_SERVER-Attributen gelesen zu haben. Und habe dann gerade mal nach gegoogled. Fand ich auch interessant zu wissen, man lernt nie aus.

Zitat von Grevas

Peinlich, aber mir ist erst jetzt aufgefallen, dass ich es viel zu oft per Hand mach:

Doppelpunkte schützen vor Mißverständnissen

Wozu genau ist denn der Code gut?

Die hier verwende ich häufiger Mal:

function getDayDiff($date1,$date2=null,$format="Y-m-d") {
	$date2 = $date2!==null ? $date2 : date("Y-m-d");
	switch($format) {
		case "Y-m-d H:i:s":
			$date1  = array_shift(explode(" ",$date1));
			$date2  = array_shift(explode(" ",$date2));
			$format = "Y-m-d";
		case "Y-m-d":
			list($year1,$month1,$day1) = explode("-",$date1);
			list($year2,$month2,$day2) = explode("-",$date2);
			break;
		case "d.m.Y H:i:s":
			$date1  = array_shift(explode(" ",$date1));
			$date2  = array_shift(explode(" ",$date2));
			$format = "d.m.Y";
		case "d.m.Y":
			list($day1,$month1,$year1) = explode(".",$date1);
			list($day2,$month2,$year2) = explode(".",$date2);
			break;
		case "Ymd":
		case "YmdHis":
			$year1  = substr($date1,0,4);
			$month1	= substr($date1,4,2);
			$day1   = substr($date1,6,2);
			$year2  = substr($date2,0,4);
			$month2	= substr($date2,4,2);
			$day2   = substr($date2,6,2);
			break;
	}
	$dayDiff = gregoriantojd($month1,$day1,$year1)-gregoriantojd($month2,$day2,$year2);
	return $dayDiff>0 ? $dayDiff : $dayDiff*(-1);
}

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("");
}

das geht mit Annotations bedeutend einfacher und übersichtlicher

/**
 *@expectedException MyException
 */
public function testMyFunctionThrowsMyException()
{
    $class = new myClass();
    $class->myFunction();
}

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.

ohne deine Methode schlecht machen zu wollen

/**
 *@expectedException MyException
 */
public function testMyFunctionThrowsMyException()
{
    $class = new myClass();
    $class->myFunction();
    $this->fail('Meine Fehlermeldung');
}

funktioniert einwandfrei.

Zitat

Ich prüfe häufig verschiedene Fälle in einer Testmethode auf Exceptions.

Das wiederum ist (wenn auch nicht unüblich) schlechter Stil
Wenn es ausser Faulheit keinen triftigen Grund gibt, sollte nur ein assert pro Test vorhanden sein.