|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #79065 DOM classes do not expose properties to Reflection
Submitted: 2020-01-05 02:49 UTC Modified: 2020-04-28 13:27 UTC
Avg. Score:3.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: asmqb7 at gmail dot com Assigned:
Status: Re-Opened Package: DOM XML related
PHP Version: 7.4.1 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
44 - 3 = ?
Subscribe to this entry?

 [2020-01-05 02:49 UTC] asmqb7 at gmail dot com
Known related (may be more):

- Bug 48527 - DOM XML classes do not expose properties to Reflection  (5.2,   2009)
- Bug 65565 - var_dump of DOM objects displays empty objects          (5.4,   2013)
- Bug 77685 - Property reflection fails for DOMElement::$firstChild   (7.3.2, 2019)

I can't access the contents of DOMNodes, DOMElements, DOMDocuments, and potentially other classes in the DOM/XML namespaces and/or other extensions, using either reflection or php_object_vars().

- ReflectionObject->getProperties() returns an empty array

- php_object_vars() returns an empty array

- **Sanity checks involving ReflectionObject->hasProperty() return TRUE, while followup ReflectionObject->getProperty() cause ReflectionException**

As an aside, I'm curious to learn how one might [face the music and] generally check for reflection accessibility issues in other extensions or parts of PHP.

FWIW, I haven't used print_r() or var_dump() in years. My own d() function is 5-7 chars less to type, literalizes its arguments (`d($abc, 1+2);` might show '$abc: "hello world" (11),  1+2: 3'), turns 2D arrays into tables, line-wraps automatically, uses xterm's 256 color palette (which works everywhere) for nicer CLI support, etc. Others likely have even more sophisticated routines they've developed over the years. So I'm very interested to learn how PHP code can introspect itself equivalently (or better than) print_r()/var_dump().

I would be interested to learn about hacks and workarounds for PHP versions prior to whenever this is fixed (TIA) which might let me escape the insanity of parsing `print_r(..., true)`, or burrowing around blindly with FFI (and incidentally it's going to be interesting seeing the effects of access to the Universal Hammerâ„¢ when nothing else is made possible by the language itself...).

Test script:
$dom = new DOMDocument;
$data = '<b>test</b>';
print '$dom: '; print_r($dom);
print 'get_object_vars(): '; print_r(get_object_vars($dom));
$r = new ReflectionObject($dom);
print '$r->getProperties(): '; print_r($r->getProperties());
print '$r->getStaticProperties(): '; print_r($r->getStaticProperties());
print '$r->hasProperty("textContent"): '; var_dump($r->hasProperty("textContent"));
print '$r->getProperty("textContent"): '; var_dump($r->getProperty("textContent"));

Expected result:
Script-parseable results from reflection and possibly(?) php_object_vars() that are appropriately equivalent to the text obtained by print_r()

Actual result:
$dom: DOMDocument Object
    [doctype] => 
    [implementation] => (object value omitted)
    [documentElement] => 
    [actualEncoding] => 
    [encoding] => 
    [xmlEncoding] => 
    [standalone] => 1
    [xmlStandalone] => 1
    [version] => 1.0
    [xmlVersion] => 1.0
    [strictErrorChecking] => 1
    [documentURI] => 
    [config] => 
    [formatOutput] => 
    [validateOnParse] => 
    [resolveExternals] => 
    [preserveWhiteSpace] => 1
    [recover] => 
    [substituteEntities] => 
    [nodeName] => #document
    [nodeValue] => 
    [nodeType] => 9
    [parentNode] => 
    [childNodes] => (object value omitted)
    [firstChild] => 
    [lastChild] => 
    [previousSibling] => 
    [nextSibling] => 
    [attributes] => 
    [ownerDocument] => 
    [namespaceURI] => 
    [prefix] => 
    [localName] => 
    [baseURI] => 
    [textContent] => 
get_object_vars(): Array
$r->getProperties(): Array
$r->getStaticProperties(): Array
$r->hasProperty("textContent"): bool(true)
$r->getProperty("textContent"): PHP Fatal error:  Uncaught ReflectionException: Property textContent does not exist in Standard input code:10
Stack trace:
#0 Standard input code(10): ReflectionClass->getProperty('textContent')
#1 {main}
  thrown in Standard input code on line 10


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2020-04-21 11:33 UTC]
-Summary: Reflection/get_object_vars cannot access contents of DOM{Document,Node,Element} +Summary: DOM classes do not expose properties to Reflection -Status: Open +Status: Verified -Package: *XML functions +Package: DOM XML related -Assigned To: +Assigned To: cmb
 [2020-04-21 11:36 UTC]
The following pull request has been associated:

Patch Name: Fix #79065: DOM classes do not expose properties to Reflection
On GitHub:
 [2020-04-27 08:29 UTC]
Automatic comment on behalf of
Log: Fix #79065: DOM classes do not expose properties to Reflection
 [2020-04-27 08:29 UTC]
-Status: Verified +Status: Closed
 [2020-04-28 13:10 UTC]
Automatic comment on behalf of
Log: Revert &quot;Fix #79065: DOM classes do not expose properties to Reflection&quot;
 [2020-04-28 13:27 UTC]
-Status: Closed +Status: Re-Opened -Type: Bug +Type: Documentation Problem -Assigned To: cmb +Assigned To:
 [2020-04-28 13:27 UTC]
The "fix" was wrong, and has been reverted.  Re-opening and
changing to documentation problem, so it can be documented that
the properties are actually overloaded (ala __get()).
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat May 18 09:01:33 2024 UTC