Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revision&revision=299980
is this intentional? if yes, I think this will become a doc problem.
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
Am 13.11.2011 16:11, schrieb Laruence:
Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revision&revision=299980is this intentional? if yes, I think this will become a doc problem
i think / hope this is an accident
if the ob_functions(9 are replaced in any way this is not a doc-problem
it would be a major BC-break and destroy all my work of the last 10 years
rely on ob_start(), ob_get_contents(), ob_get_clean() and the fact
that multiple ob_start() can work inside another one as example to
include module-files using normal output-functions, buffer the output
and replace a palceholder in a template with the buffer while we are
in another template (site-template, list-templates, item-templates)
All the ob_* tests are still in 5.4 and they all pass, so no, these
functions have not been removed.
Am 13.11.2011 16:11, schrieb Laruence:
Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revision&revision=299980is this intentional? if yes, I think this will become a doc
problemi think / hope this is an accident
if the ob_functions(9 are replaced in any way this is not a
doc-problemit would be a major BC-break and destroy all my work of the last 10
years rely onob_start(),ob_get_contents(),ob_get_clean()and the
fact that multipleob_start()can work inside another one as
example to include module-files using normal output-functions,
buffer the output and replace a palceholder in a template with the
buffer while we are in another template (site-template,
list-templates, item-templates)
Hi:
<?php
var_dump(get_extension_funcs('zlib'));
result:
$ php54 /tmp/1.php
array(24) {
[0]=>
string(10) "readgzfile"
[1]=>
string(8) "gzrewind"
[2]=>
string(7) "gzclose"
[3]=>
string(5) "gzeof"
[4]=>
string(6) "gzgetc"
[5]=>
string(6) "gzgets"
[6]=>
string(7) "gzgetss"
[7]=>
string(6) "gzread"
[8]=>
string(6) "gzopen"
[9]=>
string(10) "gzpassthru"
[10]=>
string(6) "gzseek"
[11]=>
string(6) "gztell"
[12]=>
string(7) "gzwrite"
[13]=>
string(6) "gzputs"
[14]=>
string(6) "gzfile"
[15]=>
string(10) "gzcompress"
[16]=>
string(12) "gzuncompress"
[17]=>
string(9) "gzdeflate"
[18]=>
string(9) "gzinflate"
[19]=>
string(8) "gzencode"
[20]=>
string(8) "gzdecode"
[21]=>
string(11) "zlib_encode"
[22]=>
string(11) "zlib_decode"
[23]=>
string(20) "zlib_get_coding_type"
as we can see, the ob_gzhandler is missed in trunk.
thanks
All the ob_* tests are still in 5.4 and they all pass, so no, these
functions have not been removed.Am 13.11.2011 16:11, schrieb Laruence:
Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revision&revision=299980is this intentional? if yes, I think this will become a doc
problemi think / hope this is an accident
if the ob_functions(9 are replaced in any way this is not a
doc-problemit would be a major BC-break and destroy all my work of the last 10
years rely onob_start(),ob_get_contents(),ob_get_clean()and the
fact that multipleob_start()can work inside another one as
example to include module-files using normal output-functions,
buffer the output and replace a palceholder in a template with the
buffer while we are in another template (site-template,
list-templates, item-templates)--
--
Laruence Xinchen Hui
http://www.laruence.com/
On Sun, Nov 13, 2011 at 4:26 PM, Reindl Harald h.reindl@thelounge.netwrote:
Am 13.11.2011 16:11, schrieb Laruence:
Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revision&revision=299980is this intentional? if yes, I think this will become a doc problem
i think / hope this is an accident
if the ob_functions(9 are replaced in any way this is not a doc-problem
it would be a major BC-break and destroy all my work of the last 10 years
rely onob_start(),ob_get_contents(),ob_get_clean()and the fact
that multipleob_start()can work inside another one as example to
include module-files using normal output-functions, buffer the output
and replace a palceholder in a template with the buffer while we are
in another template (site-template, list-templates, item-templates)
I see these functions present in the current trunk:
ob_functions in current trunk/5.4 branch:
tyrael@chronos:~/checkouts/php-src/trunk$ ./sapi/cli/php -r
'var_dump(get_defined_functions());'|grep 'ob_'
string(8) "ob_start"
string(8) "ob_flush"
string(8) "ob_clean"
string(12) "ob_end_flush"
string(12) "ob_end_clean"
string(12) "ob_get_flush"
string(12) "ob_get_clean"
string(13) "ob_get_length"
string(12) "ob_get_level"
string(13) "ob_get_status"
string(15) "ob_get_contents"
string(17) "ob_implicit_flush"
string(16) "ob_list_handlers"
tyrael@chronos:~/checkouts/php-src/branches/PHP_5_4$ ./sapi/cli/php -r
'var_dump(get_defined_functions());'|grep 'ob_'
string(8) "ob_start"
string(8) "ob_flush"
string(8) "ob_clean"
string(12) "ob_end_flush"
string(12) "ob_end_clean"
string(12) "ob_get_flush"
string(12) "ob_get_clean"
string(13) "ob_get_length"
string(12) "ob_get_level"
string(13) "ob_get_status"
string(15) "ob_get_contents"
string(17) "ob_implicit_flush"
string(16) "ob_list_handlers"
ob functions in 5.3:
tyrael@chronos:~/checkouts/php-src/branches/PHP_5_4$ php -r
'var_dump(get_defined_functions());'|grep 'ob_'
string(12) "ob_gzhandler"
string(16) "ob_iconv_handler"
string(8) "ob_start"
string(8) "ob_flush"
string(8) "ob_clean"
string(12) "ob_end_flush"
string(12) "ob_end_clean"
string(12) "ob_get_flush"
string(12) "ob_get_clean"
string(13) "ob_get_length"
string(12) "ob_get_level"
string(13) "ob_get_status"
string(15) "ob_get_contents"
string(17) "ob_implicit_flush"
string(16) "ob_list_handlers"
as you can see, there is 2 functions gone in 5.4/trunk:
string(12) "ob_gzhandler"
string(16) "ob_iconv_handler"
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Am 13.11.2011 16:47, schrieb Ferenc Kovacs:
as you can see, there is 2 functions gone in 5.4/trunk:
string(12) "ob_gzhandler"
string(16) "ob_iconv_handler"
thank your for confirming that
i only liked to get sure what happens early enough
the two missing are not soo bad but AFAIK also used from many
applications while i personally prerfer mod_deflate
Hi:
my mistake in the word usage, I mean ob_gzhandler missd,,
not ob_*,,
sorry
thanks
Am 13.11.2011 16:11, schrieb Laruence:
Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revision&revision=299980is this intentional? if yes, I think this will become a doc problem
i think / hope this is an accident
if the ob_functions(9 are replaced in any way this is not a doc-problem
it would be a major BC-break and destroy all my work of the last 10 years
rely onob_start(),ob_get_contents(),ob_get_clean()and the fact
that multipleob_start()can work inside another one as example to
include module-files using normal output-functions, buffer the output
and replace a palceholder in a template with the buffer while we are
in another template (site-template, list-templates, item-templates)
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revision&revision=299980
Indeed, I do not see ob_gzhandler in the function list, but no mention
of that in UPGRADING or other docs. As far as I understand, it was
converted from function to alias name, so function does not exist
anymore. Not sure if it was really needed, as the use case for it is now
covered by the alias.
Michael, as the patch committer, could you shed more light on this?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Indeed, I do not see ob_gzhandler in the function list
Personally, I do use ob_gzhandler as a function, so are some some other
projects :
http://www.google.com/codesearch#search/&q=lang:php "ob_gzhandler("
if the function could be reintroduced that would be cool...
Nicolas
Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revision&revision=299980Indeed, I do not see ob_gzhandler in the function list, but no mention
of that in UPGRADING or other docs. As far as I understand, it was
converted from function to alias name, so function does not exist
anymore. Not sure if it was really needed, as the use case for it is now
covered by the alias.Michael, as the patch committer, could you shed more light on this?
Right, the PHP_FUNCTION ob_gzhandler has been removed and an alias
to the internal "zlib output compression" output handler has been
introduced, which is faster, can maintain a stateful context and
is cleanable as long as no output has been passed along.
What did people use ob_gzhandler for directly?
Mike
Hi!
What did people use ob_gzhandler for directly?
Well, apparently they did for some reason, doing custom output handlers
based on it I guess. So the question is - is it possible to still have
this function implemented?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Well, apparently they did for some reason, doing custom output handlers
based on it I guess. So the question is - is it possible to still have
this function implemented?
I'll try to hack up a replacement. It would definitely help if people
could post some exemplar test code to ensure it does what you expect it
to do...
Thanks,
Mike
Without a real ob_gzhandler function, replacing it with an alias as
currently in RC1 : what if someone then creates an ob_gzhandler function in
userland ? would ob_start('ob_gzhandler') use the userland function or
still the alias ? I think this is a second argument to make ob_gzhandler a
real function : least surprise.
Personally, I do use ob_gzhandler directly because it's the easiest way to
do chunked compressed encoding in userland.
This allows me to ask for compression as late as possible, because
registering an ob_start('ob_gzhandler'); may be too early for me. I do want
to choose to enable compression only when the very first byte is about to
be sent over the wire.
Hope it helps
Nicolas
<?php
function my_ob_handler($buffer, $mode)
{
// based on content-type,
// do some $buffer filtering
// and add some header()
if (/* content-type benefits compression based on some userland rules */)
{
$buffer = ob_gzhandler($buffer, $mode); // benefits from gzip
negotiation, chunked compression and related headers
if (PHP_OUTPUT_HANDLER_START & $mode)
{
// play/fix with Vary: header, as sent by ob_gzhandler or before
}
}
return $buffer;
}
Without a real ob_gzhandler function, replacing it with an alias as
currently in RC1 : what if someone then creates an ob_gzhandler function
in userland ? would ob_start('ob_gzhandler') use the userland function
or still the alias ? I think this is a second argument to make
ob_gzhandler a real function : least surprise.
Why make others suffer, just if you want to?
Personally, I do use ob_gzhandler directly because it's the easiest way
to do chunked compressed encoding in userland.This allows me to ask for compression as late as possible, because
registering an ob_start('ob_gzhandler'); may be too early for me. I do
want to choose to enable compression only when the very first byte is
about to be sent over the wire.Hope it helps
Nicolas
<?php
function my_ob_handler($buffer, $mode)
{
// based on content-type,
// do some $buffer filtering // and add someheader()if (/* content-type benefits compression based on some userland rules
*/) {
$buffer = ob_gzhandler($buffer, $mode); // benefits from gzip
negotiation, chunked compression and related headersif (PHP_OUTPUT_HANDLER_START & $mode)
{
// play/fix with Vary: header, as sent by ob_gzhandler or before }
}return $buffer;
}
Looks like a bad hack, but anyway, here's is another hack [1].
It's a patch for ext/zlib, which should make your hack work again...
whoever might find worth the hassle, may commit it... or insist
on me to do so...
Regards,
Mike
Hi,
I don't want anyone to take it personal... But what is the status about
missing ob_gzhandler function (but also ob_tidyhandler and
ob_iconv_handler) ?
I put mike's patch and a comment to help track the BC break /potential
inconsistency :
https://bugs.php.net/bug.php?id=60326
Regards
Nicolas
On Fri, Nov 18, 2011 at 12:46, Nicolas Grekas
nicolas.grekas+php@gmail.comwrote:
Without a real ob_gzhandler function, replacing it with an alias as
currently in RC1 : what if someone then creates an ob_gzhandler function in
userland ? would ob_start('ob_gzhandler') use the userland function or
still the alias ? I think this is a second argument to make ob_gzhandler a
real function : least surprise.Personally, I do use ob_gzhandler directly because it's the easiest way to
do chunked compressed encoding in userland.This allows me to ask for compression as late as possible, because
registering an ob_start('ob_gzhandler'); may be too early for me. I do want
to choose to enable compression only when the very first byte is about to
be sent over the wire.Hope it helps
Nicolas
<?php
function my_ob_handler($buffer, $mode)
{
// based on content-type,
// do some $buffer filtering
// and add someheader()if (/* content-type benefits compression based on some userland rules */)
{
$buffer = ob_gzhandler($buffer, $mode); // benefits from gzip
negotiation, chunked compression and related headersif (PHP_OUTPUT_HANDLER_START & $mode)
{
// play/fix with Vary: header, as sent by ob_gzhandler or before
}
}return $buffer;
}
Hi!
I don't want anyone to take it personal... But what is the status about
missing ob_gzhandler function (but also ob_tidyhandler and
ob_iconv_handler) ?I put mike's patch and a comment to help track the BC break /potential
inconsistency :
Ah, I didn't realize this is patch from Mike. Let me take another look
into it but I think it can be applied unless anyone sees anything wrong
with it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Ah, I didn't realize this is patch from Mike. Let me take another look
into it but I think it can be applied unless anyone sees anything wrong
with it.
Note that despite I wrote the patch, I'm -1 on it, as stated in the
previous message in this thread.
Regards,
Mike
Hi!
Note that despite I wrote the patch, I'm -1 on it, as stated in the
previous message in this thread.
So what you prefer to do instead? I'd like to have ob_gzhandler(), but
if you think it can be done better way, please advise.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Sorry to insist, but taking the same argument in the thread for
REQUEST_TIME :
- x.y.z to x.y+1.z
- (...) - Backward compatibility must be kept
What is the status of this ?
Note that despite I wrote the patch, I'm -1 on it, as stated in the
previous message in this thread.
So what you prefer to do instead? I'd like to have
ob_gzhandler(), but if
you think it can be done better way, please advise.
What is the status of this ?
Looks like it's already been committed.
Regards,
Mike