Array echo'en

<?php echo '<pre>'.print_r($array, 1).'</pre>'; ?>

Zo krijg je een duidelijker beeld in de levels van de array's, als dat is wat je bedoelt althans..

@dees040
Ik heb even een voorbeeld voor je online gezet, zo kan iedereen zien wat er gebeurd.

Demo: http://84.105.129.190/demo/print_r.php

Code:

<?PHP
/**
 * Example for Ictscripters.com
 */
 if (!function_exists("print_r_pre"))
 {
	 function print_r_pre( $array )
	 {
		 return '<pre>' . print_r($array, 1) . '</pre>';
	 }
 }
 
 $array = array(
 	"Waarde 1"	=> "Value 1",
	"Waarde 2"	=> array(
		"Waarde 2.0"	=> "Value 2.0",
		"Waarde 2.5"	=> "Value 2.5"
	),
	"Waarde 3"	=> "Value 3"
 );
 
 echo print_r_pre( $array );

Maak er vaak een functie van, scheelt wat programmeer werk en is makkelijker te onthouden voor gebruik.

Hier zou nog user input in kunnen zitten.

Met bijvoorbeeld JavaScript. Met AJAX calls.

De bovenstaande functie vervult zijn rol wel, maar is NIET VEILIG.

ESCAPE ALTIJD OUTPUT, tenzij je hier een speciale - en gedocumenteerde - reden voor hebt.

Een veilig alternatief zou dus zoiets zijn (aanname: character encoding UTF-8):

<?php
function dump($a) {
    echo '<pre>'.htmlspecialchars(print_r($a, true), ENT_QUOTES, 'UTF-8').'</pre>';
}
?>

Waarom zo ingewikkeld? Voor debugging kun je toch het beste zoiets als dit doen:

<?php
$array = [];
var_dump($array);
die();

Eventueel kun je ook nog zoiets maken als:

<?php


function dd($data) {
    var_dump($data);
    die();
}


dd('string'); // Geeft output en stopt het script.

Lijkt mij makkelijker en korter.

Lijkt mij stukken slechter leesbaar, maar to each his own I guess. Probeer het allemaal uit en kijk wat je het fijnste vindt werken.

var_dump() escaped trouwens geen output en dat is uit oogpunt van veiligheid / makkelijk debuggen wellicht wel niet bepaald handig.

Vergelijk:

<?php
// Force UTF-8.
header('Content-Type: text/html; charset=UTF-8');


$test = array('<script>while(1) alert(\'irritant he\')</script>');


function dd($data) {
    var_dump($data);
    die();
}
dd($test);
?>

Met:

<?php
// Force UTF-8.
header('Content-Type: text/html; charset=UTF-8');


$test = array('<script>while(1) alert(\'irritant he\')</script>');


function dump($a) {
 echo '<pre>'.htmlspecialchars(print_r($a, true), ENT_QUOTES, 'UTF-8').'</pre>';
}


dump($test);
?>

Citaat van sjaakmans

Waarom zo ingewikkeld? Voor debugging kun je toch het beste zoiets als dit doen:

PHP

<?php
$array = [];
var_dump($array);
die();

Eventueel kun je ook nog zoiets maken als:

PHP

<?php


function dd($data) {
    var_dump($data);
    die();
}


dd('string'); // Geeft output en stopt het script.

Lijkt mij makkelijker en korter.

Inderdaad, dd staat voor Die & Dump

En wat als je nu meerdere stukken data / arrays wilt dumpen? Dan is deze functie niet bruikbaar omdat deze stopt na de eerste dump.

Functies dienen flexibel en herbruikbaar te zijn. In dat opzicht zou het misschien een verbetering zijn om een optionele tweede parameter mee te geven die aangeeft of het programma verder moet gaan / moet stoppen met het uitvoeren van code.

<?php
function myDump($data, $stop=false) {
    // do something to dump $data
    // ...
    if ($stop) {
        exit;
    }
}
?>

Persoonlijk zet ik zelf altijd (tijdelijk) exit's en die's in code zelf, meestal na een of meer dumps. Dit omdat het niet echt de taak is van een functie voor het dumpen van data om de executie van het programma te stoppen. Dit zijn echt twee verschillende taken en horen dan ook eigenlijk niet thuis in een en dezelfde functie...

