Skip to content

Conversation

cmb69
Copy link
Member

@cmb69 cmb69 commented Nov 12, 2020

No description provided.

@cmb69 cmb69 added the Bug label Nov 12, 2020
@nikic
Copy link
Member

nikic commented Nov 12, 2020

There is a related test failure.

@cmb69
Copy link
Member Author

cmb69 commented Nov 12, 2020

Yes, we cannot simply reset, because we need to heed the INI setting.

@cmb69 cmb69 marked this pull request as draft November 12, 2020 17:55
@cmb69 cmb69 marked this pull request as ready for review November 13, 2020 10:54
@nikic
Copy link
Member

nikic commented Nov 13, 2020

Might make more sense to implement the clean_output = 1 assignment by actually changing the ini setting? That would also make it automatically revert.

It should also be possible to test this, assuming that run-tests.php is invoked in --repeat 2 mode. (The test would only be actually "useful" on master.)

@cmb69
Copy link
Member Author

cmb69 commented Nov 14, 2020

Might make more sense to implement the clean_output = 1 assignment by actually changing the ini setting?

Good idea, but the situation is more messy than expected. Consider the following script:

<?php
echo "something\n";
ob_start('ob_tidyhandler');
echo "else\n";

Output as is:

something
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
else
</body>
</html>

Output with the suggested change:

something

Warning: ob_start(): Cannot change tidy.clean_output - headers already sent in %s on line %d
else

And consider this script:

<?php
ob_start('ob_tidyhandler');
ob_end_clean();
echo "something\n";

Output as is:

something

Output with the suggested change:

<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
something
</body>
</html>

The current behavior of the first script looks erroneous, but some code might rely on changing the output handler after output has been produced.

The modified behavior of the second script would be wrong, so we had to reset the INI setting (in the output_handler's dtor?).

Maybe it's best to stick with the manual reset on RSHUTDOWN for 7.4, and figure out a clean solution for the "master" branch?

@cmb69
Copy link
Member Author

cmb69 commented Nov 17, 2020

Maybe it's best to stick with the manual reset on RSHUTDOWN for 7.4, and figure out a clean solution for the "master" branch?

@nikic, thoughts?

Copy link
Member

@nikic nikic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

@php-pulls php-pulls closed this in 221345a Nov 22, 2020
@cmb69 cmb69 deleted the cmb/77594 branch November 22, 2020 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants