#51057 [NEW]: Memory leak(s), 64 bit?
From: daniel dot oconnor at gmail dot com Operating system: Debian 5.0.2 PHP version: 5.3.1 PHP Bug Type: Unknown/Other Function Bug description: Memory leak(s), 64 bit? Description: I'm seeing: [Tue Feb 16 08:05:07 2010] Script: 'tests/AllTests.php' /usr/src/php-5.3.1/Zend/zend_opcode.c(63) : Freeing 0x02090898 (4 bytes), script=tests/AllTests.php and a few of it's friends. The machine is http://wiki.php.net/systems/sg1 - compiled php 5.3.1, Reproduce code: --- clockw...@sg1:~/packages-all/Services_ExchangeRates$ php tests/AllTests.php Expected result: No memory leaks Actual result: -- PHPUnit 3.4.10 by Sebastian Bergmann. .E.EE...E..EEEIIE Time: 0 seconds, Memory: 9.75Mb There were 8 errors: 1) Services_ExchangeRatesTest::testShouldStoreRetrievedData2 Assigning the return value of new by reference is deprecated /usr/local/lib/php/pear/XML/Unserializer.php:801 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Common.php:72 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Common.php:72 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Rates_ECB.php:83 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates.php:189 /home/clockwerx/packages-all/Services_ExchangeRates/tests/Services_ExchangeRatesTest.php:70 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:25 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:49 2) Services_ExchangeRatesTest::testShouldValidateCurrencyCode Non-static method PEAR::raiseError() should not be called statically, assuming $this from incompatible context /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates.php:370 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates.php:272 /home/clockwerx/packages-all/Services_ExchangeRates/tests/Services_ExchangeRatesTest.php:102 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:25 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:49 3) Services_ExchangeRatesTest::testShouldNotConvertInvalidCurrencies Non-static method PEAR::raiseError() should not be called statically, assuming $this from incompatible context /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates.php:370 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates.php:272 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates.php:292 /home/clockwerx/packages-all/Services_ExchangeRates/tests/Services_ExchangeRatesTest.php:112 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:25 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:49 4) Services_ExchangeRatesCommonTest::testShouldParseXML Use of undefined constant XML_UNSERIALIZER_OPTION_ATTRIBUTES_PARSE - assumed 'XML_UNSERIALIZER_OPTION_ATTRIBUTES_PARSE' /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Common.php:77 /home/clockwerx/packages-all/Services_ExchangeRates/tests/Services_ExchangeRatesCommonTest.php:23 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:25 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:49 5) Services_ExchangeRates_CurrenciesUNTest::testShouldParseInformationCorrectly Use of undefined constant XML_UNSERIALIZER_OPTION_ATTRIBUTES_PARSE - assumed 'XML_UNSERIALIZER_OPTION_ATTRIBUTES_PARSE' /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Common.php:77 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Currencies_UN.php:76 /home/clockwerx/packages-all/Services_ExchangeRates/tests/Services_ExchangeRates_CurrenciesUNTest.php:36 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:25 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:49 6) Services_ExchangeRates_RatesECBTest::testShouldRetrieveInformation Use of undefined constant XML_UNSERIALIZER_OPTION_ATTRIBUTES_PARSE - assumed 'XML_UNSERIALIZER_OPTION_ATTRIBUTES_PARSE' /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Common.php:77 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Rates_ECB.php:83 /home/clockwerx/packages-all/Services_ExchangeRates/tests/Services_ExchangeRates_RatesECBTest.php:34 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:25 /home/clockwerx/packages-all/Services_ExchangeRates/tests/AllTests.php:49 7) Services_ExchangeRates_RatesNBPTest::testShouldRetrieveInformation Use of undefined constant XML_UNSERIALIZER_OPTION_ATTRIBUTES_PARSE - assumed 'XML_UNSERIALIZER_OPTION_ATTRIBUTES_PARSE' /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Common.php:77 /home/clockwerx/packages-all/Services_ExchangeRates/Services/ExchangeRates/Rates_NBP.php:106 /home/clockwerx/packages
#46792 [Bgs]: SoapFault detail property missing
ID: 46792
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
Status: Bogus
Bug Type: SOAP related
Operating System: Windows
PHP Version: 5.2.7
Assigned To: dmitry
New Comment:
I still feel it should be defined all of the time, and just set to null
if there's nothing there; like every other object in PHP.
As a normal developer, I shouldn't have to remember that if I want to
check my soapfault detail I have to wrap it in isset(), because this is
one of the few niche bits of PHP which break convention.
This bug exposes two seperate problems - class definition and how that
object is rendered.
My problem is with the class definition/instatiation not fitting with
how every other class I know of behaves.
For your problems, with rendering/encoding soapfault detail needlessly,
why not just check if the property is null or not in the encoding step?
And if its that big of a concern, what about spinning of another ticket
to specifically deal with that?
Previous Comments:
[2009-04-25 16:20:10] j...@php.net
As Dmitry said. Use isset().
[2009-01-11 10:56:45] daniel dot oconnor at gmail dot com
Not having the property defined was surprising, and unexpected - I
would not expect code which reads SoapFault::$detail to ever generate an
E_NOTICE.
[2009-01-11 09:40:03] dmi...@php.net
I don't think we should create empty detail property (and then encode
it and send back to client) if it's not important. Very rare script
looks into fault details. In case your script really needs it, it can
always check it with isset() or empty().
[2008-12-31 17:39:13] fel...@php.net
Hi Dmitry, any objection?
http://felipe.ath.cx/diff/bug46792.diff
[2008-12-08 00:06:24] daniel dot oconnor at gmail dot com
Description:
If you don't supply a detail param in the constructor of SoapFault, the
property doesn't exist.
See also bug #39357
Reproduce code:
---
?php
$sf = new SoapFault(null, null, null, Details!);
var_dump($sf);
$sf = new SoapFault(null, null);
var_dump($sf);
Expected result:
Both objects define a detail property
Actual result:
--
object(SoapFault)#1 (8) {
[message:protected]=
string(0)
[string:private]=
string(0)
[code:protected]=
int(0)
[file:protected]=
string(17) C:\soap_fault.php
[line:protected]=
int(2)
[trace:private]=
array(0) {
}
[faultstring]=
string(0)
[detail]=
string(8) Details!
}
object(SoapFault)#2 (7) {
[message:protected]=
string(0)
[string:private]=
string(0)
[code:protected]=
int(0)
[file:protected]=
string(17) C:\soap_fault.php
[line:protected]=
int(6)
[trace:private]=
array(0) {
}
[faultstring]=
string(0)
}
--
Edit this bug report at http://bugs.php.net/?id=46792edit=1
#47263 [Fbk-Opn]: xmlrpc_set_type() doesn't respect timezone settings
ID: 47263
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
-Status: Feedback
+Status: Open
Bug Type:XMLRPC-EPI related
PHP Version: 5.2.8
New Comment:
Windows: working happily now
C:\php -v
PHP 5.2.9-dev (cli) (built: Feb 2 2009 11:39:58)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
C:\php 147263.php
20060116T19:14:03
1137438843
1137438843
2006-01-16 19:14:03
2006-01-16 19:14:03
C:\
Previous Comments:
[2009-02-02 21:29:38] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-02-01 16:12:37] daniel dot oconnor at gmail dot com
Description:
xmlrpc_set_type() doesn't appear to respect my timezone settings
(alternatively, it should parse everything as GMT/UTC?)
Tested on 5.2.6 5.2.8
Reproduce code:
---
?php
date_default_timezone_set('UTC');
$time = time();
$date = date(Y-m-dTH:i:s, $time) . \n;
$date = 20060116T19:14:03;
$time = strtotime($date);
print $date . \n;
print $time . \n;
$xmlrpc_date = (string)$date;
xmlrpc_set_type($xmlrpc_date, 'datetime');
print $xmlrpc_date-timestamp . \n;;
print date(Y-m-d H:i:s, $time) . \n;
print date(Y-m-d H:i:s, $xmlrpc_date-timestamp);
/* 5.2.6 / ubuntu says:
20060116T19:14:03
1137438843
1137401043
2006-01-16 19:14:03
2006-01-16 08:44:03
*/
Expected result:
20060116T19:14:03
1137438843
1137438843
2006-01-16 19:14:03
2006-01-16 19:14:03
Actual result:
--
20060116T19:14:03
1137438843
1137401043
2006-01-16 19:14:03
2006-01-16 08:44:03
--
Edit this bug report at http://bugs.php.net/?id=47263edit=1
#47263 [NEW]: xmlrpc_set_type() doesn't respect timezone settings
From: daniel dot oconnor at gmail dot com
Operating system:
PHP version: 5.2.8
PHP Bug Type: XMLRPC-EPI related
Bug description: xmlrpc_set_type() doesn't respect timezone settings
Description:
xmlrpc_set_type() doesn't appear to respect my timezone settings
(alternatively, it should parse everything as GMT/UTC?)
Tested on 5.2.6 5.2.8
Reproduce code:
---
?php
date_default_timezone_set('UTC');
$time = time();
$date = date(Y-m-dTH:i:s, $time) . \n;
$date = 20060116T19:14:03;
$time = strtotime($date);
print $date . \n;
print $time . \n;
$xmlrpc_date = (string)$date;
xmlrpc_set_type($xmlrpc_date, 'datetime');
print $xmlrpc_date-timestamp . \n;;
print date(Y-m-d H:i:s, $time) . \n;
print date(Y-m-d H:i:s, $xmlrpc_date-timestamp);
/* 5.2.6 / ubuntu says:
20060116T19:14:03
1137438843
1137401043
2006-01-16 19:14:03
2006-01-16 08:44:03
*/
Expected result:
20060116T19:14:03
1137438843
1137438843
2006-01-16 19:14:03
2006-01-16 19:14:03
Actual result:
--
20060116T19:14:03
1137438843
1137401043
2006-01-16 19:14:03
2006-01-16 08:44:03
--
Edit bug report at http://bugs.php.net/?id=47263edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47263r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47263r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47263r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47263r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47263r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47263r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47263r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47263r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47263r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47263r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47263r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47263r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47263r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47263r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47263r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47263r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47263r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47263r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47263r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47263r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47263r=mysqlcfg
#46792 [Fbk-Opn]: SoapFault detail property missing
ID: 46792
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: Windows
PHP Version: 5.2.7
Assigned To: dmitry
New Comment:
Not having the property defined was surprising, and unexpected - I
would not expect code which reads SoapFault::$detail to ever generate an
E_NOTICE.
Previous Comments:
[2009-01-11 09:40:03] dmi...@php.net
I don't think we should create empty detail property (and then encode
it and send back to client) if it's not important. Very rare script
looks into fault details. In case your script really needs it, it can
always check it with isset() or empty().
[2008-12-31 17:39:13] fel...@php.net
Hi Dmitry, any objection?
http://felipe.ath.cx/diff/bug46792.diff
[2008-12-08 00:06:24] daniel dot oconnor at gmail dot com
Description:
If you don't supply a detail param in the constructor of SoapFault, the
property doesn't exist.
See also bug #39357
Reproduce code:
---
?php
$sf = new SoapFault(null, null, null, Details!);
var_dump($sf);
$sf = new SoapFault(null, null);
var_dump($sf);
Expected result:
Both objects define a detail property
Actual result:
--
object(SoapFault)#1 (8) {
[message:protected]=
string(0)
[string:private]=
string(0)
[code:protected]=
int(0)
[file:protected]=
string(17) C:\soap_fault.php
[line:protected]=
int(2)
[trace:private]=
array(0) {
}
[faultstring]=
string(0)
[detail]=
string(8) Details!
}
object(SoapFault)#2 (7) {
[message:protected]=
string(0)
[string:private]=
string(0)
[code:protected]=
int(0)
[file:protected]=
string(17) C:\soap_fault.php
[line:protected]=
int(6)
[trace:private]=
array(0) {
}
[faultstring]=
string(0)
}
--
Edit this bug report at http://bugs.php.net/?id=46792edit=1
#46792 [NEW]: SoapFault detail property missing
From: daniel dot oconnor at gmail dot com
Operating system: Windows
PHP version: 5.2.7
PHP Bug Type: SOAP related
Bug description: SoapFault detail property missing
Description:
If you don't supply a detail param in the constructor of SoapFault, the
property doesn't exist.
See also bug #39357
Reproduce code:
---
?php
$sf = new SoapFault(null, null, null, Details!);
var_dump($sf);
$sf = new SoapFault(null, null);
var_dump($sf);
Expected result:
Both objects define a detail property
Actual result:
--
object(SoapFault)#1 (8) {
[message:protected]=
string(0)
[string:private]=
string(0)
[code:protected]=
int(0)
[file:protected]=
string(17) C:\soap_fault.php
[line:protected]=
int(2)
[trace:private]=
array(0) {
}
[faultstring]=
string(0)
[detail]=
string(8) Details!
}
object(SoapFault)#2 (7) {
[message:protected]=
string(0)
[string:private]=
string(0)
[code:protected]=
int(0)
[file:protected]=
string(17) C:\soap_fault.php
[line:protected]=
int(6)
[trace:private]=
array(0) {
}
[faultstring]=
string(0)
}
--
Edit bug report at http://bugs.php.net/?id=46792edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46792r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46792r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46792r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46792r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46792r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46792r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46792r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46792r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46792r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46792r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46792r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46792r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46792r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46792r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46792r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46792r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46792r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46792r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46792r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46792r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46792r=mysqlcfg
#44752 [NEW]: Crash with new DateTimeZone(null)
From: daniel dot oconnor at gmail dot com
Operating system: Windows XP
PHP version: 5.2.5
PHP Bug Type: Date/time related
Bug description: Crash with new DateTimeZone(null)
Description:
new DateTimeZone crashes apache when given something it can't recognize.
timezone_open is more robust
This has similar symptoms to Bug #43377 ; but is probably different
Reproduce code:
---
?php
$dt = timezone_open(Australia/Adelaide);
var_dump($dt);
$dt = timezone_open();
var_dump($dt);
$dt = timezone_open(null);
var_dump($dt);
$dt = new DateTimeZone(Australia/Adelaide);
var_dump($dt);
$dt = new DateTimeZone();
var_dump($dt);
$dt = new DateTimeZone(null);
var_dump($dt);
Expected result:
object(DateTimeZone)#1 (0) {
}
bool(false)
bool(false)
object(DateTimeZone)#1 (0) {
}
bool(false)
bool(false)
Actual result:
--
object(DateTimeZone)#1 (0) {
}
bool(false)
bool(false)
object(DateTimeZone)#1 (0) {
}
--
Edit bug report at http://bugs.php.net/?id=44752edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44752r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44752r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44752r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44752r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44752r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44752r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44752r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44752r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44752r=support
Expected behavior:http://bugs.php.net/fix.php?id=44752r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44752r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44752r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44752r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44752r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44752r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44752r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44752r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44752r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44752r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44752r=mysqlcfg
#44489 [NEW]: libxslt 1.1.22 fails to compile XSL
From: daniel dot oconnor at gmail dot com
Operating system: Windows
PHP version: 5.3CVS-2008-03-20 (snap)
PHP Bug Type: XSLT related
Bug description: libxslt 1.1.22 fails to compile XSL
Description:
I'm pretty sure this is an upstream libxsl bug itself, rather than a PHP
bug; but...
xsl
XSL = enabled
libxslt Version = 1.1.22
libxslt compiled against libxml Version = 2.6.31
EXSLT = enabled
libexslt Version = 0.8.13
Transforming
http://www.w3.org/2001/sw/grddl-wg/td/hl7-sample
with
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt
fails to compile
PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 179 element
type in G:\work\xml_grddl\tests\bug-h17.php on line 13
This does function correctly with xsltproc from the command line;
Using libxml 20630, libxslt 10122 and libexslt 813
Reproduce code:
---
?php
/*
phpinfo();
xsl
XSL = enabled
libxslt Version = 1.1.22
libxslt compiled against libxml Version = 2.6.31
EXSLT = enabled
libexslt Version = 0.8.13
*/
$xsl = new DOMDocument();
$xsl-load('http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt');
$xml = new DOMDocument();
$xml-load('http://www.w3.org/2001/sw/grddl-wg/td/hl7-sample.xml');
$proc = new XSLTProcessor();
$proc-importStyleSheet($xsl);
$result = $proc-transformToXML($xml);
var_dump($result);
/*
-- PHP --
phpinfo()
PHP Version = 5.2.6-dev
bool(false)
PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 179 element
type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource': The
content is expected to be a single text node when compiling an AVT. in
G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 200 element
type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource': The
content is expected to be a single text node when compiling an AVT. in
G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 208 element
type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource': The
content is expected to be a single text node when compiling an AVT. in
G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::transformToXml(): No stylesheet associated to
this object in G:\work\xml_grddl\tests\bug-h17.php on line 15
*/
/*
Works with...
G:\libxml2-2.6.30+.win32\binxsltproc.exe
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt
http://www.w3.org/2001/sw/grddl-wg/td/hl7-sample.
xml
xsltproc --version
Using libxml 20630, libxslt 10122 and libexslt 813
xsltproc was compiled against libxml 20630, libxslt 10122 and libexslt
813
libxslt 10122 was compiled against libxml 20630
libexslt 813 was compiled against libxml 20630
*/
/*
G:\work\xml_grddl\scriptsphp -v
PHP 5.2.6RC3-dev (cli) (built: Mar 20 2008 08:04:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
G:\work\xml_grddl\scripts
*/
Expected result:
XML transformation
Actual result:
--
bool(false)
PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 179 element
type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource': The
content is expected to be a single text node when compiling an AVT. in
G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 200 element
type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource': The
content is expected to be a single text node when compiling an AVT. in
G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 208 element
type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource': The
content is expected to be a single text node when compiling an AVT. in
G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::transformToXml(): No stylesheet associated to
this object in G:\work\xml_grddl\tests\bug-h17.php on line 15
--
Edit bug report at http://bugs.php.net/?id=44489edit=1
--
Try a CVS snapshot (PHP 5.2
#44489 [Opn]: libxslt 1.1.22 fails to compile XSL
ID: 44489
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
Status: Open
Bug Type: XSLT related
Operating System: Windows
PHP Version: 5.3CVS-2008-03-20 (snap)
New Comment:
See also: http://bugzilla.gnome.org/show_bug.cgi?id=523548
Previous Comments:
[2008-03-20 13:23:41] daniel dot oconnor at gmail dot com
Description:
I'm pretty sure this is an upstream libxsl bug itself, rather than a
PHP bug; but...
xsl
XSL = enabled
libxslt Version = 1.1.22
libxslt compiled against libxml Version = 2.6.31
EXSLT = enabled
libexslt Version = 0.8.13
Transforming
http://www.w3.org/2001/sw/grddl-wg/td/hl7-sample
with
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt
fails to compile
PHP Warning: XSLTProcessor::importStylesheet(): compilation error:
file http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 179
element type in G:\work\xml_grddl\tests\bug-h17.php on line 13
This does function correctly with xsltproc from the command line;
Using libxml 20630, libxslt 10122 and libexslt 813
Reproduce code:
---
?php
/*
phpinfo();
xsl
XSL = enabled
libxslt Version = 1.1.22
libxslt compiled against libxml Version = 2.6.31
EXSLT = enabled
libexslt Version = 0.8.13
*/
$xsl = new DOMDocument();
$xsl-load('http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt');
$xml = new DOMDocument();
$xml-load('http://www.w3.org/2001/sw/grddl-wg/td/hl7-sample.xml');
$proc = new XSLTProcessor();
$proc-importStyleSheet($xsl);
$result = $proc-transformToXML($xml);
var_dump($result);
/*
-- PHP --
phpinfo()
PHP Version = 5.2.6-dev
bool(false)
PHP Warning: XSLTProcessor::importStylesheet(): compilation error:
file http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 179
element type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource':
The content is expected to be a single text node when compiling an AVT.
in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): compilation error:
file http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 200
element type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource':
The content is expected to be a single text node when compiling an AVT.
in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): compilation error:
file http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 208
element type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource':
The content is expected to be a single text node when compiling an AVT.
in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::transformToXml(): No stylesheet associated
to this object in G:\work\xml_grddl\tests\bug-h17.php on line 15
*/
/*
Works with...
G:\libxml2-2.6.30+.win32\binxsltproc.exe
http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt
http://www.w3.org/2001/sw/grddl-wg/td/hl7-sample.
xml
xsltproc --version
Using libxml 20630, libxslt 10122 and libexslt 813
xsltproc was compiled against libxml 20630, libxslt 10122 and libexslt
813
libxslt 10122 was compiled against libxml 20630
libexslt 813 was compiled against libxml 20630
*/
/*
G:\work\xml_grddl\scriptsphp -v
PHP 5.2.6RC3-dev (cli) (built: Mar 20 2008 08:04:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
G:\work\xml_grddl\scripts
*/
Expected result:
XML transformation
Actual result:
--
bool(false)
PHP Warning: XSLTProcessor::importStylesheet(): compilation error:
file http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 179
element type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource':
The content is expected to be a single text node when compiling an AVT.
in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): compilation error:
file http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 200
element type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource':
The content is expected to be a single text node when compiling an AVT.
in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): compilation error:
file http://www.w3.org/2001/sw/grddl-wg/td/hl7-rim-to-pomr.xslt line 208
element type in G:\work\xml_grddl\tests\bug-h17.php on line 13
PHP Warning: XSLTProcessor::importStylesheet(): Attribute 'resource':
The content is expected to be a single text node when compiling an AVT
#44367 [Bgs]: DOMDocument::baseURI parsing is out of whack
ID: 44367
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
Status: Bogus
Bug Type: DOM XML related
Operating System: Windows
PHP Version: 5.2.5
Assigned To: rrichards
New Comment:
:S I hate being pushy / argumentitive, sorry if its coming across that
way.
RFC 2396 is Uniform Resource Identifiers (URI): Generic Syntax
Section 5.1. is Establishing a Base URI describes what I've been
trying to say, probably a little clearer.
XML Base spec @ http://www.w3.org/TR/xmlbase/#rfc2396 says:
Determine a baseURI:
1. The base URI is embedded in the document's content.
2. The base URI is that of the encapsulating entity (message,
document, or none).
3. The base URI is the URI used to retrieve the entity.
4. The base URI is defined by the context of the application.
This is not just how it is implemented in PHP as the other major DOM
parsers implement it the same way
... and that's why the xml:base GRDDL tests were written - to clarify
correct behaviour / check implementations.
Previous Comments:
[2008-03-12 17:16:05] [EMAIL PROTECTED]
still bogus as what you are describing pertains to GRDDL only not DOM,
so when working with GRDDL and DOm you need to check base uri of the
document element, not the DOMDocument.
DOM determines base uri using the xml base spec.
The base URI of a document entity or an external entity is determined
by RFC 2396 rules, namely, that the base URI is the URI used to
retrieve
the document entity or external entity.
This is not just how it is implemented in PHP as the other major DOM
parsers implement it the same way,
[2008-03-11 00:03:46] daniel dot oconnor at gmail dot com
See http://www.w3.org/TR/grddl/#base_misc
http://www.apps.ietf.org/rfc/rfc3986.html#sec-5.1
The way to determine baseURI is:
1. Look for it on the root document element (HTML - base, XML - foo
xml:base=
2. Couldn't find that? Use the URL we retrieved the document with
* And make sure we follow redirects!
3. Couldn't find that? Application specific (but we don't really have
a setBaseURI())
So, condition #1 is broken in 5.2.5 when you do:
?php
$doc =
DOMDocument::load('http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml');
var_dump($doc-baseURI);//Expected http://.example.org/
produces:
string(53) http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml;
[2008-03-10 14:09:30] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Don't know about GRDDL, but for DOM trees, base uri of a DOMDocument is
the URI its loaded from (or for memory based tree, the current dir).
You need to check on the document element to get the base uri you are
looking for.
[2008-03-08 22:20:31] [EMAIL PROTECTED]
Rob, please take a look
[2008-03-08 05:09:06] daniel dot oconnor at gmail dot com
Description:
The W3C clarified a few xml:base issues when publishing the GRDDL
spec.
You can see the tests at
http://www.w3.org/TR/grddl-tests/#ambiguous-infoset.
Basically:
* DOMDocument::loadXML does not detect xml:base attributes
* simplexml_load_file does not detect xml:base attributes (or they are
lost during the importNode phase)
* simplexml_load_string does not detect xml:base attributes (or they
are lost during the importNode phase)
* DOMDocument does not deal with nested xml:base
* DOMDocument does not deal with redirected xml:base locations
To clarify on the redirect-xml:base stuff...
If I request http://foo.com/example.xml
and that redirects me to http://bar.com/example.xml
and bar.com/example.xml said xml:base = http://foo.com/example.xml
... then http://bar.com/example.xml's baseURI should be
http://bar.com/example.xml
Reproduce code:
---
?php
$url = 'http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml';
$xml = file_get_contents($url);
//Load a url
$doc = DOMDocument::load($url);
var_dump($doc-baseURI);//Expected
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
//Load an xml document with xml:base
$doc = DOMDocument::loadXML($xml);
var_dump($doc-baseURI);//Expected
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
//Does it work with importNode?
$sxe = simplexml_load_file($url);
$dom_sxe = dom_import_simplexml($sxe);
$dom = new DOMDocument('1.0');
$dom_sxe = $dom-importNode($dom_sxe, true);
$dom_sxe = $dom-appendChild($dom_sxe);
var_dump($doc-baseURI
#44367 [Bgs]: DOMDocument::baseURI parsing is out of whack
ID: 44367
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
Status: Bogus
Bug Type: DOM XML related
Operating System: Windows
PHP Version: 5.2.5
Assigned To: rrichards
New Comment:
See http://www.w3.org/TR/grddl/#base_misc
http://www.apps.ietf.org/rfc/rfc3986.html#sec-5.1
The way to determine baseURI is:
1. Look for it on the root document element (HTML - base, XML - foo
xml:base=
2. Couldn't find that? Use the URL we retrieved the document with
* And make sure we follow redirects!
3. Couldn't find that? Application specific (but we don't really have
a setBaseURI())
So, condition #1 is broken in 5.2.5 when you do:
?php
$doc =
DOMDocument::load('http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml');
var_dump($doc-baseURI);//Expected http://.example.org/
produces:
string(53) http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml;
Previous Comments:
[2008-03-10 14:09:30] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Don't know about GRDDL, but for DOM trees, base uri of a DOMDocument is
the URI its loaded from (or for memory based tree, the current dir).
You need to check on the document element to get the base uri you are
looking for.
[2008-03-08 22:20:31] [EMAIL PROTECTED]
Rob, please take a look
[2008-03-08 05:09:06] daniel dot oconnor at gmail dot com
Description:
The W3C clarified a few xml:base issues when publishing the GRDDL
spec.
You can see the tests at
http://www.w3.org/TR/grddl-tests/#ambiguous-infoset.
Basically:
* DOMDocument::loadXML does not detect xml:base attributes
* simplexml_load_file does not detect xml:base attributes (or they are
lost during the importNode phase)
* simplexml_load_string does not detect xml:base attributes (or they
are lost during the importNode phase)
* DOMDocument does not deal with nested xml:base
* DOMDocument does not deal with redirected xml:base locations
To clarify on the redirect-xml:base stuff...
If I request http://foo.com/example.xml
and that redirects me to http://bar.com/example.xml
and bar.com/example.xml said xml:base = http://foo.com/example.xml
... then http://bar.com/example.xml's baseURI should be
http://bar.com/example.xml
Reproduce code:
---
?php
$url = 'http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml';
$xml = file_get_contents($url);
//Load a url
$doc = DOMDocument::load($url);
var_dump($doc-baseURI);//Expected
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
//Load an xml document with xml:base
$doc = DOMDocument::loadXML($xml);
var_dump($doc-baseURI);//Expected
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
//Does it work with importNode?
$sxe = simplexml_load_file($url);
$dom_sxe = dom_import_simplexml($sxe);
$dom = new DOMDocument('1.0');
$dom_sxe = $dom-importNode($dom_sxe, true);
$dom_sxe = $dom-appendChild($dom_sxe);
var_dump($doc-baseURI);//Expected (maybe)
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
// Alternative?
$sxe = simplexml_load_string($xml);
$dom_sxe = dom_import_simplexml($sxe);
$dom = new DOMDocument('1.0');
$dom_sxe = $dom-importNode($dom_sxe, true);
$dom_sxe = $dom-appendChild($dom_sxe);
var_dump($doc-baseURI); //Expected (maybe)
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
//What about documents with an invalid xml:base (not on the top level
element)?
$doc =
DOMDocument::load('http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml');
var_dump($doc-baseURI);//Expected http://.example.org/
//What about documents with a *redirected xml:base* ?
//Note: this test case is a little broken because of a W3C server
change - it *should* redirect to
'http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml'
// and thus have a funky new xml:base value
$doc =
DOMDocument::load('http://www.w3.org/2001/sw/grddl-wg/td/xmlWithBase.xml');
var_dump($doc-baseURI);//Expected
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
Expected result:
See reproduce code
Actual result:
--
See reproduce code
--
Edit this bug report at http://bugs.php.net/?id=44367edit=1
#44367 [NEW]: DOMDocument::baseURI parsing is out of whack
From: daniel dot oconnor at gmail dot com
Operating system: Windows
PHP version: 5.2.5
PHP Bug Type: DOM XML related
Bug description: DOMDocument::baseURI parsing is out of whack
Description:
The W3C clarified a few xml:base issues when publishing the GRDDL spec.
You can see the tests at
http://www.w3.org/TR/grddl-tests/#ambiguous-infoset.
Basically:
* DOMDocument::loadXML does not detect xml:base attributes
* simplexml_load_file does not detect xml:base attributes (or they are
lost during the importNode phase)
* simplexml_load_string does not detect xml:base attributes (or they are
lost during the importNode phase)
* DOMDocument does not deal with nested xml:base
* DOMDocument does not deal with redirected xml:base locations
To clarify on the redirect-xml:base stuff...
If I request http://foo.com/example.xml
and that redirects me to http://bar.com/example.xml
and bar.com/example.xml said xml:base = http://foo.com/example.xml
... then http://bar.com/example.xml's baseURI should be
http://bar.com/example.xml
Reproduce code:
---
?php
$url = 'http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml';
$xml = file_get_contents($url);
//Load a url
$doc = DOMDocument::load($url);
var_dump($doc-baseURI);//Expected
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
//Load an xml document with xml:base
$doc = DOMDocument::loadXML($xml);
var_dump($doc-baseURI);//Expected
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
//Does it work with importNode?
$sxe = simplexml_load_file($url);
$dom_sxe = dom_import_simplexml($sxe);
$dom = new DOMDocument('1.0');
$dom_sxe = $dom-importNode($dom_sxe, true);
$dom_sxe = $dom-appendChild($dom_sxe);
var_dump($doc-baseURI);//Expected (maybe)
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
// Alternative?
$sxe = simplexml_load_string($xml);
$dom_sxe = dom_import_simplexml($sxe);
$dom = new DOMDocument('1.0');
$dom_sxe = $dom-importNode($dom_sxe, true);
$dom_sxe = $dom-appendChild($dom_sxe);
var_dump($doc-baseURI); //Expected (maybe)
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
//What about documents with an invalid xml:base (not on the top level
element)?
$doc =
DOMDocument::load('http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml');
var_dump($doc-baseURI);//Expected http://.example.org/
//What about documents with a *redirected xml:base* ?
//Note: this test case is a little broken because of a W3C server change -
it *should* redirect to
'http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml'
// and thus have a funky new xml:base value
$doc =
DOMDocument::load('http://www.w3.org/2001/sw/grddl-wg/td/xmlWithBase.xml');
var_dump($doc-baseURI);//Expected
http://www.w3.org/2001/sw/grddl-wg/td/base/xmlWithBase.xml
Expected result:
See reproduce code
Actual result:
--
See reproduce code
--
Edit bug report at http://bugs.php.net/?id=44367edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44367r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44367r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44367r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44367r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44367r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44367r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44367r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44367r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44367r=support
Expected behavior:http://bugs.php.net/fix.php?id=44367r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44367r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44367r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44367r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44367r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44367r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44367r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44367r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44367r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44367r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44367r=mysqlcfg
#44225 [NEW]: Build with newer libxml on for windows
From: daniel dot oconnor at gmail dot com
Operating system: Windows
PHP version: 5.2.5
PHP Bug Type: Feature/Change Request
Bug description: Build with newer libxml on for windows
Description:
Any chance of getting the version of libxml, libxslt, libexslt bumped
higher for windows builds?
Something around the libxml 2.6.30, libxslt 10122 and libexslt 813 mark?
The current bundled libraries produce incorrect XSLT results.
This in turn blocks implementing a php grddl implementation that properly
conforms to the spec (http://www.w3.org/2004/01/rdxh/spec)
Reproduce code:
---
?php
$xml =
http://www.w3.org/2001/sw/grddl-wg/td/xhtmlWithMoreThanOneGrddlTransformation.html;;
$stylesheet = http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl;;
$dom = new DOMDocument('1.0');
$dom-load($xml);
$xsl = new DOMDocument();
$xsl-load($stylesheet);
$proc = new XSLTProcessor();
$proc-importStyleSheet($xsl);
print $proc-transformToXML($dom);
phpinfo(8);
Expected result:
C:\xsltproc http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl
http://www.w3.org/2001/sw/grddl-wg/td/xhtmlWithMoreThanOneGrddlTransformation.html
rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#;
xmlns:foaf=http://xmlns.com/foaf/0.1/;
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=http://www.w3.org/People/Dom//
/dc:creator
/rdf:Description
/rdf:RDF
C:\xsltproc --version
Using libxml 20630, libxslt 10122 and libexslt 813
xsltproc was compiled against libxml 20630, libxslt 10122 and libexslt
813
libxslt 10122 was compiled against libxml 20630
libexslt 813 was compiled against libxml 20630
Actual result:
--
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
?xml version=1.0 encoding=utf-8?
rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#;
xmlns:foaf=http://xmlns.com/foaf/0.1/;
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=//
/dc:creator
/rdf:Description
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=simpleTransform.xsl/
/dc:creator
/rdf:Description
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=getAuthor.xsl/
/dc:creator
/rdf:Description
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=http://www.w3.org/People/Dom//
/dc:creator
/rdf:Description
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=mailto:[EMAIL PROTECTED]/
/dc:creator
/rdf:Description
/rdf:RDF
phpinfo()
bcmath
BCMath support = enabled
calendar
Calendar support = enabled
com_dotnet
COM support = enabled
DCOM support = disabled
.Net support = enabled
Directive = Local Value = Master Value
com.allow_dcom = 0 = 0
com.autoregister_casesensitive = 1 = 1
com.autoregister_typelib = 0 = 0
com.autoregister_verbose = 0 = 0
com.code_page = no value = no value
com.typelib_file = no value = no value
ctype
ctype functions = enabled
date
date/time support = enabled
Olson Timezone Database Version = 2007.9
Timezone Database = internal
Default timezone = UTC
Directive = Local Value = Master Value
date.default_latitude = 31.7667 = 31.7667
date.default_longitude = 35.2333 = 35.2333
date.sunrise_zenith = 90.58 = 90.58
date.sunset_zenith = 90.58 = 90.58
date.timezone = no value = no value
dom
DOM/XML = enabled
DOM/XML API Version = 20031129
libxml Version = 2.6.26
HTML Support = enabled
XPath Support = enabled
XPointer Support = enabled
Schema Support = enabled
RelaxNG Support = enabled
filter
Input
#44140 [Bgs]: XMLNS seem to be ignored for selecting attributes
ID: 44140
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
Status: Bogus
Bug Type: XSLT related
Operating System: Windows
PHP Version: 5.2.5
New Comment:
Attributes are never in the default namespace, they have always to be
declared specifically. See the XML Specs for details
So you mean it should have been '//example:[EMAIL PROTECTED]:sequence' ?
If so, then PHP is choosing the wrong behaviour.
Previous Comments:
[2008-02-17 08:29:30] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Attributes are never in the default namespace, they have always to be
declared specifically. See the XML Specs for details
[2008-02-17 05:52:19] daniel dot oconnor at gmail dot com
Description:
If an element + attribute are in a namespace, do both need to
explicitly referenced with said namespace?
Currently:
//example:[EMAIL PROTECTED] vs //example:[EMAIL PROTECTED]:sequence
Which is the correct behaviour? PHP currently chooses the first.
Reproduce code:
---
?php
/* bug.xsl
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:example=http://example.com/;
xsl:template match=example:Numbers
I expect to see 54321 54321 One Two Three Four Five after this
point
xsl:value-of select=@sequence /
xsl:value-of select=@example:sequence /
xsl:value-of select=. /
/xsl:template
/xsl:stylesheet
*/
/* bug.xml
?xml version=1.0 encoding=utf-8?
Example xmlns=http://example.com/; xmlns:ex=http://example.com;
Numbers ex:sequence=54321 sequence=12345One Two Three Four
Five/Numbers
/Example
*/
if (!extension_loaded('xsl')) {
die(Don't forget to enable to xsl extension);
}
$xml = new DOMDocument;
$xml-load(dirname(__FILE__) . '/bug.xml');
$xsl = new DOMDocument;
$xsl-load(dirname(__FILE__) . '/bug.xsl');
$proc = new XSLTProcessor;
$proc-importStyleSheet($xsl); // attach the xsl rules
print $proc-transformToXML($xml);
?
Expected result:
-- php --
?xml version=1.0?
I expect to see 54321 54321 One Two Three Four Five after this
point
5432154321One Two Three Four Five
Output completed (0 sec consumed) - Normal Termination
Actual result:
--
-- php --
?xml version=1.0?
I expect to see 54321 54321 One Two Three Four Five after this
point
12345One Two Three Four Five
Output completed (0 sec consumed) - Normal Termination
--
Edit this bug report at http://bugs.php.net/?id=44140edit=1
#44140 [NEW]: XMLNS seem to be ignored for selecting attributes
From: daniel dot oconnor at gmail dot com
Operating system: Windows
PHP version: 5.2.5
PHP Bug Type: XSLT related
Bug description: XMLNS seem to be ignored for selecting attributes
Description:
If an element + attribute are in a namespace, do both need to explicitly
referenced with said namespace?
Currently:
//example:[EMAIL PROTECTED] vs //example:[EMAIL PROTECTED]:sequence
Which is the correct behaviour? PHP currently chooses the first.
Reproduce code:
---
?php
/* bug.xsl
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:example=http://example.com/;
xsl:template match=example:Numbers
I expect to see 54321 54321 One Two Three Four Five after this
point
xsl:value-of select=@sequence /
xsl:value-of select=@example:sequence /
xsl:value-of select=. /
/xsl:template
/xsl:stylesheet
*/
/* bug.xml
?xml version=1.0 encoding=utf-8?
Example xmlns=http://example.com/; xmlns:ex=http://example.com;
Numbers ex:sequence=54321 sequence=12345One Two Three Four
Five/Numbers
/Example
*/
if (!extension_loaded('xsl')) {
die(Don't forget to enable to xsl extension);
}
$xml = new DOMDocument;
$xml-load(dirname(__FILE__) . '/bug.xml');
$xsl = new DOMDocument;
$xsl-load(dirname(__FILE__) . '/bug.xsl');
$proc = new XSLTProcessor;
$proc-importStyleSheet($xsl); // attach the xsl rules
print $proc-transformToXML($xml);
?
Expected result:
-- php --
?xml version=1.0?
I expect to see 54321 54321 One Two Three Four Five after this
point
5432154321One Two Three Four Five
Output completed (0 sec consumed) - Normal Termination
Actual result:
--
-- php --
?xml version=1.0?
I expect to see 54321 54321 One Two Three Four Five after this
point
12345One Two Three Four Five
Output completed (0 sec consumed) - Normal Termination
--
Edit bug report at http://bugs.php.net/?id=44140edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44140r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44140r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44140r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44140r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44140r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44140r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44140r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44140r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44140r=support
Expected behavior:http://bugs.php.net/fix.php?id=44140r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44140r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44140r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44140r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44140r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44140r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44140r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44140r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44140r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44140r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44140r=mysqlcfg
#42635 [NEW]: var_dump() should render more precise floats
From: daniel dot oconnor at gmail dot com
Operating system: Irrelevant
PHP version: 5.2.4
PHP Bug Type: Feature/Change Request
Bug description: var_dump() should render more precise floats
Description:
var_dump() does not show the actual value of floats; but rather performs
rounding before rendering.
This can lead to hard to decipher loss of precision bugs. If you then use
var_dump() to try to compare output, you aren't going to find the *actual*
values of the numbers you are comparing.
For this reason, I'd like to ask var_dump() renders the complete
representation of the number; where needed in scientific notation.
Reproduce code:
---
?php
function variance($a, $b) {
return (double)100.00 - (double)(($a/$b) * 100.00);
}
var_dump(12.99); //12.99
var_dump(variance(87.01, 100.00)); //12.99
var_dump(variance(87.01, 100.00) - 12.99); //difference
-5.3290705182008E-15
Expected result:
-- php --
float(12.99)
float(12.99) // should be 12.99 + -5.3290705182008E-15
float(-5.3290705182008E-15)
Output completed (0 sec consumed) - Normal Termination
Actual result:
--
-- php --
float(12.99)
float(12.99)
float(-5.3290705182008E-15)
Output completed (0 sec consumed) - Normal Termination
--
Edit bug report at http://bugs.php.net/?id=42635edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42635r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42635r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42635r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42635r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42635r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42635r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42635r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42635r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42635r=support
Expected behavior:http://bugs.php.net/fix.php?id=42635r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42635r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42635r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42635r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42635r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42635r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42635r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42635r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42635r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42635r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42635r=mysqlcfg
#41335 [NEW]: strtotime does not parse australian style dates correctly
From: daniel dot oconnor at gmail dot com
Operating system: All
PHP version: 5.2.2
PHP Bug Type: Date/time related
Bug description: strtotime does not parse australian style dates correctly
Description:
Australians tend to do dates in dd/mm/ format, rather than mm/dd/
strtotime cannot handle this when the seperator is a '/', but can for '-'
and '.'
PHP should either:
* Use consistent parsing all the way through. It should not matter if I
pick a '-', '/' or '.'
* Provide me an argument or configuration setting with which I can change
the default behaviour.
See http://en.wikipedia.org/wiki/Calendar_date#Date_format for a list
of countries which use dd/mm/ as a default, compared to a list of those
who use mm/dd/.
Reproduce code:
---
?php
print phpversion() . \n\n;
$times = array();
$times[] = '1-10-2007';
$times[] = '1/10/2007';
$times[] = '1.10.2007';
$times[] = '13-10-2007';
$times[] = '13/10/2007';
$times[] = '13.10.2007';
$times[] = '2007-10-10';
$times[] = '2007/10/10';
$times[] = '2007.10.10';
$times[] = '13-13-2007';
$times[] = '13/13/2007';
$times[] = '13.13.2007';
foreach ($times as $time) {
print $time .\n\t . strtotime($time) . \n\t . date('Y-m-d H:i:sa',
strtotime($time)) . \n\n;
}
Expected result:
-- php --
5.2.2
1-10-2007
1191196800
2007-10-01 00:00:00am
1/10/2007
1168387200
2007-01-10 00:00:00am
1.10.2007
1191196800
2007-10-01 00:00:00am
13-10-2007
1192233600
2007-10-13 00:00:00am
13/10/2007
1192233600
2007-10-13 00:00:00am
13.10.2007
1192233600
2007-10-13 00:00:00am
2007-10-10
1191974400
2007-10-10 00:00:00am
2007/10/10
1191974400
2007-10-10 00:00:00am
2007.10.10
1970-01-01 00:00:00am
13-13-2007
1970-01-01 00:00:00am
13/13/2007
1970-01-01 00:00:00am
13.13.2007
1970-01-01 00:00:00am
Output completed (0 sec consumed) - Normal Termination
Actual result:
--
-- php --
5.2.2
1-10-2007
1191196800
2007-10-01 00:00:00am
1/10/2007
1168387200
2007-01-10 00:00:00am
1.10.2007
1191196800
2007-10-01 00:00:00am
13-10-2007
1192233600
2007-10-13 00:00:00am
13/10/2007
1970-01-01 00:00:00am
13.10.2007
1192233600
2007-10-13 00:00:00am
2007-10-10
1191974400
2007-10-10 00:00:00am
2007/10/10
1191974400
2007-10-10 00:00:00am
2007.10.10
1970-01-01 00:00:00am
13-13-2007
1970-01-01 00:00:00am
13/13/2007
1970-01-01 00:00:00am
13.13.2007
1970-01-01 00:00:00am
Output completed (0 sec consumed) - Normal Termination
--
Edit bug report at http://bugs.php.net/?id=41335edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41335r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41335r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41335r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41335r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41335r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41335r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41335r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41335r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41335r=support
Expected behavior:http://bugs.php.net/fix.php?id=41335r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41335r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41335r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41335r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41335r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41335r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41335r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41335r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41335r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41335r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41335r=mysqlcfg
#41257 [NEW]: lookupPrefix, lookupNamespaceURI do not work as expected
From: daniel dot oconnor at gmail dot com
Operating system: Windows, Linux
PHP version: 5.2.1
PHP Bug Type: *General Issues
Bug description: lookupPrefix, lookupNamespaceURI do not work as expected
Description:
DOMDocument should extend DOMNode
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#i-Document), and should be
able to find any xmlns defined in the top level element.
Currently, DOMDocument-lookupPrefix() and
DOMDocument-lookupNamespaceURI() will never return any values other than
null; or warn developers they are using the wrong method.
Additionally, DOMDocument-lookupPrefix friends should be able to
recognise xmlns defined in the root node of a document.
Reproduce code:
---
?php
$xml = '?xml version=1.0 encoding=UTF-8?
office:document-content office:class=text office:version=1.0
xmlns:chart=http://openoffice.org/2000/chart;
xmlns:dc=http://purl.org/dc/elements/1.1/;
xmlns:dom=http://www.w3.org/2001/xml-events;
xmlns:dr3d=http://openoffice.org/2000/dr3d;
xmlns:draw=http://openoffice.org/2000/drawing;
xmlns:fo=http://www.w3.org/1999/XSL/Format;
xmlns:form=http://openoffice.org/2000/form;
xmlns:math=http://www.w3.org/1998/Math/MathML;
xmlns:meta=http://openoffice.org/2000/meta;
xmlns:number=http://openoffice.org/2000/datastyle;
xmlns:office=http://openoffice.org/2000/office;
xmlns:ooo=http://openoffice.org/2004/office;
xmlns:oooc=http://openoffice.org/2004/calc;
xmlns:ooow=http://openoffice.org/2004/writer;
xmlns:script=http://openoffice.org/2000/script;
xmlns:style=http://openoffice.org/2000/style;
xmlns:svg=http://www.w3.org/2000/svg;
xmlns:table=http://openoffice.org/2000/table;
xmlns:text=http://openoffice.org/2000/text;
xmlns:xforms=http://www.w3.org/2002/xforms;
xmlns:xlink=http://www.w3.org/1999/xlink;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
office:body
table:table table:name=Table13 table:style-name=Table13
table:table-column table:style-name=Table13.A /
table:table-row table:style-name=Table13.1
table:table-cell table:style-name=Table13.A1
table:value-type=string
text:p text:style-name=P84Important Notes and
Qualifications/text:p
/table:table-cell
/table:table-row
/table:table
text:p text:style-name=P88lt; lt; func_image(photograph)
gt; gt;/text:p
/office:body
/office:document-content';
$document = new DOMDocument('1.0', 'UTF-8');
$document-loadXML($xml);
foreach
($document-getElementsByTagNameNS('http://openoffice.org/2000/table',
'table') as $element) {
echo 'local name: ', $element-localName, ', prefix: ',
$element-prefix, ' xmlns (element):',
$element-lookupNamespaceURI($element-prefix), ' xmlns (document):',
$document-lookupNamespaceURI($element-prefix), \n;
}
print \n\n;
foreach ($document-getElementsByTagName('*') as $element) {
echo 'local name: ', $element-localName, ', prefix: ',
$element-prefix, ' xmlns (element):',
$element-lookupNamespaceURI($element-prefix), ' xmlns (document):',
$document-lookupNamespaceURI($element-prefix), \n;
}
print \n\n;
foreach ($document-getElementsByTagNameNS('*', '*') as $element) {
echo 'local name: ', $element-localName, ', prefix: ',
$element-prefix, ' xmlns (element):',
$element-lookupNamespaceURI($element-prefix), ' xmlns (document):',
$document-lookupNamespaceURI($element-prefix), \n;
}
print \n\n;
foreach
($document-getElementsByTagNameNS('http://openoffice.org/2000/table', '*')
as $element) {
echo 'local name: ', $element-localName, ', prefix: ',
$element-prefix, ' xmlns (element):',
$element-lookupNamespaceURI($element-prefix), ' xmlns (document):',
$document-lookupNamespaceURI($element-prefix), \n;
}
print \n\n;
foreach
($document-getElementsByTagNameNS('http://openoffice.org/2000/table', '*')
as $element) {
echo 'local name: ', $element-localName, ', prefix: ',
$element-prefix, ' xmlns (element):',
$element-lookupNamespaceURI($element-prefix), ' xmlns (document):',
$document-lookupNamespaceURI($element-prefix), \n;
}
print \n\n;
foreach
($document-getElementsByTagNameNS('http://openoffice.org/2000/table',
'table') as $element) {
echo 'local name: ', $element-localName, ', prefix: ',
$element-prefix, ' xmlns (element):',
$element-lookupNamespaceURI($element-prefix), ' xmlns (document):',
$document-lookupNamespaceURI($element-prefix), \n;
}
Expected result:
$document-lookupNamespaceURI() and $element-lookupNamespaceURI() should
return identical results.
Actual result:
--
local name: table, prefix: table xmlns
(element):http://openoffice.org/2000/table xmlns (document):
--
Edit bug report at http://bugs.php.net/?id=41257edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41257r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41257r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id
#41258 [NEW]: setAttributeNS has inconsistent behaviour when raising exceptions
From: daniel dot oconnor at gmail dot com
Operating system:
PHP version: 5.2.1
PHP Bug Type: *XML functions
Bug description: setAttributeNS has inconsistent behaviour when raising
exceptions
Description:
Inconsistent behaviour when raising exceptions. No exception is raised
until line 10
Reproduce code:
---
?php
$d = new DOMDocument();
$example = $d-createElementNS('http://foo.com','example');
$example-setAttributeNS('http://bar.com', 'bar:bar',value);
$example-setAttributeNS('http://bar.com', 'monkey',value);
$d = new DOMDocument();
$example = $d-createElementNS('http://foo.com','example');
$example-setAttributeNS('http://fish.com', 'bar:bar',value);
$example-setAttributeNS('http://bar.com', 'monkey',value);
Expected result:
1. An exception raised on the second setAttributeNS (line 4)
2. A more meaningful error than 'Namespace Error' - No namespace prefix
found for http://fish.com
Actual result:
--
An exception on line 10
--
Edit bug report at http://bugs.php.net/?id=41258edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41258r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41258r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41258r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41258r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41258r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41258r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41258r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41258r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41258r=support
Expected behavior:http://bugs.php.net/fix.php?id=41258r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41258r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41258r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41258r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41258r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41258r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41258r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41258r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41258r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41258r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41258r=mysqlcfg
#41258 [Bgs]: setAttributeNS has inconsistent behaviour when raising exceptions
ID: 41258
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
Status: Bogus
Bug Type:DOM XML related
PHP Version: 5.2.1
New Comment:
This is not a functionality bug, but a usability one.
Please see http://clockwerx.blogspot.com/2007/05/bogus-this.html for
more detail - it expands on some of the real world use problems related
to the behavior exhibited here. Take it with a grain of salt, because
I've been fighting this code all day and am more than a little cranky.
Previous Comments:
[2007-05-02 12:54:03] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Line 4 is fine as namespace URI with an associated prefix already
exists (it was created when from line 3). The prefix gets attached to
the attribute. Error messages are not a bug, but feel free to open a
feature request for more verbose messages though.
[2007-05-02 08:55:59] daniel dot oconnor at gmail dot com
Description:
Inconsistent behaviour when raising exceptions. No exception is raised
until line 10
Reproduce code:
---
?php
$d = new DOMDocument();
$example = $d-createElementNS('http://foo.com','example');
$example-setAttributeNS('http://bar.com', 'bar:bar',value);
$example-setAttributeNS('http://bar.com', 'monkey',value);
$d = new DOMDocument();
$example = $d-createElementNS('http://foo.com','example');
$example-setAttributeNS('http://fish.com', 'bar:bar',value);
$example-setAttributeNS('http://bar.com', 'monkey',value);
Expected result:
1. An exception raised on the second setAttributeNS (line 4)
2. A more meaningful error than 'Namespace Error' - No namespace
prefix found for http://fish.com
Actual result:
--
An exception on line 10
--
Edit this bug report at http://bugs.php.net/?id=41258edit=1
#40941 [Fbk-Csd]: Segfault with Reflection and undeclared class properties
ID: 40941
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
-Status: Feedback
+Status: Closed
Bug Type: Reproducible crash
Operating System: Ubuntu (fiesty)
PHP Version: 5.2.1
New Comment:
Works For Me, CVS
Previous Comments:
[2007-03-29 08:14:16] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2007-03-29 05:15:14] daniel dot oconnor at gmail dot com
Description:
Segfaults happen when you put something into a class property you
haven't declared.
Probably a dupe of 40460, 40431; but affecting 5.2.1
Reproduce code:
---
?php
class Example {
public function segfault() {
$class = new ReflectionObject($this);
$properties = $class-getProperties();
foreach ($properties as $property) {
//Kaboom!
if ($property-isStatic()) { continue; }
}
return true;
}
public function __construct($jr_id = null) {
$this-d = ;
}
}
$report = new Example();
$report-segfault();
Expected result:
No segfault.
Warnings about undeclared stuff.
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=40941edit=1
#40941 [NEW]: Segfault with Reflection and undeclared class properties
From: daniel dot oconnor at gmail dot com
Operating system: Ubuntu (fiesty)
PHP version: 5.2.1
PHP Bug Type: Reproducible crash
Bug description: Segfault with Reflection and undeclared class properties
Description:
Segfaults happen when you put something into a class property you haven't
declared.
Probably a dupe of 40460, 40431; but affecting 5.2.1
Reproduce code:
---
?php
class Example {
public function segfault() {
$class = new ReflectionObject($this);
$properties = $class-getProperties();
foreach ($properties as $property) {
//Kaboom!
if ($property-isStatic()) { continue; }
}
return true;
}
public function __construct($jr_id = null) {
$this-d = ;
}
}
$report = new Example();
$report-segfault();
Expected result:
No segfault.
Warnings about undeclared stuff.
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=40941edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40941r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40941r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40941r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40941r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40941r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40941r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40941r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40941r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40941r=support
Expected behavior:http://bugs.php.net/fix.php?id=40941r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40941r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40941r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40941r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40941r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40941r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40941r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40941r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40941r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40941r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40941r=mysqlcfg
#39521 [NEW]: DomDocument::createElement() should warn you if you create invalid XML.
From: daniel dot oconnor at gmail dot com
Operating system: Windows
PHP version: 5.2.0
PHP Bug Type: DOM XML related
Bug description: DomDocument::createElement() should warn you if you create
invalid XML.
Description:
DomDocument::createElement() should warn you if you create invalid XML.
Reproduce code:
---
?php
$string = 'treebranchFun Games amp;/branch/tree';
$xml = new SimpleXMLElement($string);
$xml-addChild('actor', 'John Doe');
print $xml-asXML();
$dom = new domDocument;
$dom-loadXML($string);
$dom-appendChild($dom-createTextNode(fish amp; chips));
$node = $dom-createElement('fish', 'ampersand this, amp;');
$dom-appendChild($node);
print $dom-saveXML();
Expected result:
A warning when you do the createElement about the unfinished entity; or at
least when you try the saveXML
Actual result:
--
-- php --
Warning: SimpleXMLElement::addChild(): unterminated entity reference
Doe in C:\vx\tests\simplexml.php on line 6
?xml version=1.0?
treebranchFun Games amp;/branchactorJohn /actor/tree
?xml version=1.0?
treebranchFun Games amp;/branch/tree
fish amp;amp; amp; chips
fishampersand this, amp;/fish
--
Edit bug report at http://bugs.php.net/?id=39521edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39521r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39521r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39521r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39521r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39521r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39521r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39521r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39521r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39521r=support
Expected behavior:http://bugs.php.net/fix.php?id=39521r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39521r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39521r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39521r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39521r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39521r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39521r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39521r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39521r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39521r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39521r=mysqlcfg
#38362 [NEW]: Fatal error: Cannot access empty property unexpectedly
From: daniel dot oconnor at gmail dot com
Operating system:
PHP version: 5.1.4
PHP Bug Type: *General Issues
Bug description: Fatal error: Cannot access empty property unexpectedly
Description:
See also: 28444
PHP gives unexpected errors when creating an object. I understand that i'm
constructing an object, and some properties aren't there yet for reading;
but I would have expected $this-$$date to work exactly the same as
$this-date_Created...
I would also have thought that declaring the class with a value in the
protected member vars meant that these variables are not empty!
Reproduce code:
---
class NexusJob {
protected $date_Created = ''; //dateTime
protected $appointment_Date = ''; //dateTime
protected $valuation_Date = ''; //dateTime
protected $inspection_Date = '';//dateTime
public function __construct() {
$dates = array('date_Created', 'appointment_Date',
'valuation_Date', 'inspection_Date');
foreach ($dates as $date) {
$this-$$date = date(DATE_W3C);
}
}
}
$nj = new NexusJob();
Expected result:
No errors
Actual result:
--
Fatal error: Cannot access empty property
--
Edit bug report at http://bugs.php.net/?id=38362edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38362r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38362r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38362r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38362r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38362r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38362r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38362r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38362r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38362r=support
Expected behavior:http://bugs.php.net/fix.php?id=38362r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38362r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38362r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38362r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38362r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38362r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38362r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38362r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38362r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38362r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38362r=mysqlcfg
#37670 [Fbk-Opn]: Serialize fails unexpectedly
ID: 37670
User updated by: daniel dot oconnor at gmail dot com
Reported By: daniel dot oconnor at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: windows
PHP Version: 5.1.4
New Comment:
Sorry, I can't try it on the CVS copy.
To amend the bug report:
?php
class BugFeed {
protected $cache;
public function __construct($options) {
if (isset($options[cache])) {
$this-cache = $options[cache];
}
}
public function fetch() {}
public static function render($type = edit) {}
}
$stuff = array(new BugFeed(array()));
$cereal = serialize($stuff);
$stuff2 = unserialize($cereal);
$stuff3 = unserialize((string)$cereal);
var_dump($stuff2 == $stuff);
var_dump($stuff3 == $stuff);
var_dump(strlen($cereal));
print $cereal . \n;
print (string)$cereal;
print hello world?;
Produces:
bool(true)
bool(true)
int(45)
a:1:{i:0;O:7:BugFeed:1:{s:8:
---
That is to say: there's an unexpected EOF character output in the
serialized code.
Previous Comments:
[2006-06-02 06:24:13] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Works just fine for me
[2006-06-02 03:28:23] daniel dot oconnor at gmail dot com
Description:
Serialize does not appear to be serializing fully or safely.
Reproduce code:
---
?php
class BugFeed {
protected $cache;
public function __construct($options) {
if (isset($options[cache])) {
$this-cache = $options[cache];
}
}
public function fetch() {}
public static function render($type = edit) {}
}
$stuff = array(new BugFeed(array()));
print serialize($stuff);
Expected result:
a serialized string of my BugFeed object, or if it was unable to
properly serialize it, an exception or warning.
Actual result:
--
a:1:{i:0;O:7:BugFeed:1:{s:8:
--
Edit this bug report at http://bugs.php.net/?id=37670edit=1
#37670 [NEW]: Serialize fails unexpectedly
From: daniel dot oconnor at gmail dot com
Operating system: windows
PHP version: 5.1.4
PHP Bug Type: Class/Object related
Bug description: Serialize fails unexpectedly
Description:
Serialize does not appear to be serializing fully or safely.
Reproduce code:
---
?php
class BugFeed {
protected $cache;
public function __construct($options) {
if (isset($options[cache])) {
$this-cache = $options[cache];
}
}
public function fetch() {}
public static function render($type = edit) {}
}
$stuff = array(new BugFeed(array()));
print serialize($stuff);
Expected result:
a serialized string of my BugFeed object, or if it was unable to properly
serialize it, an exception or warning.
Actual result:
--
a:1:{i:0;O:7:BugFeed:1:{s:8:
--
Edit bug report at http://bugs.php.net/?id=37670edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37670r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37670r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37670r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37670r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37670r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37670r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37670r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37670r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37670r=support
Expected behavior:http://bugs.php.net/fix.php?id=37670r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37670r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37670r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37670r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37670r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37670r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37670r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37670r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37670r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37670r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37670r=mysqlcfg
#37355 [NEW]: SOAP uses deprecated __call method by default
From: daniel dot oconnor at gmail dot com
Operating system: Windows
PHP version: 5.1.4
PHP Bug Type: SOAP related
Bug description: SOAP uses deprecated __call method by default
Description:
5.1.4 appears to be still using __call instead of __soapCall, in at least
one place this causes exceptions without error codes to be thrown.
Reproduce code:
---
?php
$wsdl = 'http://vx.valex.com.au/soap/vxsoap.wsdl';
$client = new SoapClient($wsdl);
$result = $client-login(array(username = fake, password =
user));
?
Expected result:
No SoapFaults thrown, or a SoapFault is thrown with a meaningful error.
Actual result:
--
-- php --
Fatal error: Uncaught SoapFault exception: [SOAP-ENV:Server]
SoapFault::__construct() [a
href='function.SoapFault---construct'function.SoapFault---construct/a]:
Invalid parameters. Invalid fault code. in
C:\vx\tests\unit\soap\LoginTest.php:42
Stack trace:
#0 [internal function]: SoapClient-__call('login', Array)
#1 C:\vx\tests\unit\soap\LoginTest.php(42): SoapClient-login(Array)
#2 {main}
thrown in C:\vx\tests\unit\soap\LoginTest.php on line 42
Output completed (0 sec consumed) - Normal Termination
--
Edit bug report at http://bugs.php.net/?id=37355edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37355r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37355r=trysnapshot51
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37355r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37355r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37355r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37355r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37355r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37355r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37355r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37355r=support
Expected behavior:http://bugs.php.net/fix.php?id=37355r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37355r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37355r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37355r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37355r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37355r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37355r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37355r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37355r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37355r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37355r=mysqlcfg
