Last modified: 2011-03-13 18:04:57 UTC
wfElement has the following declaration: function wfElement( $element, $attribs = null, $contents = '') Calling it with the following: wfElement( "foo", null, null) ...results in: <foo> ...instead of: <foo/> ...or <foo></foo> Patch is simply the following: Index: GlobalFunctions.php =================================================================== --- GlobalFunctions.php (MediaWiki 1.5.7) +++ GlobalFunctions.php (working copy) @@ -1184,7 +1184,7 @@ } } if( is_null( $contents ) ) { - $out .= '>'; + $out .= '/>'; } else { if( $contents == '' ) { $out .= ' />';
That's by design so you can create open elements with all the bits. However it might be better to split that to the separate wfOpenElement; I've seen several mistakes where normally-string data that may end up being null due to load errors ends up producing bad XML output. Check for usage to see where explicit use of null might be used and needs to be replaced before changing the function behavior.
ah, I see where I missed the documentation for the function. I can imagine my "fix" would break a lot of stuff, not just in the core code but also in any extensions that might rely on this. As sloppy as it might be from an API perspective, it might be better to create a "null safe" version of wfElement, and deprecate wfElement. However, in my case, I'll just RTFM. Don't keep this bug open on my account.
I made a small change with r22083 that would help solve the issue. I have found only one occurrence of Xml::element being called with null content to actually open an element (in HTMLForm.php). We can now probably recode Xml::element() to handle the 'null' content as an empty string and always close the element.
wfElement and everything else in XmlFunctions has been marked as deprecated since December 2008.
