PHP Doku:: Leert (schickt/sendet) den Ausgabe-Puffer und deaktiviert die Ausgabe-Pufferung - function.ob-end-flush.html

Verlauf / Chronik / History: (1) anzeigen

Sie sind hier:
Doku-StartseitePHP-HandbuchFunktionsreferenzDas Verhalten von PHP beeinflussenAusgabepufferungOutput-Control-Funktionenob_end_flush

Ein Service von Reinhard Neidl - Webprogrammierung.

Output-Control-Funktionen

<<ob_end_clean

ob_flush>>

ob_end_flush

(PHP 4, PHP 5)

ob_end_flush Leert (schickt/sendet) den Ausgabe-Puffer und deaktiviert die Ausgabe-Pufferung

Beschreibung

bool ob_end_flush ( void )

Der Inhalt des Ausgabepuffers (sofern vorhanden) wird abgeschickt und der Ausgabepuffer (aber nur dieser) wird deaktiviert. Falls sie mit dem Puffer-Inhalt weiter arbeiten möchten, müssen sie diesen erst per ob_get_contents() zwischen speichern bevor sie ob_end_flush() aufrufen, da dadurch der Puffer geleert wird.

Hinweis: Diese Funktion ähnelt ob_get_flush(), aber ob_get_flush() lieft den Inhalt des Puffers als String zurück.

Rückgabewerte

Gibt bei Erfolg TRUE zurück. Im Fehlerfall wird FALSE zurückgegeben. Gründe für Fehler sind erstens, dass sie die Funktion ohne einen aktiven Puffer augerufen haben, oder zweitens, dass aus irgendeinem Grund der Puffer nicht gelöscht werden konnte (möglich bei speziellen Puffern).

Fehler/Exceptions

Wenn die Funktion fehlschlägt, generiert sie eine E_NOTICE.

Changelog

Version Beschreibung
4.2.0 Die Funktion gibt nun den Erfolgsstatus als bool zurück.

Beispiele

Beispiel #1 ob_end_clean()-Beispiel

Das folgende Beispiel zeigt einen einfachen Weg, um alle aktiven Ausgabepuffer zu leeren und zu entfernen:

<?php
  
while (@ob_end_flush());
?>

Siehe auch

  • ob_start() - Ausgabepufferung aktivieren
  • ob_get_contents() - Gibt den Inhalt des Ausgabe-Puffers zurück
  • ob_get_flush() - Flush the output buffer, return it as a string and turn off output buffering
  • ob_flush() - Leert (sendet) den Ausgabepuffer
  • ob_end_clean() - Löscht den Ausgabe-Puffer und deaktiviert die Ausgabe-Pufferung


7 BenutzerBeiträge:
- Beiträge aktualisieren...
Mark
24.06.2010 22:49
Wanted to speed things up and put some processing after the page has been delivered to the client. That drove me almost insane, but finally, I found a solution (php 5.2.5):

<?php
ob_start
(); // outer buffer
ob_start(); // inner buffer to catch URL rewrites and other post processing
session_start(); // registers URL rewriter with inner buffer!
echo '...';
// log performance data to log files *after* delivering the page!
register_shutdown_function(array($benchmarkclass,'log_perf_data'));
// now flush output output to client
ob_end_flush();
// need to calculate content length *after* URL rewrite!
header("Content-length: ".ob_get_length());
ob_end_flush();
// now we close the session and do some arbitrary clean-up tasks
// registered using register_shutdown_function()
session_write_close();
?>
unxed
6.03.2010 15:50
Remember that chromium browser (and maybe other webkit-based browsers) have some issues with ob_end_flush.

http://code.google.com/p/chromium/issues/detail?id=31410

You may use
header("Content-Type: text/plain");
to solve those issues if you do not need html.
shanep
22.01.2010 6:31
It appears that ob_end_flush() is very important if you are looping.  For instance if you are using a mass mailer that uses the output buffer for creating HTML content.  Use ob_end_flush() to avoid server errors.
skippy at zuavra dot net
1.07.2005 11:10
Apart from being mostly redundant, ob_end_flush() can be downright damaging in some weird cases.

Actual example: a particular page on an Intranet website which would appear blank on Internet Explorer 6 when ob_start('ob_gzhandler') was called in the beginning and ob_end_flush() at the end.

We couldn't figure out what made that page special no matter what we tried. The ob_ functions were placed in scripts which were include()'d by all pages just the same, but only that page did this.

Even stranger, the problem only appeared on direct browser/server connections. Whenever the connection passed through a proxy the problem dissapeared. I'm guessing some kind of HTTP encoding headers mumbo-jumbo.

Solution: unless you really need it in particular cases, remove the ob_end_flush() call and rely on the builtin, automatic buffer flush.
jhannus at 128kb dot com
5.06.2004 18:18
A note on the above example...

with PHP 4 >= 4.2.0, PHP 5 you can use a combination of ob_get_level() and ob_end_flush() to avoid using the @ (error suppresion) which should probably be a little faaster.

<?php

while (ob_get_level() > 0) {
   
ob_end_flush();
}

?>
kriek at jonkriek dot com
29.03.2003 18:22
ob_end_flush() isn't needed in MOST cases because it is called automatically at the end of script execution by PHP itself when output buffering is turned on either in the php.ini or by calling ob_start().
brett at realestate-school dot com
26.09.2002 22:01
It appears that you can call ob_end_flush() regardless of whether or not output buffering was ever started using ob_start(). This can prove useful because it saves you from having to create conditional statements based on whether a particular function or include file has started output buffering. You can simply call the ob_end_flush() anyway and if there's output in the buffer, it will be sent, otherwise your script will just keep on keepin' on.



PHP Powered Diese Seite bei php.net
The PHP manual text and comments are covered by the Creative Commons Attribution 3.0 License © the PHP Documentation Group - Impressum - mail("TO:Reinhard Neidl",...)