[PHP] Vreemd "headers already sent" probleem

[WingsOfFury]

Ik heb een berichtensite voor 2 gebruikers. De gebruikers hebben verschillende opties. Nu krijg ik bij de ene gebruiker, met de meeste opties, steeds de foutmelding:

code:

Warning: Cannot modify header information - headers already sent by (output started at /home/httpd/vhosts/d3s.nl/httpdocs/kb/site.php:118) in /home/httpd/vhosts/d3s.nl/httpdocs/kb/scripts/acties.php on line 19

Lijn 118 in site.php is:

PHP:

<?php if ($_GET['ma'] == "Gelezen" OR $_GET['ma'] == "Markeren" OR $_GET['ma'] == "Markeren opheffen" OR $_GET['ma'] == "Verbergen" OR $_GET['ma'] == "Weergeven" OR $_GET['ma'] == "Verwijderen") { include ('./scripts/acties.php'); }

En lijn 19 in acties.php is:

code:

header("Location: ./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen"); }

Ik heb al uren op internet gezocht en eigenlijk lijkt overal de oplossing dat er 'ergens' wit regels voor een <?php of achter een ?> staan. Maar bij mij kan ik het probleem verhelpen door alleen maar wat html code weg te halen.
Het hoofdmenu heb ik in een tabel staan:

PHP:

<table width="1240" height="60" border="0" cellspacing="0" cellpadding="0" background="./img_v2/banner.jpg">
  <tr>
    <td width="30%">&nbsp;</td>
    <td align="center" style="color:#525252; padding-left:5px; padding-right:5px;"><a href="?mt=bb&ml=<?php if ($_SESSION['UNAME'] == bart) { echo "toevoegen"; } else if ($_SESSION['UNAME'] == betty) { echo "actief"; } ?>&actie=lezen">Berichtjes Bart</a> <?php echo $bart_ongelezen; ?></td>
    <td align="center" style="color:#525252; padding-left:5px; padding-right:5px;"><a href="?mt=bt&ml=<?php if ($_SESSION['UNAME'] == bart) { echo "actief"; } else if ($_SESSION['UNAME'] == betty) { echo "toevoegen"; } ?>&actie=lezen">Berichtjes Betty</a> <?php echo $betty_ongelezen ?></td>
    <td align="center" style="padding-left:5px; padding-right:5px;"><a href="?mt=bo&ml=<?php if($_SESSION['UNAME'] == bart) { echo"statistieken&refresh=10"; } else if ($_SESSION['UNAME'] == betty) { echo"berichtjes_overig"; } ?>">Berichtjes overig</a></td>
    <td align="center" style="padding-left:5px; padding-right:5px;"><a href="?mt=fo&ml=login">Foto's</a></td>
    <td align="center" style="padding-left:5px; padding-right:5px;"><a href="?mt=vi">Video's</a></td>
    <td width="30%">&nbsp;</td>
  </tr>
</table>

Als ik bij 2 td's alles weghaal wat die td's opmaakt, dus bij bijv de eerste 2 menu items, dan is het probleem weg:

PHP:

<td><a href="?mt=bb&ml=<?php if ($_SESSION['UNAME'] == bart) { echo "toevoegen"; } else if ($_SESSION['UNAME'] == betty) { echo "actief"; } ?>&actie=lezen">Berichtjes Bart</a> <?php echo $bart_ongelezen; ?></td>
<td><a href="?mt=bt&ml=<?php if ($_SESSION['UNAME'] == bart) { echo "actief"; } else if ($_SESSION['UNAME'] == betty) { echo "toevoegen"; } ?>&actie=lezen">Berichtjes Betty</a> <?php echo $betty_ongelezen ?></td>

Of als ik 1 hele td weg haal, zoals:

code:

<td align="center" style="padding-left:5px; padding-right:5px;"><a href="?mt=fo&ml=login">Foto's</a></td>

Dan is het probleem ook opgelost.

Ook kan ik het probleem oplossen door het aantal knoppen in het actie menu te wijzigen. Dit is nu:

PHP:

<form name="berichtjes" method="get" action="./start_v2.php" style="margin:0px;">
<input type="hidden" name="mt" value="<?php echo $mt; ?>">
<input type="hidden" name="ml" value="<?php echo $ml; ?>">

