---

Hey.. Jeg får fejlen:

Warning: Cannot add header information - headers already sent by (output
started at /var/www

Så vidt jeg kan se er det fordi jeg har en

include 'vars.php';

tidligere i scriptet.. Kan det virkeligt være rigtigt?

Hvordan redirecter man så til en anden side?

Mvh
Michael

---

Ja. Din vars.php fil ender garanteret i nogle spaces eller en tom linie i
stedet for at ende med ?>

Lars.

Michael Andreasen wrote:
> Hey.. Jeg får fejlen:
>
> Warning: Cannot add header information - headers already sent by (output
> started at /var/www
>
> Så vidt jeg kan se er det fordi jeg har en
>
> include 'vars.php';
>
> tidligere i scriptet.. Kan det virkeligt være rigtigt?
>
> Hvordan redirecter man så til en anden side?
>
> Mvh
> Michael

---

"Michael Andreasen" <maskinen2000@hotmail.com> wrote in message
news:auis6u$872$1@sunsite.dk...
> Hey.. Jeg får fejlen:
>
> Warning: Cannot add header information - headers already sent by (output
> started at /var/www
>
> Så vidt jeg kan se er det fordi jeg har en
>
> include 'vars.php';
>
> tidligere i scriptet.. Kan det virkeligt være rigtigt?
>
> Hvordan redirecter man så til en anden side?
Der må ikke have været skrevet noget ud, bare en tom linie er nok til at PHP
har sendt headers. F.eks:
<?
$xo="";
?>
<?
header("xxxx");
?>
Dette er nok.... for mellem disse:
?>
<?
kommer der en tom linie....

---

"Dan Molberg" <beyond@repair.void> wrote in message
news:auiskr$b0p$1@sunsite.dk...
> Dette er nok.... for mellem disse:
> ?>
> <?
> kommer der en tom linie....

ok.. tak til jer begge. jeg går min inkluderet fil igennem igen

Mvh
Michael Andreasen

---

For at slippe uden om det kan du benytte output buffering.

Tilføj i starten af din fil, lige efter <?php
ob_start();
<http://www.php.net/manual/en/function.ob-start.php>

og i slutningen af din fil, lige før ?>
ob_end_flush();
<http://www.php.net/manual/en/function.ob-end-flush.php>

Så er det problem ude af verden

Output control
<http://www.php.net/manual/en/ref.outcontrol.php>


M v H
Ronni
rofe@mailme.dk

---

rofe@mailme.dk wrote in <auj1ob$i9e$1@sunsite.dk>:
> Tilføj i starten af din fil, lige efter <?php
[...]
> Så er det problem ude af verden

Jeg vil lige tilføje, at det fjerne ikke problemet, det er bare gemt. Det er
ikke en pæn løsning, men det virker.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

"Niels Andersen" <niels-usenet@myplace.dk> wrote in message news:RpcP9.15343$Hl6.1774934@news010.worldonline.dk...
> rofe@mailme.dk wrote in <auj1ob$i9e$1@sunsite.dk>:
>
> Jeg vil lige tilføje, at det fjerne ikke problemet, det er bare gemt. Det er
> ikke en pæn løsning, men det virker.
>

Jo det er en pæn løsning (og ja nem - men er der grund til at bruge mere tid end nødvendigt?) - det er jo ikke errors der kommer
frem men warnings..

Output buffering står i manualen ergo det er en brugbar løsning.

Man kan meget vel forestille sig noget kode hvor et forløb er at man er nødt til at ændre header information en eller flere gange
selv om der er output - her er det den eneste måde hvor på man kan klare problemet.

Og specielt når der absolut ikke er nogen forskel på kodens effekt efter man har fjernet evt mellemrum før <? eller fjerner kode
stumper hvor man forsøger at skrive til headeren efter output er påbegyndt, eller om man bruger output buffering, så kan jeg ikke se
andet end at det er den nemmeste løsning.

Det er en funktionalitet der er stillet til rådighed - den er beskrevet som et løsningsforslag i manualen så hvad er problemet?

Det er forkert at skrive at det "ikke er en pæn løsning" - det er en løsning så vel som det at optimere koden er det.

Desuden kan man også bruge buffering til at komprimere data som jo er meget godt i netværk hvor båndbredden måske ikke er så stor
hvor hvor tekst datamængden er det.

Når dette er skrevet så er det også nødvendigt for mig at skrive at output buffering ikke er en pæn løsning hvis man ikke har
forståelse for hvorfor man bruger denne løsning - men det gælder jo al programmering.

MVH
Peter

---

Peter Binderup wrote in <3e0d70dd$0$47424$edfadb0f@dtext01.news.tele.dk>:
>> Jeg vil lige tilføje, at det fjerne ikke problemet, det er bare gemt. Det
>> er ikke en pæn løsning, men det virker.
> Jo det er en pæn løsning

Det er ikke pænt at generere output, der ikke skal bruges. Det kan godt være
at det bare er et par mellemrum, i så fald er det bare koden der ikke er
pæn. Men ofte er det flere kilobytes HTML, som der måske er brugt
adskillige db-queries på at generere.
Det virker nok fint, men det er ikke pænt.

> (og ja nem - men er der grund til at bruge mere
> tid end nødvendigt?)

Det må man jo så selv vurdere.

> - det er jo ikke errors der kommer frem men warnings..

Der skulle ikke komme noget som helst. Hvis der gør det, så er der noget
galt. Om ikke andet, så i hvert fald error reporting level el. lign.

> Output buffering står i manualen ergo det er en brugbar løsning.

Jeg siger ikke, at det ikke er brugbart. Jeg siger bare, at det ikke er
pænt.

Desuden giver dit argument ingen mening. "acos()" står også i manualen, er
det så også en brugbar løsning?

> Man kan meget vel forestille sig noget kode hvor et forløb er at man er
> nødt til at ændre header information en eller flere gange selv om der er
> output - her er det den eneste måde hvor på man kan klare problemet.

Nødt til og nødt til... Hvis tiden eller evnerne er begrænset, så vil jeg
give dig ret.

> Og specielt når der absolut ikke er nogen forskel på kodens effekt efter
> man har fjernet evt mellemrum før <? eller fjerner kode stumper hvor man
> forsøger at skrive til headeren efter output er påbegyndt, eller om man
> bruger output buffering, så kan jeg ikke se andet end at det er den
> nemmeste løsning.

Jeg siger heller ikke noget om, at det ikke er den *nemmeste* løsning.
Selvfølgelig er det da det.

> Det er en funktionalitet der er stillet til rådighed - den er beskrevet
> som et løsningsforslag i manualen så hvad er problemet?

At det ikke er pænt.

> Det er forkert at skrive at det "ikke er en pæn løsning" - det er en
> løsning så vel som det at optimere koden er det.

Jeg synes stadig ikke det er pænt.

> Desuden kan man også bruge buffering til at komprimere data som jo er
> meget godt i netværk hvor båndbredden måske ikke er så stor hvor hvor
> tekst datamængden er det.

Jeg siger heller ikke noget om, at output buffering er en dårlig ting. Jeg
siger bare, at det ikke er pænt, at bruge det på denne måde.

> Når dette er skrevet så er det også nødvendigt for mig at skrive at output
> buffering ikke er en pæn løsning hvis man ikke har forståelse for hvorfor
> man bruger denne løsning - men det gælder jo al programmering.

Det har du ret i. Det kunne jeg også have nævnt.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

"Niels Andersen" <niels-usenet@myplace.dk> wrote in message news:9FeP9.15375$Hl6.1780951@news010.worldonline.dk...
>
> > Når dette er skrevet så er det også nødvendigt for mig at skrive at output
> > buffering ikke er en pæn løsning hvis man ikke har forståelse for hvorfor
> > man bruger denne løsning - men det gælder jo al programmering.
>
> Det har du ret i. Det kunne jeg også have nævnt.
>

Så tror jeg i bund og grund at vi er enige (dog kan jeg god indrømme at jeg er lidt doven - så hvis det driller og hvis jeg ikke
lige føler trang til at optimere for optimeringens skyld så bruger jeg de nemme løsninger).

MVH
Peter

---

hehe....

Det havde jeg faktisk læst før, at det ikke var en "pæn" løsning.
Men jeg kan faktisk ikke se hvad problemet er, man laver vel ikke
noget funktionalitet i form af outputbuffering og tænker "Det her skal
ikke bruges, for det er ikke pænt", så havde man nok aldrig lavet det.

Jeg kan se din pointe i at det er dumt at bruge hvis man generer unødig
HTML inden man eksempelvis re-directer til en anden side, men at
det ikke er pænt, forstår jeg ikke. Jeg vil ikke engang gå så langt som
at kalde det dårlig kodeskik, som det var at smide om sig med goto i
gamle dage, der kunne man snakke om kode der ikke var pænt eller
optimalt!

Jeg giver dig ret i, at der er nogle få huller man kan falde i, ved brug af
outputbuffering, men som Peter også skriver, nogle gange kan man ikke
komme uden om det, og hvorfor også setotalt bort fra en funktionalitet
der mange gange er god nok ?

m v h
Ronni
rofe@mailme.dk

---

rofe@mailme.dk wrote in <3e0dac42$0$181$edfadb0f@dread16.news.tele.dk>:
> Det havde jeg faktisk læst før, at det ikke var en "pæn" løsning.
> Men jeg kan faktisk ikke se hvad problemet er, man laver vel ikke
> noget funktionalitet i form af outputbuffering og tænker "Det her skal
> ikke bruges, for det er ikke pænt", så havde man nok aldrig lavet det.
____

Niels Andersen wrote in <9FeP9.15375$Hl6.1780951@news010.worldonline.dk>:
> Jeg siger heller ikke noget om, at output buffering er en dårlig ting. Jeg
> siger bare, at det ikke er pænt, at bruge det på denne måde.
____


> Jeg kan se din pointe i at det er dumt at bruge hvis man generer unødig
> HTML inden man eksempelvis re-directer til en anden side, men at
> det ikke er pænt, forstår jeg ikke. Jeg vil ikke engang gå så langt som
> at kalde det dårlig kodeskik,

Måske skal der bare mere til, før jeg kalder det "pænt".

> som det var at smide om sig med goto i
> gamle dage, der kunne man snakke om kode der ikke var pænt eller
> optimalt!

Det må da være både pænt og optimalt, når det ikke kan blive bedre. Og det
kunne det ikke dengang.

> Jeg giver dig ret i, at der er nogle få huller man kan falde i, ved brug
> af outputbuffering, men som Peter også skriver, nogle gange kan man ikke
> komme uden om det,

Sidst vi snakkede om det i gruppen, var der flere der påstod at det aldrig
er nødvendigt. Jeg kan ikke huske om jeg dengang var med til at sige det,
eller om jeg bare var enig. Men det blev aldrig modbevist.

> og hvorfor også setotalt bort fra en funktionalitet
> der mange gange er god nok ?

Det siger jo heller ikke noget om at man skal. Jeg siger bare at det ikke er
pænt.


For satan, hvor kunne jeg dog bruge noget af det chokolade de snakkede om i
dk.edb.sikkerhed for kort tid siden...

DET ER IKKE PÆNT! Er der nogen man kan kalde "professionel PHP-udvikler" der
ikke er enig, eller er det kun søndags-nørder der ikke er enig med mig?

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

"Niels Andersen" <niels-usenet@myplace.dk> wrote in message news:bojP9.15662$Hl6.1813820@news010.worldonline.dk...
>
> DET ER IKKE PÆNT! Er der nogen man kan kalde "professionel PHP-udvikler" der
> ikke er enig, eller er det kun søndags-nørder der ikke er enig med mig?
>

http://www.zend.com/zend/art/buffering.php

Her er der en artikel der er skrevet af en de førende PHP udviklere - som jeg læser den så er output buffering faktisk pænt og det
anbefales.

Specielt sætningen: "While this usually doesn't pose any significant problem, sometimes having to 'finalize' the HTTP header, before
emitting any output, can significantly complicate the logic of the script. Output buffering solves this very problem." kan give et
hint til hvorfor output buffering er pænt.

Jeg vil til hver en tid hellere have et pænt overskueligt script end jeg vil have et korrekt men uoverskueligt script - og hvis det
giver bedre forståelse af opbygningen af et script ved at modificere header efter output så er det absolut at foretrække.

Zeev er ikke hvem som helst - han er en af dem der fingerene virkelig dybt nede i php's motor
(http://www.zend.com/comm_person.php?id=12), så mon ikke han kvalificere sig som "professionel PHP-udvikler" - derudover er han en
flink fyr (har snakket med ham ved de to sidste internationale php konferencer i Frankfurt i forbindelse med hans gennemgang af Zend
studio).

Og hvis man enabler output buffering i php.ini er det så heller ikke pænt?

/Peter

---

On Sat, 28 Dec 2002 17:25:17 +0100, "Peter Binderup"
<binderup@hotmail.com> wrote:

>Jeg vil til hver en tid hellere have et pænt overskueligt script end jeg vil have et korrekt men uoverskueligt script - og hvis det
>giver bedre forståelse af opbygningen af et script ved at modificere header efter output så er det absolut at foretrække.

Zeev har et godt argument for output buffering. Men det "hvidvasker"
ikke alle ønsker om at bruge output buffering, bare fordi der kan være
relevante tilfælde :)

I en del tilfælde skyldes "problematikken" med at headers allerede er
sendt, blot almindelig sjusk. For eksempel et return for meget et
sted, output af en warning, etc.

Sammenlign det med at bruge @: det kan forhindre output af en warning,
men det er ikke ensbetydende med at man bør bruge @ for at undgå
warnings; problemet kan være mere underliggende.

Jeg ville i hvert fald foretrække at folk fandt ud af hvad, fejlen
var, i stedet for blot at kaste @ og outputbuffering efter alt, der
brokkede sig. Det giver forhåbentligt om ikke andet en større
bevidsthed om hvordan, ens script virker.

--
- Peter Brodersen

---

"Peter Brodersen" <usenet@ter.dk> wrote in message news:aukl3d$mk2$1@dknews.tiscali.dk...

>
> Jeg ville i hvert fald foretrække at folk fandt ud af hvad, fejlen
> var, i stedet for blot at kaste @ og outputbuffering efter alt, der
> brokkede sig. Det giver forhåbentligt om ikke andet en større
> bevidsthed om hvordan, ens script virker.
>

hvilket også var grunden til at jeg tidligere skrev: "Når dette er skrevet så er det også nødvendigt for mig at skrive at output
buffering ikke er en pæn løsning hvis man ikke har forståelse for hvorfor man bruger denne løsning - men det gælder jo al
programmering."

/Peter

---

Peter Binderup wrote in <3e0dd06e$0$47414$edfadb0f@dtext01.news.tele.dk>:
>> DET ER IKKE PÆNT! Er der nogen man kan kalde "professionel PHP-udvikler"
>> der ikke er enig, eller er det kun søndags-nørder der ikke er enig med
>> mig?
>
> http://www.zend.com/zend/art/buffering.php
>
> Her er der en artikel der er skrevet af en de førende PHP udviklere - som
> jeg læser den så er output buffering faktisk pænt og det anbefales.
>
> Specielt sætningen: "While this usually doesn't pose any significant
> problem, sometimes having to 'finalize' the HTTP header, before emitting
> any output, can significantly complicate the logic of the script. Output
> buffering solves this very problem." kan give et hint til hvorfor output
> buffering er pænt.

Okay, så vi kan altså konkludere, at der findes mindst én, der ved hvad han
snakker om, der har set situationer, hvor han selv synes at løsningen er
"pæn".

Jeg synes dog sætningen groft sagt kan omformuleres til "nogle gange er det
nemmere", og så er vi tilbage til hvad jeg hele tiden har sagt.

Jeg synes også at "overskuelig" er en del af "pæn". Men jeg synes altså
stadig at "pæn" kode ved om der skal redirectes før der genereres indhold.

> Jeg vil til hver en tid hellere have et pænt overskueligt script end jeg
> vil have et korrekt men uoverskueligt script

"Pæn" kode er ikke unødvendigt uoverskueligt. :)

> og hvis det giver bedre
> forståelse af opbygningen af et script ved at modificere header efter
> output så er det absolut at foretrække.

Jeg har dog endnu tilgode at se en situation, hvor man ikke kan klare alle
afgørelser før der genereres output. Undtagelsen er sider hvor man virkelig
ønsker output inden "logikken" er overstået ("Dynamisk HTML"), men i den
situation er http-redirects jo ikke relevante.

Men jeg har da ofte set situationer hvor det er nemt. Både at få det til at
fungere, og få koden til at se overskuelig ud.

> Og hvis man enabler output buffering i php.ini er det så heller ikke pænt?

Det synes jeg ikke. Det fjerner muligheden for at sende output før det er
færdig-genereret (medmindre man fjerner effekten igen et andet sted), og
det næsten opfordrer [1] til at skrive "grim" kode, hvor man nemt kan
generere en hel masse HTML, der ikke skal bruges.

[1] "Opfordre" er nok lige stærkt nok, men det opfordrer da i hvert fald
ikke til det modsatte, som ikke-OB gør.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

rofe@mailme.dk wrote in <3e0dac42$0$181$edfadb0f@dread16.news.tele.dk>:
> Det havde jeg faktisk læst før, at det ikke var en "pæn" løsning.
> Men jeg kan faktisk ikke se hvad problemet er, man laver vel ikke
> noget funktionalitet i form af outputbuffering og tænker "Det her skal
> ikke bruges, for det er ikke pænt", så havde man nok aldrig lavet det.
____

Niels Andersen wrote in <9FeP9.15375$Hl6.1780951@news010.worldonline.dk>:
> Jeg siger heller ikke noget om, at output buffering er en dårlig ting. Jeg
> siger bare, at det ikke er pænt, at bruge det på denne måde.
____


> Jeg kan se din pointe i at det er dumt at bruge hvis man generer unødig
> HTML inden man eksempelvis re-directer til en anden side, men at
> det ikke er pænt, forstår jeg ikke. Jeg vil ikke engang gå så langt som
> at kalde det dårlig kodeskik,

Måske skal der bare mere til, før jeg kalder det "pænt".

> som det var at smide om sig med goto i
> gamle dage, der kunne man snakke om kode der ikke var pænt eller
> optimalt!

Det må da være både pænt og optimalt, når det ikke kan blive bedre. Og det
kunne det ikke dengang.

> Jeg giver dig ret i, at der er nogle få huller man kan falde i, ved brug
> af outputbuffering, men som Peter også skriver, nogle gange kan man ikke
> komme uden om det,

Sidst vi snakkede om det i gruppen, var der flere der påstod at det aldrig
er nødvendigt. Jeg kan ikke huske om jeg dengang var med til at sige det,
eller om jeg bare var enig. Men det blev aldrig modbevist.

> og hvorfor også setotalt bort fra en funktionalitet
> der mange gange er god nok ?

Det siger jo heller ikke noget om at man skal. Jeg siger bare at det ikke er
pænt.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Jeg udvikler php professionelt, og jeg mener klart, at output buffering er
en nødløsning. Nødløsninger er dog lovlige, men ikke pæne.

Når man forespørger et php-script, så er det en stor fordel at php er i
stand til at sende data uden at have udført hele scriptet. Faktisk er det
sådan, at hvis et php script sender data fra en interbase forespørgsel, så
vil man opleve at browseren kan vise data før interbase databasen har styr
over, hvor mange records det i det hele taget drejer sig om... hvis
serveren har et højt load, eller hvis der er mange data, er dette af stor
betydning for en websides performance.

Hvis man har en algoritme, som både leverer data til output, men som også
bruges til at afgøre, om der skal laves en redirection, så er der følgende
muligheder:

1) Put koden i en function() og kald den to gange. Af naturlige årsager er
dette ikke en særlig smuk eller god løsning.
2) Put koden hvor der skal laves output, og gør det med output buffering
muligt at lave en redirect, hvis det findes nødvendigt.
3) Put koden i starten, hvor man kan lave redirects, og gem output i en
variabel, så det kan sendes med en simpel "echo $variabelnavn;" senere.