Daarbij is het rechtstreeks naar het scherm dumpen van data zonder escaping om eerder genoemde redenen (en aangetoond met bijbehorend voorbeeld) niet veilig.

+1 voor het scheiden van het debuggen van data en het beeindigen van de applicatie
-2 want nog steeds niet veilig

Nogmaals: var_dump() escaped géén output.

Misschien moet het gewoon een keer grondig misgaan voordat jullie tot inkeer komen. Een gebrande hand is in het algemeen de beste leermeester.

Waarom stel je bovenstaande oplossing dan voor?

Bij het beantwoorden van een vraag zou je voorbij moeten gaan aan het simpelweg beantwoorden van de vraag maar ook zelf opgedane kennis en ervaring hierin moeten verwerken.

Indien een vraag een oplossing zoekt in een verkeerde richting of wanneer de aanpak gewoon krom is dan moet je niet voortborduren op deze verkeerde richting/aanpak maar simpelweg aangeven dat de aanpak veranderd moet worden.

Output escaping zou in alle facetten van (PHP) programmeerwerk moeten zitten, ongeacht de omgeving.

Citaat van D.Oomens

dus dat zal niet zo'n probleem zijn.

Het is niet heel erg ver gezocht dat de data van je development omgeving een afspiegeling is van je live omgeving. Het is ook niet altijd zo dat een development omgeving compleet is afgeschermd van de buitenwereld.

Ook is het niet gegarandeerd dat je enkel data dumpt op een ontwikkelomgeving. Soms gebeurt het wel eens dat bepaalde kwesties alleen "live gedebugged" kunnen worden.

Het (soms) niet escapen van (user) data vormt te allen tijde een potentieel risico. Dit risico kun je niet het hoofd bieden door simpelweg te zeggen "dat zal niet zo'n probleem zijn". Assumption is the mother of all f*ckups. Op eenzelfde wijze kun je daaropvolgende inbraken / veiligheidslekken / diefstal van gevoelige informatie van zo'n foutieve aanname niet verexcuseren met "oeps".

Citaat van D.Oomens

Maar ook op mijn development environment wordt alles ge-escaped. So no worries .

Hier gaat het ook niet om. Je stelt iets voor (waarvan je weet) dat (het) (potentieel) onveilig is. Mja, no worries, zo lang je je eigen schaapjes maar op het droge hebt?

Predik ajb geen slechte programmeergewoontes, hoe onschuldig deze ook in eerste instantie lijken te zijn. Je weet namelijk niet hoe je codesnippets worden gebruikt.

Nnet zoals met medicijnen zou een codesnippet met een bijsluiter of in ieder geval een "word of warning" of toelichting moeten komen... Simpelweg een codefragment plaatsen zonder enig commentaar vertelt je niets over het wat en (wellicht nog belangrijker) ook niet over het waarom. Je kunt hier dan ook niet uit afleiden of deze met een zekere rationele gedachtengang totstand is gekomen, of zo maar uit de mouw wordt geschud in een onbewaakt moment. Voor minder ervaren gebruikers is dit onderscheid minder duidelijk. Als je hier code plaatst moet je deze ook kunnen onderbouwen.

@FangorN
Wie zijn code live gaat debuggen is ook niet bepaald slim bezig, bij mij draait een kopie altijd op een development omgeving. Ga live niet zomaar code outputten omdat 'iets' even niet werkt zoals het verwacht wordt..

En als het écht moet, gooi er dan even een ip-whitlelist op met jouw IP.

@WMDiensten
Lees nogmaals wat ik zeg/typ. Dit heeft niets te maken met al dan niet "slim bezig zijn". Het gaat erom welke mogelijkheden je tot je beschikking hebt. En als je dan niet anders kunt dan live debuggen kun je er beter voor zorgen dat dit veilig gebeurt inderdaad. Dit is altijd (het) belangrijk(ste). Dat laatste was eigenlijk mijn punt...

Maar prima als je een draai wilt geven aan wat ik zeg, en dat je het daar dan vervolgens niet mee eens bent :p.

@WMDiensten
live code debuggen kan onder bepaalde gevallen wel noodzakelijk zijn. Als je bevoorbeeld een groot project hebt die heel veel instellingen heeft waarbnij een bepaalde koppeling bevoorbeeld niet werkt.
Probeer dat maar eens na te doen.
Bevoorbeeld een koppeling met een plc die aan een machine hangt van een miljoen euro.