php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #47530 Importing objects into document fragments creates bogus "default" namespace
Submitted: 2009-02-28 14:48 UTC Modified: 2024-03-09 16:06 UTC
Votes:20
Avg. Score:4.3 ± 1.0
Reproduced:16 of 17 (94.1%)
Same Version:6 (37.5%)
Same OS:5 (31.2%)
From: sgunderson at bigfoot dot com Assigned: nielsdos (profile)
Status: Closed Package: DOM XML related
PHP Version: 5.2.9 OS: Debian
Private report: No CVE-ID: None
View Add Comment Developer Edit
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: sgunderson at bigfoot dot com
New email:
PHP Version: OS:

 

 [2009-02-28 14:48 UTC] sgunderson at bigfoot dot com 
Description:
------------
Hi,

When I import a DOM node via a document fragment, suddenly a "default" namespace comes out of nowhere (and it's really hard to remove, short of making my own cloneNode() simulation stripping it).

IIRC PHP4 got this right (although it had lots of other issues), and all other languages I've tested in (Perl, Python, Ruby) do as well. Note that the code below doesn't strictly need importNode(), but I cannot really do with cloneNode() in the real code (it's vastly simplified).

Note: On the surface, this appears to be the same bug as #46185, but I tested 5.3 CVS (as of 2009-02-28) and it's still there.

Reproduce code:
---------------
<?php

$doc = new DOMDocument;
$doc->loadXML('<html xmlns="something" xmlns:ns="whatever"><element ns:foo="bar" /></html>');
$root = $doc->documentElement;
$elem = $root->firstChild;
$frag = $doc->createDocumentFragment();
$frag->appendChild($doc->importNode($elem));
$root->appendChild($frag);
print $doc->saveXML();

?>

Expected result:
----------------
<?xml version="1.0"?>
<html xmlns="something" xmlns:ns="whatever"><element ns:foo="bar"/></html>


Actual result:
--------------
<?xml version="1.0"?>
<html xmlns="something" xmlns:ns="whatever"><default:element xmlns:default="something" xmlns:ns="whatever" ns:foo="bar"/></html>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-06-20 21:31 UTC] felipe@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: rrichards
 [2011-01-12 08:34 UTC] mplomer at gmx dot de 
This does not only affect DocumentFragments. I had this problem with a simple importNode() when having multiple default namespaces. Here is a simplified XML sample:

Reproduce code:
---------------
<?php

$xml = '<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Test-Text</p>
    </div>
</feed>';

$dom = new DOMDocument();
$dom->loadXML($xml);

$dom2 = new DOMDocument();
$importedNode = $dom2->importNode($dom->documentElement, true);
$dom2->appendChild($importedNode);

echo $dom2->saveXML();

?>

Actual result:
--------------
<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:default="http://www.w3.org/1999/xhtml">
    <default:div xmlns="http://www.w3.org/1999/xhtml">
        <default:p>Test-Text</default:p>
    </default:div>
</feed>
 [2013-12-03 07:45 UTC] mike@php.net
-Status: Assigned +Status: Analyzed
 [2013-12-03 07:45 UTC] mike@php.net 
libxml2 issue.

See also bug #55294
 [2017-10-24 05:14 UTC] kalle@php.net
-Status: Analyzed +Status: Assigned
 [2017-10-24 06:15 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: rrichards +Assigned To:
 [2023-06-15 19:59 UTC] nielsdos@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: nielsdos
 [2023-06-15 19:59 UTC] nielsdos@php.net 
The fix for this bug has been committed.
If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test.
Thank you for the report, and for helping us make PHP better.
 [2024-01-17 18:45 UTC] nielsdos@php.net
-Status: Closed +Status: Re-Opened
 [2024-01-17 18:45 UTC] nielsdos@php.net 
I forgot to re-open this. But long story short: I had to revert this because of BC breaks due to side-effects of this fix.
This will be fixed (together with other namespace bugs) once and for all once https://github.com/php/php-src/pull/13031 gets merged.
 [2024-03-09 16:06 UTC] nielsdos@php.net
-Status: Re-Opened +Status: Closed
 [2024-03-09 16:06 UTC] nielsdos@php.net 
The fix for this bug has been committed.
If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test.
Thank you for the report, and for helping us make PHP better.

This is fixed in the new opt-in spec-compliance mode, which was merged in https://github.com/php/php-src/pull/13031.
For more information about the opt-in mode, please see https://wiki.php.net/rfc/opt_in_dom_spec_compliance.
In short: the behaviour of the old DOM classes are unaffected for backwards-compatibility reasons. There are new DOM classes where your code is correctly handled.
This feature will be available in PHP 8.4.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 09:01:27 2024 UTC