From: boen dot robot at gmail dot com
Operating system: Windows XP SP2
PHP version: 5.2.5
PHP Bug Type: XSLT related
Bug description: Inconsistent parameter validation
Description:
------------
XSLTProcessor::setParameter() seems to be validating if its arguments are
valid in XSLT context, but not always. What I'm even more curious about is
that these warnings never get into the LibXML's error buffer. That is,
libxml_get_errors() returns an empty array when such warnings are to be
displayed (regardless of the libxml_use_internal_errors() value).
To make description of the bug simpler, I'm only altering the $params
array in the sample code below (which I used to isolate the bug(s?)).
Another (minor) part of this issue is that the namespace is never
validated to be an URI (I can live without that one though), regardless of
whether two or three arguments are used.
Reproduce code:
---------------
<?php
ini_set('display_errors', 'On');
$params = array();
libxml_use_internal_errors(true);
$proc = new XSLTProcessor;
$proc->importStylesheet(@DOMDocument::loadXML('<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:param name="test1" />
<xsl:param name="test2" />
<xsl:template match="/">
test1: <xsl:value-of select="$test1"/><br />
test2: <xsl:value-of select="$test2"/><br />
</xsl:template>
</xsl:stylesheet>'));
$proc->setParameter(null, $params);
echo $proc->transformToXML(DOMDocument::loadXML('<a/>'));
print_r(libxml_get_errors());
?>
Expected result:
----------------
$params = array(
'test1'=>'legal value',
'1'=>'invalid parameter name, but a legal value',
'test2'=>'another legal value');
Should create a warning for $params being an invalid parameter array,
ideally pointing explicitly to the "1" parameter, and still apply "test2",
since it's a valid parameter. The warning should be part of the LibXML
error buffer.
$params = array(
'test1'=> new XSLTProcessor,
'test2'=>'legal value');
Should generate a warning in LibXML's error buffer because of the
XSLTProcessor object. This error belongs there, as "normal" arrays can have
objects as their values. The same is applicable for any other object,
though I'm not sure if __toString() has any influence on the outcome with
setParameter(). I believe it should be tried before a warning is reported,
and if it's not available, "test1" should not be populated at all (or
should I say its last successfully applied value should be used during the
transformation).
The same should apply if setParameter() was used with three arguments
instead of two, like
$proc->setParameter(null, 'test1', 'legal value');
$proc->setParameter(null, '1', 'invalid parameter name, but a legal
value');
$proc->setParameter(null, 'test2', 'another legal value');
and
$proc->setParameter(null, 'test1', new XSLTProcessor);
$proc->setParameter(null, 'test2', 'legal value');
respectively.
Actual result:
--------------
$params = array(
'test1'=>'legal value',
'1'=>'invalid parameter name, but a legal value',
'test2'=>'another legal value');
Shows a warning about $params not being a valid parameter array and
doesn't apply any parameter in the array appearing after the first invalid
parameter (in the case above: "test2"). No entry in LibXML's error buffer
is generated.
$params = array(
'test1'=> new XSLTProcessor,
'test2'=>'legal value');
Throws a catchable fatal error appearing on screen, and executes the
transformation, giving "test1" a value of the string "Object", and giving
"test2" its expected "legal value".
When using three arguments instead of two, no warnings ever occur anywhere
for the first case, and
$proc->setParameter(null, 'test1', new XSLTProcessor);
shows "Wrong parameter count" warning, instead of trying to turn the
object into string, and using
$proc->setParameter(null, 'test1',(string) new XSLTProcessor);
shows the same error as when using an array, only it doesn't populate
"test1" with the value "Object".
(I haven't tried it, but I'm guessing resources may have similar issues)
--
Edit bug report at http://bugs.php.net/?id=44269&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44269&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44269&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44269&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44269&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44269&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44269&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=44269&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=44269&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44269&r=support
Expected behavior: http://bugs.php.net/fix.php?id=44269&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44269&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44269&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44269&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44269&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44269&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=44269&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44269&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44269&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44269&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=44269&r=mysqlcfg
