FAQ
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/

Search Discussions

  • Reindl Harald at Nov 13, 2011 at 3:26 pm

    Am 13.11.2011 16:11, schrieb Laruence:
    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
    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)
  • Rasmus Lerdorf at Nov 13, 2011 at 3:38 pm
    All the ob_* tests are still in 5.4 and they all pass, so no, these
    functions have not been removed.
    On 11/13/2011 07:26 AM, Reindl Harald wrote:


    Am 13.11.2011 16:11, schrieb Laruence:
    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
    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)
  • Laruence at Nov 13, 2011 at 4:03 pm
    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
    On Sun, Nov 13, 2011 at 11:38 PM, Rasmus Lerdorf wrote:
    All the ob_* tests are still in 5.4 and they all pass, so no, these
    functions have not been removed.
    On 11/13/2011 07:26 AM, Reindl Harald wrote:


    Am 13.11.2011 16:11, schrieb Laruence:
    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
    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)

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Ferenc Kovacs at Nov 13, 2011 at 3:48 pm

    On Sun, Nov 13, 2011 at 4:26 PM, Reindl Harald wrote:

    Am 13.11.2011 16:11, schrieb Laruence:
    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
    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)
    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
  • Reindl Harald at Nov 13, 2011 at 3:51 pm

    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
  • Laruence at Nov 13, 2011 at 3:52 pm
    Hi:
    my mistake in the word usage, I mean ob_gzhandler missd,,

    not ob_*,,

    sorry

    thanks
    On Sun, Nov 13, 2011 at 11:26 PM, Reindl Harald wrote:


    Am 13.11.2011 16:11, schrieb Laruence:
    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
    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)


    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Stas Malyshev at Nov 13, 2011 at 8:16 pm

    On 11/13/11 7:11 AM, Laruence wrote:
    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
  • Nicolas Grekas at Nov 14, 2011 at 9:24 am
    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
  • Michael Wallner at Nov 14, 2011 at 10:42 am

    On Sun, 13 Nov 2011 12:16:52 -0800, Stas Malyshev wrote:
    On 11/13/11 7:11 AM, Laruence wrote:
    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?
    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
  • Stas Malyshev at Nov 14, 2011 at 7:59 pm
    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
  • Michael Wallner at Nov 18, 2011 at 9:18 am

    On Mon, 14 Nov 2011 11:59:04 -0800, Stas Malyshev wrote:

    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
  • Nicolas Grekas at Nov 18, 2011 at 11:46 am
    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;
    }
  • Michael Wallner at Nov 18, 2011 at 7:11 pm

    On Fri, 18 Nov 2011 12:46:05 +0100, Nicolas Grekas wrote:

    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 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;
    }
    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

    [1] http://dev.iworks.at/PATCHES/ob_gzhandler.diff.txt
  • Nicolas Grekas at Dec 6, 2011 at 5:01 pm
    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
    wrote:
    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;
    }
  • Stas Malyshev at Dec 6, 2011 at 7:07 pm
    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
    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
  • Michael Wallner at Dec 7, 2011 at 8:31 pm

    On Tue, 06 Dec 2011 11:07:00 -0800, Stas Malyshev wrote:
    https://bugs.php.net/bug.php?id=60326
    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
  • Stas Malyshev at Dec 7, 2011 at 8:38 pm
    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
  • Nicolas Grekas at Dec 30, 2011 at 9:29 am
    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

    ( https://wiki.php.net/rfc/releaseprocess )

    What is the status of this ?

    On Wed, Dec 7, 2011 at 21:38, Stas Malyshev wrote:

    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.
  • Michael Wallner at Dec 30, 2011 at 9:57 am

    On Fri, 30 Dec 2011 10:29:09 +0100, Nicolas Grekas wrote:


    What is the status of this ?
    Looks like it's already been committed.

    Regards,
    Mike

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 13, '11 at 3:11p
activeDec 30, '11 at 9:57a
posts20
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase