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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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: Thu Apr 18 18:01:28 2024 UTC