XML en php print_r en var_dump geen opmaak

[Verwijderd]

Hoi,

Sinds enkele weken heb ik een raar probleem. Ik heb alles al geprobeerd waarvan ik denk dat ermee te maken kan hebben, maar niets schijnt te werken.

Awel, het probleem:
Als ik via mijn locale wamp server een php opvraag die wat xml genereert via een DOMDocument krijg ik de volgende output:

2010-02-11 15:46:19 +010008041751

en als ik dan in firebug kijk zie ik onder het NET tabje:

headers:
Date Thu, 11 Feb 2010 14:46:16 GMT
Server Apache/2.2.4 (Win32) PHP/5.2.6
X-Powered-By PHP/5.2.6
Content-Length 208
Keep-Alive timeout=5, max=100
Connection Keep-Alive
Content-Type text/xml;charset=utf-8

response:
<?xml version="1.0"?><ZonMaan><vandaag>2010-02-11 15:46:19 +0100</vandaag><zonsopgang><uur>08</uur><minuten>04</minuten></zonsopgang><zonsondergang><uur>17</uur><minuten>51</minuten></zonsondergang></ZonMaan>

Terwijl je normaal zou verwachten dat toch wel enige opmaak te zien moet zijn in de browser. Het is op zich geen punt, want de data wordt wel juist gelezen door de machine, maar het is zo lastig debuggen.


Hetzelfde probleem heb ik ook met de print_r en var_dump functies in PHP. Deze vertonen ook geen opmaak.

Ik dacht dat het lag aan de de Content-type text/xml, maar ook application/xml geeft het zelfde resultaat, daarna dacht ik...misschien de browser, maar FF, Opera, Safari, Chrome en IE tonen het allemaal identiek, zonder opmaak. Dus dacht ik.. Het ligt aan mijn server. Maar ook nadat ik het php bestand op een live server had gezet, kreeg ik nog steeds dezelfde output.

Dan zal het wel aan mijn vista liggen. Dus heb ik het in een VM met een kale winxp geprobeerd. Ook hier hetzelfde gedrag.

Waar Oh Waar kan dit aan liggen?

Iemand hetzelfde al voor gehad?

Ik ben aan het ende van mijn latijn.

[MueR]

Wat voor "opmaak" hebben we het over? print_r en var_dump hebben in ieder geval nooit "opmaak", die dumpen alleen text.

[Verwijderd]

die dumpen inderdaad alleen tekst, maar deze tekst heeft wel een opmaak. Er wordt gebruik gemaakt van inspringende tekst.

var_dump voorbeeld van php_manual:

code:

<?php
$a = array(1, 2, array("a", "b", "c"));
var_dump($a);
?>

var_dump bij mij :

array(3) { [0]=> int(1) [1]=> int(2) [2]=> array(3) { [0]=> string(1) "a" [1]=> string(1) "b" [2]=> string(1) "c" } }

var_dump van php manual:

code:

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  array(3) {
    [0]=>
    string(1) "a"
    [1]=>
    string(1) "b"
    [2]=>
    string(1) "c"
  }
}

[RobIII]

Gooi er een <pre> </pre> om heen of zet de content-type op text/plain.

[disjfa]

PHP:

echo "<pre>";

Of bekijk bron

[krvabo]

Var_dump en print_r gebruiken newlines ipv <br> zodat je ook in CLI normaal kunt debuggen.

Dat je xml niet wordt weergegeven komt omdat firefox / andere browsers het zien als 'html' (tags) (door de < >), maar daar hij ze niet kent geeft ie niets weer.
Mits met het juiste contenttype geserveerd (let wel: je webserver kan een ander contenttype geven dan jij in je phpscript opgeeft) geven browsers het vaak wel weer met een opmaak. Let er dus op dat je contenttype niet verschilt door je webserver.
Klik eens op Tools > Page info (firefox) om te kijken welk contenttype hij heeft.

[Verwijderd]

Kan het zijn dat de webserver het content-type dat ik gebruik niet ondersteund? en dus maar iets verzint?

Ik heb wel artikelen gelezen over \r en \n en dat browsers deze negeren, maar het kan toch niet zo zijn dat ik het enkele weken geleden nog wel had... En dat het ook soms gewoon wel werkt..?

Een site als http://ipinfodb.com/ip_query.php moet dan toch wel gewoon deftige xml weergeven?

Wat ik zo vaag vindt is dat firebug het inspringen wel weergeeft onder de HTML en NET ->response en ->XML tabs.

[Raynman]

krvabo schreef op donderdag 11 februari 2010 @ 20:02:
Mits met het juiste contenttype geserveerd (let wel: je webserver kan een ander contenttype geven dan jij in je phpscript opgeeft) geven browsers het vaak wel weer met een opmaak. Let er dus op dat je contenttype niet verschilt door je webserver.
Klik eens op Tools > Page info (firefox) om te kijken welk contenttype hij heeft.

In TS staat een overzicht van de response headers die Firebug laat zien (+opmerking over reeds geprobeerd alternatief MIME-type), dus dat lijkt me het probleem niet.

Verwijderd schreef op donderdag 11 februari 2010 @ 20:24:
Kan het zijn dat de webserver het content-type dat ik gebruik niet ondersteund? en dus maar iets verzint?

De browser zorgt voor het weergeven; die moet het ondersteunen. (en zie opmerking hierboven)

Ik heb wel artikelen gelezen over \r en \n en dat browsers deze negeren, maar het kan toch niet zo zijn dat ik het enkele weken geleden nog wel had... En dat het ook soms gewoon wel werkt..?

Kun je dit iets verhelderen? Wat (precies) werkte er wel en wat niet en wat is er nu anders? (zie hieronder)

Een site als http://ipinfodb.com/ip_query.php moet dan toch wel gewoon deftige xml weergeven?

Mijn browser (Firefox; het is een xml-pagina, maar de weergave wordt bij de client bepaald) komt dan met dit (+wat er beloofd wordt): "This XML file does not appear to have any style information associated with it. The document tree is shown below." Bedoel je dat die functionaliteit niet (meer) werkt?
Edit: ik activeerde net Firebug op die voorbeeldpagina, en toen zag ik ook alleen nog de tekst (inhoud van tags), niet meer de document tree. Probeer dus eens Firebug te deactiveren (en refresh). Ik weet echter zo niet wat dat met print_r en var_dump te maken heeft.

Wat ik zo vaag vindt is dat firebug het inspringen wel weergeeft onder de HTML en NET ->response en ->XML tabs.

Firebug doet zelf formatting, in elk geval voor HTML, dat is niet hetzelfde als de 'echte' broncode.

[ Voor 4% gewijzigd door Raynman op 11-02-2010 21:10 ]

[Voutloos]

De fout bij het weergeven van een xml doc is inderdaad een bug in firebug. Sluit firebug maar en je ziet het document perfect.

[Verwijderd]

Inderdaad. rechtermuis op firebug icoon en clear activation list did the trick. Maar dat verklaart nog niet waarom het dan ook in andere browsers en VM sessies ook die fout weergaf..

Maar op zich kan het topic dicht..

Dank allen.