The fix is based on the same strategy for handling namespace
declarations as used by getAttributeNode. Note that this strategy makes
these methods not return a DOMAttr for xmlns* attributes, but an
instance of the (undocumented) class DOMNameSpaceNode. This is not
really ideal, but at least this fix makes the behavior of
getAttributeNode and getAttributeNodeNS consistent.
A follow-up action would be to investigate whether DOMNameSpaceNode can
be made into a subclass of DOMAttr (which may be hard due to the way
libxml treats namespace declarations) or document this deviating return
value for xmlns* attributes.
It seems fair to remove this warning, given that:
* it is not documented in the official documentation
* the $specified property, which has a similar 'not implemented' status,
also does not trigger a warning
* it apparently hinders quite a lot of people during debugging, judging by
the number of votes on the bug
This bug was caused by the fact that dom_get_elements_by_tag_name_ns_raw
uses an empty string to filter on the default namespace (as NULL means
'no filter'), whereas in the node itself the default namespace is
signalled by nodep->ns being null.
When we decrement the refcount of a node's document, we state that we
won't need it anymore. Therefore we can *always* set the pointer to the
document to NULL, what avoids invalid memory accesses for some edge cases
as demonstrated with the PHPT.
Original patch provided by Sean Heelan.
According to the W3C DOM Core Level 3 specification DOMElement::nodeValue is
supposed to yield null, but currently the DOM extension yield the result of
calling xmlNodeGetContent(), what is the concatenation of the values of the
children of the element. This patch fixes the non standard behavior.
Assigning to DOMNode::textContent encodes entities, what does not match the
behavior of DOMText::__construct() and DOMDocument::createTextNode. This patch
changes the behavior of DOMNode::textContent in this regard.
This prevented compilation warnings and disclosed few incorrect usages in Zend/zend_vm_def.h and ext/dom/xpath.c.
Now explicit type casting may be required on call site.
This may break some C extension code, but it shoulfn't be a problem to add explicit casting.
