header("Location: uebersicht.php");

[Bernd]

Hallo,

was ich nicht verstehe ist folgendes

if ($stmt = $mysqli->prepare("Update projekte SET 

			anrede=?, 
			vorname=?, 
			nachname=?, 
			email=?

			WHERE Projekt = ?")) {    
				
				$anrede		= $_POST["anrede"];
				$vorname	= $_POST["vorname"];
				$nachname	= $_POST["nachname"];
				$email		= $_POST["email"];

		$stmt->bind_param("sssss",	
				
				$anrede,
				$vorname,
				$nachname,
				$email,
				$code);
		
		$stmt->execute();
		header("Location: uebersicht.php");
		$_SESSION['edit'] = 1;
    $_SESSION['edit_Projekt'] = $pitel;
	}
	else {
			echo $mysqli -> error;
	}

Ich dachte immer wenn ein header gesetzt ist, wird man direkt nach dem Aufruf auf die hinterlegte Seite weitergeleitet, was auch funktioniert, aber wie kann dann noch die $_SESSION erstellt werden? Auf der Zielseite stimmt alles.

Und ja, ich weiß es ist sinnlos die $_POST umzukopieren, ich könnte diese direkt in bind_param einfügen, dieses werde ich als nächstes bereinigen.

[dedlfix]

Tach!

Ich dachte immer wenn ein header gesetzt ist, wird man direkt nach dem Aufruf auf die hinterlegte Seite weitergeleitet,

Wird man nicht. Das setzt nur einen Header. Da passiert kein Script-Abbruch.

dedlfix.

[Bernd]

Hallo,

Wird man nicht. Das setzt nur einen Header. Da passiert kein Script-Abbruch.

ok. Aber an welchem Zeitpunkt werde ich dann auf die Zielseite geleitet?

[dedlfix]

Tach!

Wird man nicht. Das setzt nur einen Header. Da passiert kein Script-Abbruch.

ok. Aber an welchem Zeitpunkt werde ich dann auf die Zielseite geleitet?

Wenn die Response fertig erstellt wurde und am Client angekommen ist.

Eine Umleitung ist nichts weiter als ein bestimmter Statuscode plus Location-Header. Der Browser kann sich auch entscheiden (vor allem, wenn es vom Anwender so konfiguriert ist), dass er der Umleitung nicht folgt. In dem Fall müsste er eigentlich auch die Response rendern. Nur wird man meist keine mitsenden.

dedlfix.

[Rolf B]

Hallo dedlfix,

und bei PHP immer dran denken: Sobald das erste Byte vom Body geschrieben wurde, lässt sich an den Headern nichts mehr tun.

Rolf

[ursus contionabundo]

und bei PHP immer dran denken: Sobald das erste Byte vom Body geschrieben wurde, lässt sich an den Headern nichts mehr tun.

Das "immer" galt in den "guten" alten Zeiten. Seit PHP (wohl) Version 5.6 braucht es jedenfalls für PHP, welches nicht als CLI ausgeführt wird, im folgenden Beispiel das ob_start() nicht mehr:

<?php
#ob_start();
echo "Hallo";
header("Content-Type: text/plain");

(auch header("Location: …")) funktioniert.

Grund

Drupal-User können das output-buffering ("ob") aber abschalten…

[dedlfix]

Tach!

und bei PHP immer dran denken: Sobald das erste Byte vom Body geschrieben wurde, lässt sich an den Headern nichts mehr tun.

Das "immer" galt in den "guten" alten Zeiten. Seit PHP (wohl) Version 5.6 braucht es jedenfalls für PHP, welches nicht als CLI ausgeführt wird, im folgenden Beispiel das ob_start() nicht mehr:

Das stimmt so absolut auch wieder nicht.

Grund

Wenn du aber mal nach oben rollst, siehst du, dass der Default-Wert 0 ist, und damit das Output-Buffering ausgeschaltet ist. Ist das nicht widersprüchlich?

Nun, die Lösung offenbart sich durch einen Blick in die php.ini. Original ausgeliefert werden jedoch nur php.ini-development und php.ini-production. In beiden steht aber:

; Default Value: Off
; Development Value: 4096
; Production Value: 4096
; http://php.net/output-buffering
output_buffering = 4096

Wenn man nun eine von beiden Datei zur php.ini kopiert/umbenennt und sie wirksam im System platziert, bekommt man es mit 4096 Bytes eingeschaltet. Man kann es aber auch selbst ausschalten oder durch eine von Distributionen oder Hosters vorgefertigte php.ini ausgeschaltet bekommen.

Das heißt also, wenn man das System nicht selbst kontrolliert (hat) kann man sich weder darauf verlassen, dass es aktiv ist, noch dass es ausgeschaltet ist. Zudem könnten auch die 4096 oder wie auch immer konfigurierten Bytes bereits in die Ausgabe geschrieben worden sein.

Wenn man die Umgebung nicht kontrollieren kann, sollte man davon ausgehen, dass es deaktiviert ist, und keine Ausgaben erzeugen, bevor man die Header zusammengestellt hat. Damit ist man auf der sicheren Seite, auch wenn es eingeschaltet und noch Platz im Buffer ist.

Drupal-User können das output-buffering ("ob") aber abschalten…

Jeder kann.

dedlfix.

[ursus contionabundo]

und bei PHP immer dran denken: Sobald das erste Byte vom Body geschrieben wurde, lässt sich an den Headern nichts mehr tun.

Das "immer" galt in den "guten" alten Zeiten. Seit PHP (wohl) Version 5.6 braucht es jedenfalls für PHP, welches nicht als CLI ausgeführt wird, im folgenden Beispiel das ob_start() nicht mehr:

Das stimmt so absolut auch wieder nicht.

Doch. Das von mir im Zitat absichtlich betonte "immer" stimmt absolut nicht.

Wenn du aber mal nach oben rollst, siehst du, dass der Default-Wert 0 ist, und damit das Output-Buffering ausgeschaltet ist. Ist das nicht widersprüchlich?

Widersprüchlich ist die Dokumentation bzw. das Verhalten der Entwickler:

In meiner, von mir nicht geänderten Fassung von /etc/php/7.3/apache2/php.ini

; output_buffering
;   Default Value: Off
;   Development Value: 4096
;   Production Value: 4096

und, weiter unten:

; Note: Output buffering can also be controlled via Output Buffering Control
;   functions.
; Possible Values:
;   On = Enabled and buffer is unlimited. (Use with caution)
;   Off = Disabled
;   Integer = Enables the buffer and sets its maximum size in bytes.
; Note: This directive is hardcoded to Off for the CLI SAPI
; Default Value: Off
; Development Value: 4096
; Production Value: 4096
; http://php.net/output-buffering
output_buffering = 4096

Das entspricht z.B. auch dem Originaldownload "php-7.3.3.tar.bz2", darin der "php.ini-production" in den Blöcken ab den Zeilen 126 bzw. 203.

Soll heißen, die Entwickler benutzen den im Programm selbst bestimmten default-value "off" in den mit gelieferten ini-Dateien selbst gerade nicht und überschreiben ihn - übrigens auch in der "php.ini-development".

Das "This directive is hardcoded to Off for the CLI SAPI" hatte ich mit anderen Worten erwähnt.

[TS]

Hello,

und bei PHP immer dran denken: Sobald das erste Byte vom Body geschrieben wurde, lässt sich an den Headern nichts mehr tun.

Das "immer" galt in den "guten" alten Zeiten. Seit PHP (wohl) Version 5.6 braucht es jedenfalls für PHP, welches nicht als CLI ausgeführt wird, im folgenden Beispiel das ob_start() nicht mehr:

Das stimmt so absolut auch wieder nicht.

Doch. Das von mir im Zitat absichtlich betonte "immer" stimmt absolut nicht.

Wenn du aber mal nach oben rollst, siehst du, dass der Default-Wert 0 ist, und damit das Output-Buffering ausgeschaltet ist. Ist das nicht widersprüchlich?

Widersprüchlich ist die Dokumentation bzw. das Verhalten der Entwickler:

In meiner, von mir nicht geänderten Fassung von /etc/php/7.3/apache2/php.ini

; output_buffering
;   Default Value: Off
;   Development Value: 4096
;   Production Value: 4096

und, weiter unten:

; Note: Output buffering can also be controlled via Output Buffering Control
;   functions.
; Possible Values:
;   On = Enabled and buffer is unlimited. (Use with caution)
;   Off = Disabled
;   Integer = Enables the buffer and sets its maximum size in bytes.
; Note: This directive is hardcoded to Off for the CLI SAPI
; Default Value: Off
; Development Value: 4096
; Production Value: 4096
; http://php.net/output-buffering
output_buffering = 4096

Das entspricht z.B. auch dem Originaldownload "php-7.3.3.tar.bz2", darin der "php.ini-production" in den Blöcken ab den Zeilen 126 bzw. 203.

Soll heißen, die Entwickler benutzen den im Programm selbst bestimmten default-value "off" in den mit gelieferten ini-Dateien selbst gerade nicht und überschreiben ihn - übrigens auch in der "php.ini-development".

Das "This directive is hardcoded to Off for the CLI SAPI" hatte ich mit anderen Worten erwähnt.

Und dann sollte man nicht vergessen, dass es nicht 'den einen' Output Buffer gibt, sondern die Dinger auch noch verschachtelt werden.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Und dann sollte man nicht vergessen, dass es nicht 'den einen' Output Buffer gibt, sondern die Dinger auch noch verschachtelt werden.

Das ist eine andere Baustelle, denn dieses von dir hier gemeinte Output-Buffering kann man sich ganz unabhängig von dem in der php.ini konfigurierbaren generellen Output-Buffer einschalten. Wenn man die ob_*()-Funktionen verwendet, dann macht man das üblicherweise bewusst, und bekommt nicht einen per Default gesetzten Buffer vorgesetzt.

dedlfix.

[TS]

Hello,

Und dann sollte man nicht vergessen, dass es nicht 'den einen' Output Buffer gibt, sondern die Dinger auch noch verschachtelt werden.

Das ist eine andere Baustelle, denn dieses von dir hier gemeinte Output-Buffering kann man sich ganz unabhängig von dem in der php.ini konfigurierbaren generellen Output-Buffer einschalten. Wenn man die ob_*()-Funktionen verwendet, dann macht man das üblicherweise bewusst, und bekommt nicht einen per Default gesetzten Buffer vorgesetzt.

Ist das nicht derselbe Bufferstack?

Soweit ich mich erinnere, ist es ein Stapel, aus dem man nicht einfach aus der Mitte (oder von unten) ein Element herauslöschen darf.

Und irgendwann war der dann mal nicht mehr per Default bei Level 0, sondern bei 1. Das führte dann damals zu ganz viel Postings, weil irgendwelche Ticker o. ä nicht mehr funktionierten. Ist aber schon ein paar Jahre/PHP-Versionen her.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Und dann sollte man nicht vergessen, dass es nicht 'den einen' Output Buffer gibt, sondern die Dinger auch noch verschachtelt werden.

Das ist eine andere Baustelle, denn dieses von dir hier gemeinte Output-Buffering kann man sich ganz unabhängig von dem in der php.ini konfigurierbaren generellen Output-Buffer einschalten. Wenn man die ob_*()-Funktionen verwendet, dann macht man das üblicherweise bewusst, und bekommt nicht einen per Default gesetzten Buffer vorgesetzt.

Ist das nicht derselbe Bufferstack?

Ähm ja, anscheinend doch. Mit output_buffering > 0 ergibt ob_get_contents() das, was zuvor ausgegeben wurde. Nur wenn output_buffering auf 0/Off steht, ist es false, also unbenutzt. Halten wir also fest, dass es doch dasselbe ist, und sich mit den vorgeschlagenen php.ini-Dateien wie ein ob_start(null, 4096) verhält.

Soweit ich mich erinnere, ist es ein Stapel, aus dem man nicht einfach aus der Mitte (oder von unten) ein Element herauslöschen darf.

Man kann es auch nicht. Man kann mit ob_end_*()/ob_clean()-Funktionen nur auf den zuletzt geöffneten Buffer einwirken.

Und irgendwann war der dann mal nicht mehr per Default bei Level 0, sondern bei 1. Das führte dann damals zu ganz viel Postings, weil irgendwelche Ticker o. ä nicht mehr funktionierten. Ist aber schon ein paar Jahre/PHP-Versionen her.

Davon ist mir nichts bekannt. Ich sehe da auch grad keine Anwendungsfall vor mir. Dass man das Level mit ob_get_level() abfragen kann, offenbart das Handbuch zwar, aber wozu man das verwenden wollen würde, sehe ich nicht.

dedlfix.

[ursus contionabundo]

aber wozu man das verwenden wollen würde, sehe ich nicht.

Es gäbe da was wozu man es verwenden können könnte:

• Rekursiver Aufruf um durch "Plugins" Platzhalter im Inhalt des Caches zu ersetzen und eventuell neue Platzhalter zu "verbauen" und mit dieser Pluginhudelei erst aufzuhören wenn keine Platzhalter mehr im Cache sind.

Aber verwenden wollen würde ich es auch eher nicht... Macht WP nicht sowas?

[dedlfix]

Tach!

Aber verwenden wollen würde ich es auch eher nicht... Macht WP nicht sowas?

Wenn PHP nicht anbietet, gezielt Outputbuffer zu beenden, die nicht der zuletzt geöffnete sind, kann auch Wordpress eine solche Funktionalität nicht nutzen.

dedlfix.

[ursus contionabundo]

Wenn PHP nicht anbietet, gezielt Outputbuffer zu beenden, die nicht der zuletzt geöffnete sind, kann auch Wordpress eine solche Funktionalität nicht nutzen.

Ich bezog mich auf das von Dir erwähnte Level:

Dass man das Level mit ob_get_level() abfragen kann, offenbart das Handbuch zwar, aber wozu man das verwenden wollen würde, sehe ich nicht.

Das könnte man durchaus abfragen um durch "Ausschütten" vom aktuellen herunter bis zu einem bestimmten Level der Puffer zu gelangen...

[dedlfix]

Tach!

Dass man das Level mit ob_get_level() abfragen kann, offenbart das Handbuch zwar, aber wozu man das verwenden wollen würde, sehe ich nicht.

Das könnte man durchaus abfragen um durch "Ausschütten" vom aktuellen herunter bis zu einem bestimmten Level der Puffer zu gelangen...

Aber wie? Wo kann man die Nummer verwenden? Mit for-Schleife eine bestimmte Anzahl Puffer schließen, die man (spricht die aktuelle Funktion etc.) gar nicht selbst geöffnet hat?

dedlfix.

[ursus contionabundo]

Aber wie? Wo kann man die Nummer verwenden?

Für sowas:

$cacheFile = $_SERVER['DOCUMENT_ROOT'] . '/cache/' . md5( 
  . $_SERVER['SCRIPT_NAME']
  . $_SERVER['QUERY_STRING']
  . serialize( $_POST ) 
  . serialize( $_COOKIES )
  . serialize( $_SESSION )
);

if (! is_file ( $cacheFile ) {
    # Erzeugen der Inhalte
    main(); 
    while ( ob_get_level() > 1 ) {
       ob_flush();
    }
    $cache     = ob_get_clean();
    file_put_contents( $cacheFile, $cache );
    file_put_contents( $cacheFile . '.gz', gzcompress( $cache ) );
    echo $cache;
    exit;
} else {
    # Cache einfach ausgeben:
    echo file_get_contents( $cacheFile );
    exit;
}

main () {
    # Erzeugen der Inhalte
    …
}

→ ausführlicher

[TS]

Hello,

Dass man das Level mit ob_get_level() abfragen kann, offenbart das Handbuch zwar, aber wozu man das verwenden wollen würde, sehe ich nicht.

Das könnte man durchaus abfragen um durch "Ausschütten" vom aktuellen herunter bis zu einem bestimmten Level der Puffer zu gelangen...

Aber wie? Wo kann man die Nummer verwenden? Mit for-Schleife eine bestimmte Anzahl Puffer schließen, die man (spricht die aktuelle Funktion etc.) gar nicht selbst geöffnet hat?

Klar! Im Gegensatz zu verteilter Intelligenz arbeiten viele PHP-Programme doch mit verteiltem Blödsinn.

Glück Auf
Tom vom Berg