<input type="submit" name="ma" value="Gelezen" class="submit"> |
<input type="submit" name="ma" value="Verbergen" class="submit"> |
<input type="submit" name="ma" value="Markeren" class="submit"> |
<input type="submit" name="ma" value="Markeren opheffen" class="submit"> |
<input type="submit" name="ma" value="Aanpassen" class="submit"> |
<input type="submit" name="ma" value="Verwijderen" class="submit">

En als ik daar 2 willekeurige knoppen weghaal dan werkt het ook! De fout kan dus worden opgelost door simpelweg html code weg te halen.
Echter wordt het probleem niet opgelost als ik in het hoofdmenu de eerste en/of laatste td weghaal.

Omdat het probleem is op te lossen door html code weg te halen lijkt het mij dus dat de fout niet in wit regels voor <?php of achter ?> zit... Is dit een juiste conclusie? Het rare is ook dat het niet werkt bij willekeurige code. Het lijkt bij een X aantal tekens pas te werken, verwijder ik minder dan X dan blijft de foutmelding komen, verwijder ik X of meer dan werkt alles wel.

Wie kan mij hiermee helpen? Of mij op weg helpen door eventueel aan te geven waarop ik kan Googlen ipv alleen maar "headers already sent" of "cannot modify header information"?
Als de rest van het script nodig is hoor ik het wel. Alvast super bedankt!

Edit: Ik heb trouwens ook gezien dat bij sommigen wat tekens voor de <?php worden gezet door hun editor, zoals een omgedraaid vraagteken. Bij mij is dit niet zo, en los daarvan wederom: het weghalen van html code lost het probleem op

[Verwijderd]

Je zou als je zeker weet dat je code goed is, php warnings kunnen uitzetten.

Zie ook http://nl2.php.net/manual...n.php#ini.error-reporting

Hiermee voorkom je dat de boodschap headers already sent, in het vervolg wordt genegeerd (En elke andere foutmelding). Wellicht is dat een oplossing voor je probleem.

[WingsOfFury]

Bedankt voor de snelle reactie op dit tijdstip! Ik vind het alleen geen échte 'oplossing'. Als bij je auto het lampje aangaat dat er een fout in je motor zit en dat je naar de garage moet dan zet je ook niet dat lampje uit. Er zit bij mij ergens een fout in, en die wil ik eruit hebben.

Verwijderd schreef op maandag 17 mei 2010 @ 02:37:
Je zou als je zeker weet dat je code goed is

Ik denk het wel, maar die fout is er niet voor niets, zo nuchter ben ik ook wel. Ik snap alleen echt niet waarom het met 1 menu item minder wel werkt...

[Domokoen]

Als je HTML vóór je <?php zet, dan worden de HTTP headers al verstuurd. Dus, je moet zorgen dat de <?php vóór de HTML staat, en dan de headers doen. Daarna pas de HTML.

[WingsOfFury]

Ik zag de reactie van StevenK in http://gathering.tweakers.net/forum/list_messages/1187440/:

StevenK schreef op zondag 31 december 2006 @ 21:05:
Je doet de include van admin.php *nadat* je al HTML zooi hebt neergegooid.

Je zult toch echt moeten zorgen dat je alle code waarin je een header() doet, komt voor je HTML output.

En ja, tegelijk gaf Domokoen hier de oplossing:

Domokoen schreef op maandag 17 mei 2010 @ 02:49:
Als je HTML vóór je <?php zet, dan worden de HTTP headers al verstuurd. Dus, je moet zorgen dat de <?php vóór de HTML staat, en dan de headers doen. Daarna pas de HTML.

Maar nu blijft mijn vraag: hoe kan het dat de redirect (header) wel werkt op de plek waar hij stond als er een X aantal tekens minder voorstaan?
Of is dat gewoon omdat de browser, of html, of php, of iets anders (iemand een suggestie?) maar een Y aantal tekens kan opslaan/negeren/lezen/... voordat het wordt gezien als output?

Edit: een paar regels onder de plek waar eerst:

PHP:

<?php if ($_GET['ma'] == "Gelezen" OR $_GET['ma'] == "Markeren" OR $_GET['ma'] == "Markeren opheffen" OR $_GET['ma'] == "Verbergen" OR $_GET['ma'] == "Weergeven" OR $_GET['ma'] == "Verwijderen") { include ('./scripts/acties.php'); }

stond, staat trouwens:

PHP:

else if ($_GET['ma'] == "Aanpassen") { include ('./scripts/aanpassen.php'); }
else if ($_GET['ml'] == "toevoegen") { include ('./scripts/toevoegen.php'); }

