|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #54698 setAttribute
Submitted: 2011-05-10 00:15 UTC Modified: 2011-05-10 10:52 UTC
From: broshizzledizzle at gmail dot com Assigned:
Status: Wont fix Package: DOM XML related
PHP Version: Irrelevant OS: (irrelevant)
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.
Block user comment
Status: Assign to:
Bug Type:
From: broshizzledizzle at gmail dot com
New email:
PHP Version: OS:


 [2011-05-10 00:15 UTC] broshizzledizzle at gmail dot com
It makes more sense for setAttribute() to return the object it was called on 
instead of the attribute that was set.  If I was interested in the attribute, I'd 
have use createAttribute() instead.

Test script:
$dom = new DOMDocument();
$body = $dom->createElement('body');
$dom->appendChild($body->setAttribute('class', 'wrapper'));
echo $dom->saveHTML();

Expected result:
I would expect that it would properly append $body to the $dom.

Actual result:
Warning: DOMNode::appendChild() [domnode.appendchild]: Couldn't append node in 
_FILE_ on _LINE_.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-10 10:17 UTC]
-Status: Open +Status: Wont fix
 [2011-05-10 10:17 UTC]
Given how widely the DOM extension is used, I don't think it would be
a good idea to break backward compatibility now, even in a good cause.

Closing won't fix.
 [2011-05-10 10:35 UTC] broshizzledizzle at gmail dot com
I understood the implication of what I suggested when I posted.  This exact same 
flaw happens in so many methods of the DOM that I always have to look up return 
values to see what actually gets returned, rather than what would be useful.

I'm not looking to get into a fight, but think about what you said: "I don't 
think it would be
a good idea to break backward compatibility now, even in a good cause."  Doesn't 
that grate on your nerves?  You are saying, we won't right the wrong we made in 
the beginning because a lot of people use this extension.  Ever heard of 
investing in your future? I don't think PHP is going to die anytime soon, and if 
we're going to ever improve the DOM in this regard we'll probably never have a 
better time.  It'll just get harder the longer we wait.
 [2011-05-10 10:52 UTC]
I think if we were to fix it, we would make it return void or false on an error 
to comply better with the DOM spec. Changing it from one value that doesn't 
comply with the spec to another one that also doesn't comply doesn't make much 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed May 22 08:01:33 2024 UTC