php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #48918 Proposal to newline after close-tag issue
Submitted: 2009-07-14 14:54 UTC Modified: 2010-11-24 15:26 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: none at of dot your dot biz Assigned:
Status: Wont fix Package: *General Issues
PHP Version: 5.3.0 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: none at of dot your dot biz
New email:
PHP Version: OS:

 

 [2009-07-14 14:54 UTC] none at of dot your dot biz
Description:
------------
I have read the (various) bug reports on this issue and I am aware that the subject has already been discussed to death. Not wanting to "flog a dead horse" further, I have a simple proposal that I haven't seen mentioned anywhere before and wanted to run it past the PHP devs to get their opinion on it.

The proposal is this: the newline following a close tag is still swallowed at the end of a file to avoid the accidental output problem, but that inside the file, where more content follows, the newline is not swallowed.

This would satisfy both camps, wouldn't it? obviously, the "more redthan mine" example above would not occur. And the work-around that prevents a newline at the end of a file (forced by some editors) being output where none were intended, potentially forcing the sending of headers, would remain intact.

I'd love to hear some feedback on this proposal. Obviously, the dev team needs to ensure that scripts written in PHP remain compatible with future versions of PHP wherever possible. But equally, as can be seen by the response from frustrated PHP programmers, this quirky behaviour is inconvenient in a number of situations, including output beautification and the potential error situation mentioned in the "more redthan mine" example above. I was hoping that this proposal might sit somewhere in between the two sides of the argument.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-07-14 14:56 UTC] none at of dot your dot biz
Sorry, i should add that I wrote this in response to bug #47707 but was unable to post, since that bug was closed. The referred to "more redthan mine" example can be found in that bug.
 [2010-11-24 15:26 UTC] jani@php.net
-Status: Open +Status: Wont fix -Package: Feature/Change Request +Package: *General Issues
 [2010-11-24 15:26 UTC] jani@php.net
Changing it would potentially break old stuff. Won't happen.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed May 01 15:01:30 2024 UTC