En in die 2 bestanden werkten de headers weer wel. Het probleem is opgelost, maar ik vraag mij nu nog af waarom het ook was op te lossen door html code weg te halen en waarom die andere headers wel werken, terwijl zij 'onder' degene stonden die niet werkte...

[ Voor 26% gewijzigd door WingsOfFury op 17-05-2010 04:16 ]

[Gomez12]

Tja, blijkbaar heb je ergens output buffering aanstaan tot een bepaalde grootte.

Met output buffering mag je later headers toevoegen, zolang het gebuffered is kan php het zelf wel op de goede plek zetten.
Blijkbaar zit je net tegen de grens van je output buffering aan te werken waardoor die paar tekens het verschil maken...

[NMe]

Verwijderd schreef op maandag 17 mei 2010 @ 02:37:
Je zou als je zeker weet dat je code goed is, php warnings kunnen uitzetten.

Zie ook http://nl2.php.net/manual...n.php#ini.error-reporting

Hiermee voorkom je dat de boodschap headers already sent, in het vervolg wordt genegeerd (En elke andere foutmelding). Wellicht is dat een oplossing voor je probleem.

Jij steekt in het echte leven bij problemen ook je kop in het zand? PHP gooit nooit voor niks errors en warnings en ze zomaar negeren moet je nooit doen.

[Verwijderd]

NMe schreef op maandag 17 mei 2010 @ 08:48:
[...]

Jij steekt in het echte leven bij problemen ook je kop in het zand? PHP gooit nooit voor niks errors en warnings en ze zomaar negeren moet je nooit doen.

Nee je hebt gelijk. Mijn oplossing getuigde van noobheid De oplossing van Domokoen is het juiste.

In worst case had ik gewoon de meldingen uitgezet. Vaak komen die nog wel eens voor als je migreert van PHP4 naar PHP5, en bepaalde functies willen niet of spugen continue foutmeldingen uit.

[Verwijderd]

Zet eens ob_start(); boven aan de pagina

[ Voor 4% gewijzigd door Verwijderd op 17-05-2010 09:13 ]

[nickb90]

en dan bijvoorbeeld het volgende aan het eind om het netjes te houden

PHP:

$output = ob_get_contents();
ob_end_clean();  
echo $output;

[MueR]

Waarom zou je dat aan het einde van je pagina doen? Wanneer je output buffering gebruikt gooit PHP aan het einde vanzelf de buffer leeg naar de output. Op deze manier ben je alleen maar extra geheugen en tijd aan het gebruiken.

[xehbit]

En als je toch naar een andere pagina wilt gaan kan je in plaats dit:

PHP:

header("Location: ./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen");

Dit gaan doen:

PHP:

echo "<script>window.location='./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen';</script>";

[!GN!T!ON]

Dragon707 schreef op maandag 17 mei 2010 @ 11:26:
En als je toch naar een andere pagina wilt gaan kan je in plaats dit:

PHP:

header("Location: ./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen");

Dit gaan doen:

PHP:

echo "<script>window.location='./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen';</script>";

Wat als je geen JS ondersteuning hebt dan? Dat lijkt me geen prettige oplossing (ik kan het natuurlijk altijd mis hebben).

[xehbit]

!GN!T!ON schreef op maandag 17 mei 2010 @ 11:33:
[...]


Wat als je geen JS ondersteuning hebt dan? Dat lijkt me geen prettige oplossing (ik kan het natuurlijk altijd mis hebben).

Ik denk dat ondertussen wel veel browsers JS ondersteunen, Je kan anders ook gebruik maken van <noscript>. Bijv,

PHP:

echo "<noscript><a href='./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen'>Je browser ondersteund geen JavaScript, Klik hier om verder te gaan</a></noscript>";

[Snake]

Dragon707 schreef op maandag 17 mei 2010 @ 11:26:
En als je toch naar een andere pagina wilt gaan kan je in plaats dit:

PHP:

header("Location: ./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen");

Dit gaan doen:

PHP:

echo "<script>window.location='./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen';</script>";

Oh mijn god. Als je auto het niet doet ga je 'm toch niet duwen om toch ter plekke te geraken.

Feit is: TS stuurt ergens output naar de browser zonder dat hij het weet. Laten we naar een oplossing zoeken zonder dit soort kunstgrepen toe te passen.

Je include acties.php. Wat zit daar in? Geen whitespace bovenaan ofzo?

[ Voor 5% gewijzigd door Snake op 17-05-2010 11:44 ]

[SinergyX]

Begint je acties.php toevallig ook niet met <?php, dat gaat mischien dubbel op.

[NMe]

Dragon707 schreef op maandag 17 mei 2010 @ 11:26:
En als je toch naar een andere pagina wilt gaan kan je in plaats dit:

PHP:

header("Location: ./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen");

Dit gaan doen:

PHP:

echo "<script>window.location='./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen';</script>";

Welkom terug in 1999.

[Voutloos]

Dragon707 schreef op maandag 17 mei 2010 @ 11:26:
En als je toch naar een andere pagina wilt gaan kan je in plaats dit:

PHP:

header("Location: ./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen");

Dit gaan doen:

PHP:

echo "<script>window.location='./site.php?mt=".$_GET['mt']."&ml=actief&actie=lezen';</script>";

Waarom zou je in hemelsnaam de goede manier van redirecten vervangen door de slechte?

Waar de output begonnen is is wel duidelijk en inmiddels al genoemd. Sterker nog, deze foutmelding noemt _altijd_ de plek waar de output begonnen is en is een van de meeste triviale en trivaal te debuggen PHP errors.

[.oisyn]

En toen las je de rest van de post en snapte je zelf ook niet meer waarom hij die errors krijgt... Of eigenlijk, waarom die weggaan na het verwijderen van wat HTML.

.edit: ik vermoed eerlijk gezegd dat er een soort van output buffering gebruikt wordt, en dat je net tegen de limiet van die buffer aanzit. Zolang je onder de limiet blijft heeft PHP nog niets daadwerkelijk verstuurd, en kun je dus alsnog de header() zetten. Sowieso is hierop vertrouwen nogal bad practice, je wilt gewoon dat je een header() per definitie vóór alle overige output stuurt. En dus geen HTML gaan zitten genereren om er later achter te komen dat je een redirect moet gaan doen.

[ Voor 85% gewijzigd door .oisyn op 17-05-2010 12:10 ]

[WingsOfFury]

SinergyX schreef op maandag 17 mei 2010 @ 11:49:
Begint je acties.php toevallig ook niet met <?php, dat gaat mischien dubbel op.

Klopt, die begint ook met <?php, wat inderdaad niet nodig zou zijn. Alleen voor de duidelijkheid (kleuren in DW) is het wel zo handig. Of is dit écht not done in de programmeerwereld?

Snake schreef op maandag 17 mei 2010 @ 11:42:
Je include acties.php. Wat zit daar in? Geen whitespace bovenaan ofzo?

Die zitten er wel. Het weghalen ervan loste het probleem niet op. Nu include ik acties.php vóór de <html> en werkt het wel... met de wit regels voor <?php in acties.php Volgens mij mogen die wit regels alleen niet voor de allereerste <?php en de allerlaatste ?> in je document, klopt dat?

Gomez12 schreef op maandag 17 mei 2010 @ 07:12:
Tja, blijkbaar heb je ergens output buffering aanstaan tot een bepaalde grootte.

Met output buffering mag je later headers toevoegen, zolang het gebuffered is kan php het zelf wel op de goede plek zetten.
Blijkbaar zit je net tegen de grens van je output buffering aan te werken waardoor die paar tekens het verschil maken...

Ik heb dit zelf nergens in mijn codering staan, dus hat zal een instelling bij de host zijn. Is het normaal dat ze zoiets instellen om het voor de minder ervaren php-ers wat makkelijker te maken? Of duidt dit juist op een slecht opgezette server?

Verwijderd schreef op maandag 17 mei 2010 @ 09:12:
Zet eens ob_start(); boven aan de pagina

Die suggestie ben ik uiteraard ook overal op internet tegen gekomen, maar ook dit vind ik meer 'het probleem omzeilen' dan het probleem oplossen.

.oisyn schreef op maandag 17 mei 2010 @ 12:06:
En toen las je de rest van de post en snapte je zelf ook niet meer waarom hij die errors krijgt... Of eigenlijk, waarom die weggaan na het verwijderen van wat HTML.

.edit: ik vermoed eerlijk gezegd dat er een soort van output buffering gebruikt wordt, en dat je net tegen de limiet van die buffer aanzit. Zolang je onder de limiet blijft heeft PHP nog niets daadwerkelijk verstuurd, en kun je dus alsnog de header() zetten. Sowieso is hierop vertrouwen nogal bad practice, je wilt gewoon dat je een header() per definitie vóór alle overige output stuurt. En dus geen HTML gaan zitten genereren om er later achter te komen dat je een redirect moet gaan doen.

De rest van de post heb je niet gelezen he? Zie onderstaand bericht:

Gomez12 schreef op maandag 17 mei 2010 @ 07:12:
Tja, blijkbaar heb je ergens output buffering aanstaan tot een bepaalde grootte.

Met output buffering mag je later headers toevoegen, zolang het gebuffered is kan php het zelf wel op de goede plek zetten.
Blijkbaar zit je net tegen de grens van je output buffering aan te werken waardoor die paar tekens het verschil maken...

Maar je geeft er wel wat meer informatie bij, .oisyn, en de tip om er nooit op te vertrouwen. Dus ik ga sowieso altijd de headers boven mijn <html> laten uitkomen in het vervolg. Ook voor jou de vraag: zal de host dit ingesteld hebben, en is dat normaal voor een host om te doen?

[SinergyX]

WingsOfFury schreef op maandag 17 mei 2010 @ 12:27:
Klopt, die begint ook met <?php, wat inderdaad niet nodig zou zijn. Alleen voor de duidelijkheid (kleuren in DW) is het wel zo handig. Of is dit écht not done in de programmeerwereld?

Weet ik niet of het not done is, maar dat was tijd terug bij mij dus het probleem. Als je een <?php hebt, daarin een include doe met nogmaals een <?php, wordt die afaik geparsed en krijg je dus een 'header already sent'. (als include een location: heeft). Maar mijn php wordt wat grijs, dus mogelijk zit ik er naast.

Zou zeggen, gooi die eens weg en test eens?

[ Voor 7% gewijzigd door SinergyX op 17-05-2010 12:30 ]

[.oisyn]

SinergyX schreef op maandag 17 mei 2010 @ 12:29:
[...]

Weet ik niet of het not done is, maar dat was tijd terug bij mij dus het probleem. Als je een <?php hebt, daarin een include doe met nogmaals een <?php, wordt die afaik geparsed en krijg je dus een 'header already sent'

Wat is dat nou voor onzin . Een header includen betekent gewoon dat PHP tijdelijk even een andere file gaat parsen voor hij verder gaat met de huidige. En dus moet ook die file weer gewoon een open tag gebruiken, omdat de inhoud anders als output behandeld wordt. Een HTML file includen mag dus ook gewoon.

WingsOfFury schreef op maandag 17 mei 2010 @ 12:27:
De rest van de post heb je niet gelezen he? Zie onderstaand bericht:

Ik zei idd "post", niet "topic"

[ Voor 14% gewijzigd door .oisyn op 17-05-2010 12:42 ]

[NMe]

.oisyn schreef op maandag 17 mei 2010 @ 12:38:
[...]

Wat is dat nou voor onzin . Een header includen betekent gewoon dat PHP tijdelijk even een andere file gaat parsen voor hij verder gaat met de huidige. En dus moet ook die file weer gewoon een open tag gebruiken, omdat de inhoud anders als output behandeld wordt. Een HTML file includen mag dus ook gewoon.

Sterker nog, PHP-templates zonder aparte templating-engine vertrouwen daarop.

[YopY]

SinergyX schreef op maandag 17 mei 2010 @ 12:29:
Weet ik niet of het not done is, maar dat was tijd terug bij mij dus het probleem. Als je een <?php hebt, daarin een include doe met nogmaals een <?php, wordt die afaik geparsed en krijg je dus een 'header already sent'. (als include een location: heeft). Maar mijn php wordt wat grijs, dus mogelijk zit ik er naast.

Volgens mij zit je ernaast. <?php zegt niks anders als 'het volgende stukkie is PHP', en dat moet je voor elk PHP script doen, geinclude of niet. Je krijgt wel die foutmelding als er een spatie of tab of wat voor whitespace dan ook voor die <?php staat.

[SinergyX]

.oisyn schreef op maandag 17 mei 2010 @ 12:38:
Wat is dat nou voor onzin . Een header includen betekent gewoon dat PHP tijdelijk even een andere file gaat parsen voor hij verder gaat met de huidige. En dus moet ook die file weer gewoon een open tag gebruiken, omdat de inhoud anders als output behandeld wordt. Een HTML file includen mag dus ook gewoon.