Jeg plejer at bruge løsning 3), da den giver størst performance og ofte også
pænest kode. Med hensyn til din kommentar om at "nogle gange kan man ikke
komme uden om det", så er jeg dybt uenig. Flyt koden op i toppen og erstat

echo "Test";

med

$output.="Test";

og skriv så følgende forneden, hvor du har brug for output:

echo $output;

That's it. Jeg har omskrevet adskillige php-scripts, som andre har lavet, på
den måde, med bedre performance for brugeren til følge, og selvflg. også
mindre RAM forbrug på serveren, hvilket kan have betydning, hvis serveren
har et meget stort load.

Lars Dybdahl.


rofe@mailme.dk wrote:
> Det havde jeg faktisk læst før, at det ikke var en "pæn" løsning.
> Men jeg kan faktisk ikke se hvad problemet er, man laver vel ikke
> noget funktionalitet i form af outputbuffering og tænker "Det her skal
> ikke bruges, for det er ikke pænt", så havde man nok aldrig lavet det.

--
Dybdahl Engineering
http://dybdahl.dk/

---

Lars Dybdahl wrote in <3e0df97b$0$142$edfadb0f@dread12.news.tele.dk>:
> 3) Put koden i starten, hvor man kan lave redirects, og gem output i en
> variabel, så det kan sendes med en simpel "echo $variabelnavn;" senere.

