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

go to bug id or search bugs for

Bug #74494 DOMDocument::saveXML() LIBXML_NOEMPTYTAG option is ignored
Submitted: 2017-04-24 18:11 UTC Modified: 2017-04-26 07:37 UTC
From: mfburdett at gmail dot com Assigned:
Status: Not a bug Package: DOM XML related
PHP Version: 7.1.4 OS: FreeBSD
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: mfburdett at gmail dot com
New email:
PHP Version: OS:

 

 [2017-04-24 18:11 UTC] mfburdett at gmail dot com 
Description:
------------
When executing a PHP script using the Apache module, the DOMDocument::saveXML() LIBXML_NOEMPTYTAG option is ignored - a self-closing tag, e.g. <body /> is created.

When executing the same script on the commandline, the LIBXML_NOEMPTYTAG option is honored.

This could be a bug in how PHP, Apache and LibXML are compiled by FreeBSD ports, rather than a bug in PHP itself.

Test script:
---------------
<?php
$dom = new \DOMDocument();
$dom->loadHTML('<body></body>');
$node = $dom->getElementsByTagName('body')->item(0);
echo $dom->saveXML($node, LIBXML_NOEMPTYTAG);


Expected result:
----------------
<body></body>

Actual result:
--------------
<body/>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-04-24 19:05 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2017-04-24 19:05 UTC] requinix@php.net 
LIBXML_NOEMPTYTAG only applies to XML documents. Yours is HTML.

Use ->saveHTML().
 [2017-04-25 00:03 UTC] mfburdett at gmail dot com 
I can also reproduce this bug with an XML document:

<?php
$dom = new \DOMDocument();
$dom->loadXML('<root><node/></root>');
$node = $dom->getElementsByTagName('node')->item(0);
echo $dom->saveXML($node, LIBXML_NOEMPTYTAG);

Expected result: <node></node>

Actual result: <node/>
 [2017-04-25 07:25 UTC] requinix@php.net 
Looks fine to me. https://3v4l.org/pOKD9

What libxml do you have?
 [2017-04-25 19:02 UTC] mfburdett at gmail dot com 
phpinfo reports libxml 2.9.4
 [2017-04-25 20:57 UTC] requinix@php.net
-Status: Not a bug +Status: Open
 [2017-04-25 20:57 UTC] requinix@php.net 
I haven't found anything to suggest why yours is working differently. I'm still pretty sure this is not a bug with PHP but I don't know enough to tell you what to test next (besides maybe a build straight from the libxml2 sources without FreeBSD's patches?) so I'll move this back to Open.
 [2017-04-25 22:10 UTC] mfburdett at gmail dot com 
I resolved this issue by purging old libraries in /usr/local/lib/compat/pkg (libraries are automatically moved here when packages are uninstalled) and forcibly recompiling and reinstalling all dependencies: portupgrade -fR textproc/php71-dom www/mod_php71

I didn't try to debug, but perhaps an old version of libxml was used despite PHP reporting libxml 2.9.4?

I think this bug could be closed again since it is resolvable, but hope this report is useful to someone else who runs into this obscure issue...
 [2017-04-26 07:37 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2017-04-26 07:37 UTC] requinix@php.net 
The "libxml Version" reported is what PHP was compiled against, not what it is currently running with. In fact the phpinfo for ext/libxml calls the same value the "libXML Compiled Version".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Oct 25 12:00:01 2025 UTC