Mag je het meteen afschepen als 'onzin', ik geef toch aan dat mijn php kennis erg grijs is geworden?

YopY schreef op maandag 17 mei 2010 @ 12:44:
Volgens mij zit je ernaast. <?php zegt niks anders als 'het volgende stukkie is PHP', en dat moet je voor elk PHP script doen, geinclude of niet. Je krijgt wel die foutmelding als er een spatie of tab of wat voor whitespace dan ook voor die <?php staat.

Dan zal dat ongetwijfeld mijn probleem zijn geweest

[Verwijderd]

Hoe dan ook blijft dat er output gegenereerd wordt alvorens de header() wordt uitgevoerd. De enige opties die je hebt lijken me:
- Je PHP herschrijven zodat header() eerder wordt uitgevoerd (voor welke output dan ook).
- Zoeken waar per ongeluk output gegenereerd wordt en die weghalen (maar dat lukte dus niet)
- Output buffering gebruiken (ob_start()) zodat output in een buffer komt en de header() eerder kan outputten.

[.oisyn]

SinergyX schreef op maandag 17 mei 2010 @ 12:55:
[...]

Mag je het meteen afschepen als 'onzin', ik geef toch aan dat mijn php kennis erg grijs is geworden?

En ik geef aan dat wat je zei onzin was. Wat is je punt nou precies? . 't Was verder geen waardeoordeel van jou als persoon oid.

[ Voor 11% gewijzigd door .oisyn op 17-05-2010 13:12 ]

[doeternietoe]

Nog een kleine aanvullende tip die helpt om te voorkomen dat je output krijgt op het moment dat je dat nog niet wilt: sluit je PHP nooit af. Het is verplicht om je php-document te beginnen met een '<?php'. De '?>' aan het einde mag je echter ten alle tijden weglaten. Problematische spaties, witregels of andere karakters zitten altijd voor de '<?php' en na de '?>'. Als je de laatste weglaat, heb je al de helft van het aantal mogelijkheden op een fout geëlimineerd.

Kijk daarnaast uit dat je UTF-documenten geen BOM gebruiken. Php kan daar niet goed mee omgaan en leest de eerste byte van het document dan als een karakter dat naar de browser wordt gestuurd.

[_eXistenZ_]

Sowieso geen outputbuffering gebruiken of het eindhaakje weglaten, dat zijn gewoon slordige tricks om een symptoom te bestrijden als je lui bent.

Wat je kan doen is een templating engine zoals Smarty pakken, en dan je logica scheiden van je output, probleem opgelost. Dat je applicatie 300% beter onderhoudbaar wordt is gelijk mooi meegenomen.

[doeternietoe]

_eXistenZ_ schreef op maandag 17 mei 2010 @ 19:50:
Sowieso geen outputbuffering gebruiken of het eindhaakje weglaten, dat zijn gewoon slordige tricks om een symptoom te bestrijden als je lui bent.

Het eindhaakje weglaten is zeker geen slordige trick, maar een gewoonte die fouten voorkomt. En passant, de ontwikkelaars van Zend(de belangrijkste organisatie achter PHP) zijn het met me eens:

quote: http://framework.zend.com...p-file-formatting.general

For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it´ prevents the accidental injection of trailing white space into the response.

En vindt je Smarty gebruik aanraden voor dit probleem niet een beetje aan het probleem voorbijschieten? Ik ontken niet dat Smarty handig kan zijn, maar in principe kan je opmaak en logica ook prima scheiden zonder Smarty. Ik kan de TS slechts aanraden om het lijstje van RoadRunner84 boven mij af te lopen.

[Gomez12]

doeternietoe schreef op maandag 17 mei 2010 @ 19:59:
[...]

Het eindhaakje weglaten is zeker geen slordige trick, maar een gewoonte die fouten voorkomt.

Voorkomt het fouten of verdoezelt het ze?

De unintended white-space zit er nog steeds.

En bij de grotere projecten is het ondertussen redelijk standaard geworden enkel omdat je anders heel erg snel heel erg hard op je bek gaat met tig includes in includes waarvan je een groot gedeelte niet in eigen beheer hebt...
Maar wmb is het bij kleinere projecten duidelijker en overzichtelijker om gewoon keurig alles af te sluiten wat je opent.

In het voorbeeld van de TS toont het wmb mooi aan dat hij nog eens goed naar de serversettings moet gaan kijken.