Eller: Start med kode der finder ud af om der redirectes, og gem evt.
resultater. Hvis der så senere er brug for output, genereres det til den
tid.

Hvis det er en større mængde output, eller der ofres "mange" ressourcer på
at generere det, så er løsningen som Lars skriver det ikke meget bedre end
OB-tricket.

(Det ved han sikkert godt, jeg synes bare det skulle nævnes.)

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Ja - at gemme mellemresultater kan også være en mulighed. Fordelen ved at
gemme output eller mellemresultater, frem for at bruge output buffering, er
modulariteten i det. Hvis man en dag fjerner koden, har man en normal
php-fil med normal performance, i stedet for en php-fil med output
buffering som performer dårligt.

Det vil desuden sjældent være lige så meget der skal gemmes til senere brug,
når man gemmer output i en variabel, som når man laver output buffering.

Lars.

Niels Andersen wrote:
> Eller: Start med kode der finder ud af om der redirectes, og gem evt.
> resultater. Hvis der så senere er brug for output, genereres det til den
> tid.

--
Dybdahl Engineering
http://dybdahl.dk/

---

>og i slutningen af din fil, lige før ?>
>ob_end_flush();
><http://www.php.net/manual/en/function.ob-end-flush.php>

Er det nødvendigt bruge denne - vil den ikke automatisk blive kaldt
når scriptet afsluttet (ligesom i ASP)?