[pieturp]

@Gomez et al:

Ik zou die closing tags altijd weglaten: Je script is klaar, er hoeft niet meer "terug" naar HTML gegaan te worden, je voorkomt onnodige whitespace in de HTML. Fouten als "per ongeluk toch HTML binnen PHP" voorkom je doordat PHP gaat miepen. Fouten als "per ongeluk toch PHP in HTML" (theoretisch veiligheidsrisico) voorkom je ermee.
Last but not least: it saves a few byes en je hoeft minder te kloppen

[doeternietoe]

Gomez12 schreef op maandag 17 mei 2010 @ 20:19:
[...]

Voorkomt het fouten of verdoezelt het ze?

De unintended white-space zit er nog steeds.

Nee, die zit er niet. Hoe kun je nu een fout verdoezelen die er niet is?

Je hebt het hier over fouten. Als ik nu na mijn laatste regel PHP een stuk of honderd niet-functionele spaces en newlines zet, dan is dat misschien heel vreemd en onnodig, maar het is niet fout. Die PHP doet dan precies wat ik wil. Pas als ik al die spaces na de '?>' zet, gaat het fouten opleveren. Heb je geen '?>', dan is het simpelweg niet mogelijk om op deze manier fouten te genereren.

[Gomez12]

doeternietoe schreef op maandag 17 mei 2010 @ 21:26:
[...]

Nee, die zit er niet. Hoe kun je nu een fout verdoezelen die er niet is?

Je hebt het hier over fouten. Als ik nu na mijn laatste regel PHP een stuk of honderd niet-functionele spaces en newlines zet, dan is dat misschien heel vreemd en onnodig, maar het is niet fout. Die PHP doet dan precies wat ik wil. Pas als ik al die spaces na de '?>' zet, gaat het fouten opleveren. Heb je geen '?>', dan is het simpelweg niet mogelijk om op deze manier fouten te genereren.

Na de ?> levert het nog steeds geen fouten op, ervanuit gaande dat je intentioneel en bewust het hebt neergezet.

Mits correct neergezet levert het voor of na de ?> geen fouten op ( enkel wat whitespace in je html ). Het gaat enkel fout worden als je het foutief hebt neergezet

En foutief neerzetten wordt (imho) afgestraft als je het afsluit met ?> en verdoezelt als je het niet afsluit.

pieturp schreef op maandag 17 mei 2010 @ 21:19:
@Gomez et al:

Ik zou die closing tags altijd weglaten: Je script is klaar, er hoeft niet meer "terug" naar HTML gegaan te worden, je voorkomt onnodige whitespace in de HTML. Fouten als "per ongeluk toch HTML binnen PHP" voorkom je doordat PHP gaat miepen. Fouten als "per ongeluk toch PHP in HTML" (theoretisch veiligheidsrisico) voorkom je ermee.
Last but not least: it saves a few byes en je hoeft minder te kloppen

Tja, wmb als je script klaar is kun je het afsluiten. Het niet afsluiten geeft wmb aan dat het nog niet klaar is, er kan na 500 regels whitespace nog steeds iets komen.

Whitespace in de html moet je wmb niet zo oplossen, dit is mierenneuken in de marge. Gooi er dan een extra filter oid overheen wat simpelweg alle overbodige whitespaces verwijdert ( dus ook je indenting etc ), dat filter kan je dan tenminste ook weer uitzetten.
HTML binnen PHP is wmb gewoon een totaal ander probleem, je scheidt je data en je code dan niet goed genoeg...
PHP in html is geen probleem als je gewoon normaal je app test...

Maar laat ik het eens andersom vragen, zit iedereen hier gewoon een beetje random op de spatiebalk / enter te drukken tijdens het coden ofzo?
Ik loop er namelijk in eigen code bijna niet tegenaan ( in ieder geval niet vaker dan willekeurige elke andere bug die ikzelf veroorzaak ). En als ik ertegenaan loop, dan heb ik behoorlijke error info en een normale editor waardoor het binnen 2 sec opgelost is...

Voor mij is het gewoon net zo'n automatisme als een if then else / functie / classe constructie correct afsluiten. Of een html tag altijd meesturen en aan het einde een /html tag

Ik vind het een handig iets voor samenwerkingsprojecten, dan wordt je niet zo erg gestoord door een mede-progger die net een foutje maakt. Maar in projecten waar ik de regie heb, daar heb je gewoon geen overbodige whitespaces neer te zetten.

What's next, een if constructie beginnen in het ene bestand en de else in het andere bestand en dan eindigen in een 3e bestand

[NMe]

Gomez12 schreef op maandag 17 mei 2010 @ 21:57:
[...]

Na de ?> levert het nog steeds geen fouten op, ervanuit gaande dat je intentioneel en bewust het hebt neergezet.

Mits correct neergezet levert het voor of na de ?> geen fouten op ( enkel wat whitespace in je html ). Het gaat enkel fout worden als je het foutief hebt neergezet

En foutief neerzetten wordt (imho) afgestraft als je het afsluit met ?> en verdoezelt als je het niet afsluit.

Als jij whitespace onderaan je file hebt staan (doen sommige editors uit zichzelf) dan kan dat best vervelend zijn. Zie deze constructie:

PHP:

include "bestand.php";
header("Location: bestand2.php");

PHP:

<?php
//code hier
?>

.

Lees die punt op de laatste regel even niet, blijkbaar trimt onze code parser de code eerst voordat hij begint met parsen.

Als je de ?> gewoon weglaat zul je niet ergens diep in je includestructuur een bug introduceren die je lastig terug gaat vinden. Nou moet ik zeggen dat ik zelf ook gewoon de ?> schrijf omdat ik het netter vind maar er is zeker wat te zeggen voor het weglaten. Het heeft verder ook geen enkel performancenadeel en volgens mij wordt het zelfs door de developers achter PHP aangeraden.

[ Voor 11% gewijzigd door NMe op 17-05-2010 23:09 ]

[WingsOfFury]

Ik ben super blij met de extra informatie die gegeven is nadat het probleem al was opgelost, vooral de Smarty tip. Ik ga uitzoeken wat Smarty voor mij kan betekenen en hopelijk zorgt het voor veel nieuwe kennis. Als iemand nog wat "concurrenten" van Smarty kent zou ik die graag horen, zodat ik ze een beetje kan vergelijken en dan kan bepalen welke ik wil gebruiken.

Iedereen heel erg bedankt voor alle tips! En om ook even mijn mening te geven, hier ben ik het absoluut mee eens:

_eXistenZ_ schreef op maandag 17 mei 2010 @ 19:50:
Sowieso geen outputbuffering gebruiken of het eindhaakje weglaten, dat zijn gewoon slordige tricks om een symptoom te bestrijden als je lui bent.

Over dat eindhaakje ben ik nog niet zeker. In mijn geval (simpele websites) ben ik het er wel mee eens en vind ik dat ik het hoor af te sluiten, maar zoals anderen al zeggen: bij grote projecten met meerdere programmeurs is het misschien handig om ?> weg te laten.

doeternietoe schreef op maandag 17 mei 2010 @ 19:59:
En vindt je Smarty gebruik aanraden voor dit probleem niet een beetje aan het probleem voorbijschieten? Ik ontken niet dat Smarty handig kan zijn, maar in principe kan je opmaak en logica ook prima scheiden zonder Smarty.

Volgens mij gaf _eXistenZ_ de tip over Smarty als algemene tip, niet direct voor mijn probleem. Ik ben wel blij dat jij, doeternietoe, bevestigd dat Smarty handig is

[pieturp]

Gomez12 schreef op maandag 17 mei 2010 @ 21:57:
[...]
Ik loop er namelijk in eigen code bijna niet tegenaan

bijna nooit

Ik ook niet, maar waarom zou je 't niet gewoon voorkomen? Ik vind 't ook netter om gedag te zeggen als ik wegga, maar moet ik dat ook tegen PHP zeggen?

[MueR]

NMe schreef op maandag 17 mei 2010 @ 23:06:
Als je de ?> gewoon weglaat zul je niet ergens diep in je includestructuur een bug introduceren die je lastig terug gaat vinden. Nou moet ik zeggen dat ik zelf ook gewoon de ?> schrijf omdat ik het netter vind maar er is zeker wat te zeggen voor het weglaten.

Wat precies de reden is dat ik hem weglaat Zal niet voor het eerst zijn dat er ergens een regel whitespace achterblijft.

Het heeft verder ook geen enkel performancenadeel en volgens mij wordt het zelfs door de developers achter PHP aangeraden.

Correct: Zend Framework Coding Standards

For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it´ prevents the accidental injection of trailing white space into the response.