#33698 [Bgs]: Conflicts with multiple interfaces sharing common method names
ID: 33698
User updated by: jason at hybd dot net
Reported By: jason at hybd dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.4
New Comment:
I know PHP != Java, but surely this sort of stuff should be documented?
Most people will expect interfaces to work like Java interfaces or C++
interfaces (Pure virtual abstract methods), as many other languages
seem to follow this behaviour. As I said this is debatable as it
depends how you look at things, and likewise it is fairly easy to work
round this issue.
Previous Comments:
[2005-07-15 12:44:04] [EMAIL PROTECTED]
PHP != Java
[2005-07-14 17:35:15] jason at hybd dot net
Description:
This is debateable if this is a bug or not. Personally, I don't regard
it as a bug.
Classes that implement 1 interface that share common methods raise
fatal errors. Because of the abstract nature of interfaces, no error or
warning should be rasied.
I know PHP Java, but Java doesn't raise any errors, and PHP5's OO
model is very close to Java's
Reproduce code:
---
interface FirstInterface
{
function execute();
}
interface SecondInterface
{
function execute();
}
class MyClass implements FirstInterface, SecondInterface
{
function execute()
{
echo Hello World;
}
}
$obj = new MyClass();
$obj-execute();
Expected result:
Hello World
Actual result:
--
Can't inherit abstract function SecondInterface::execute()
--
Edit this bug report at http://bugs.php.net/?id=33698edit=1
#33698 [NEW]: Conflicts with multiple interfaces sharing common method names
From: jason at hybd dot net
Operating system: Irrelevent
PHP version: 5.0.4
PHP Bug Type: Scripting Engine problem
Bug description: Conflicts with multiple interfaces sharing common method names
Description:
This is debateable if this is a bug or not. Personally, I don't regard it
as a bug.
Classes that implement 1 interface that share common methods raise fatal
errors. Because of the abstract nature of interfaces, no error or warning
should be rasied.
I know PHP Java, but Java doesn't raise any errors, and PHP5's OO model
is very close to Java's
Reproduce code:
---
interface FirstInterface
{
function execute();
}
interface SecondInterface
{
function execute();
}
class MyClass implements FirstInterface, SecondInterface
{
function execute()
{
echo Hello World;
}
}
$obj = new MyClass();
$obj-execute();
Expected result:
Hello World
Actual result:
--
Can't inherit abstract function SecondInterface::execute()
--
Edit bug report at http://bugs.php.net/?id=33698edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33698r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33698r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33698r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33698r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33698r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33698r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33698r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33698r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33698r=support
Expected behavior: http://bugs.php.net/fix.php?id=33698r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33698r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33698r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33698r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33698r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33698r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33698r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33698r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33698r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33698r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33698r=mysqlcfg
#33643 [NEW]: Fatal error: Only variables can be passed by reference
From: Jason at hybd dot net
Operating system:
PHP version: 5.1.0b2
PHP Bug Type: Scripting Engine problem
Bug description: Fatal error: Only variables can be passed by reference
Description:
This bug is a rehash of 33516, but I can't reopen as I'm not the original
author.
It seems like you can not pass tempories to function / method parameters.
?php
class Foo {
public static function bar() {
return array('a' = '1234567890');
}
}
$tmp = Foo::bar();
$var = array_pop($tmp);
?
Seems to work, but it shouldn't be down to the PHP user (imho) to
implement this as this change in PHP 5.1 breaks a lot of existing code.
Reproduce code:
---
?php
class Foo {
public static function bar() {
return array('a' = '1234567890');
}
}
$var = array_pop(Foo::bar());
?
Expected result:
$var = '1234567890';
Foo::bar() gets placed in temporary variable
Actual result:
--
Fatal error: Only variables can be passed by reference
--
Edit bug report at http://bugs.php.net/?id=33643edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33643r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33643r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33643r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33643r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33643r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33643r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33643r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33643r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33643r=support
Expected behavior: http://bugs.php.net/fix.php?id=33643r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33643r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33643r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33643r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33643r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33643r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33643r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33643r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33643r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33643r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33643r=mysqlcfg
#33643 [Bgs-Opn]: Fatal error: Only variables can be passed by reference
ID: 33643
User updated by: Jason at hybd dot net
Reported By: Jason at hybd dot net
-Status: Bogus
+Status: Open
Bug Type:Scripting Engine problem
PHP Version: 5.1.0b2
New Comment:
Sorry, it's all fair and well making this bogus, but this change breaks
LOADS of existing code, so it is not a bug and it's behavior is
NOT documented. The least you could have done is justify why this is
not a bug and why this change was introduced into the language!
This is really a PHP bug because thi has worked in all versions of PHP
prior to this. There has been nothing in the way of warning or anything
in recent releases to phase in this change in behaviour like there was
with the call by reference thing.
Do you expect many thousands of programmers to change their code
because if this stupid querk.
Previous Comments:
[2005-07-11 17:32: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
.
[2005-07-11 13:06:46] Jason at hybd dot net
Description:
This bug is a rehash of 33516, but I can't reopen as I'm not the
original author.
It seems like you can not pass tempories to function / method
parameters.
?php
class Foo {
public static function bar() {
return array('a' = '1234567890');
}
}
$tmp = Foo::bar();
$var = array_pop($tmp);
?
Seems to work, but it shouldn't be down to the PHP user (imho) to
implement this as this change in PHP 5.1 breaks a lot of existing code.
Reproduce code:
---
?php
class Foo {
public static function bar() {
return array('a' = '1234567890');
}
}
$var = array_pop(Foo::bar());
?
Expected result:
$var = '1234567890';
Foo::bar() gets placed in temporary variable
Actual result:
--
Fatal error: Only variables can be passed by reference
--
Edit this bug report at http://bugs.php.net/?id=33643edit=1
#32963 [Fbk-Opn]: Hard to find/trace Segfault issues
ID: 32963 User updated by: Jason at hybd dot net Reported By: Jason at hybd dot net -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: CentOS 4 / RHEL 3 PHP Version: 5CVS-2005-05-06 (dev) New Comment: in what way? In the template system I started to play about with, I did use reference operators explictly, much like PHP4. However, since then I haven't used them in other bits of code. I did find that occasionally that using the reference operators did screw things up a while back, and I have had issues such as the one in at http://bugs.php.net/bug.php?id=32745. However the points in which I have used the reference operator, they have nearly always been dealing with objects, and not POD types such as string/int/float types, and therefore would be naturally be passed by reference regardless of there being a reference operator. Out of interest, what way do references affect things internally? Previous Comments: [2005-05-09 23:11:38] [EMAIL PROTECTED] Are you using references extensively? [2005-05-09 19:47:01] Jason at hybd dot net There seems to be no way I can reduce this bug down to a few lines. I can only think some eariler piece of code triggers some sort of memory corruption. I've tried with a test script, fiddling about with things like scopes and making circlar references, thinking maybe that was to do with it (seeing as it's destruction call to the offset that seems to be creating the problem, from what I can make out in the src) Although I don't think it's the same thing as (Certainly I had some code that was doing what was said in these bugs, but it seems like it works now, which makes me believe the bugs below are different, although the behaviour is rather similar at times)... http://bugs.php.net/bug.php?id=30346 OR http://bugs.php.net/bug.php?id=32252 It is very similar. The issue is to do with offsetGet(). Frame 5 of the dump seems to the most likely problem area. [2005-05-09 15:17:20] Jason at hybd dot net In a worst case scenario (if I can't get a small test script developed), would it be OK to email you with access details to the scripts/server so you can investigate for yourself. I can give you suitable SSH access to our testing box. That way you can do what you want in the way of running gdb, recompiling etc if need be. [2005-05-09 11:38:38] [EMAIL PROTECTED] We can't do much without a script to reproduce it ourselves, so try come up with one.. [2005-05-09 11:28:08] jason at amp-design dot net I normally do try and isolate bugs in PHP by producing a short few lines of PHP in order to replicate the problem. I have tried on many occasions when I have had this bug to replicate it by stripping parts of the code down, but I have not managed to do it sucessfully yet. Is there any other way I can profide feedback? I could probably try and limit the amount code down to some extent, but even so I doubt it would be a small chunk of code. Anyway, I will attempt to find a way to replicate this as soon as I can get time. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32963 -- Edit this bug report at http://bugs.php.net/?id=32963edit=1
#32963 [Opn]: Hard to find/trace Segfault issues
ID: 32963 User updated by: Jason at hybd dot net Reported By: Jason at hybd dot net Status: Open Bug Type: Reproducible crash Operating System: CentOS 4 / RHEL 3 PHP Version: 5CVS-2005-05-06 (dev) New Comment: Hi Derick, You're a ledgend! I was having to do some changes to some of the code that was crashing. Funnily enough I changed some and decided I'd use a reference to an array element. All of a sudden the segfaults returned, and I did a backtrace on our live server (for some reason, probably relating to my clumsiness, the test box doesn't give us backtraces despite compiling with --enable-debug). The backtrace gives exactly the same results. It seems the segfault does not happen though until further down in the program. I would guess it does it where some of the ArrayAccess stuff is used. I'll see if I can develop a test script again to reproduce this bug, now I have a clearer idea what seems to be causing it. Previous Comments: [2005-05-10 11:30:58] Jason at hybd dot net in what way? In the template system I started to play about with, I did use reference operators explictly, much like PHP4. However, since then I haven't used them in other bits of code. I did find that occasionally that using the reference operators did screw things up a while back, and I have had issues such as the one in at http://bugs.php.net/bug.php?id=32745. However the points in which I have used the reference operator, they have nearly always been dealing with objects, and not POD types such as string/int/float types, and therefore would be naturally be passed by reference regardless of there being a reference operator. Out of interest, what way do references affect things internally? [2005-05-09 23:11:38] [EMAIL PROTECTED] Are you using references extensively? [2005-05-09 19:47:01] Jason at hybd dot net There seems to be no way I can reduce this bug down to a few lines. I can only think some eariler piece of code triggers some sort of memory corruption. I've tried with a test script, fiddling about with things like scopes and making circlar references, thinking maybe that was to do with it (seeing as it's destruction call to the offset that seems to be creating the problem, from what I can make out in the src) Although I don't think it's the same thing as (Certainly I had some code that was doing what was said in these bugs, but it seems like it works now, which makes me believe the bugs below are different, although the behaviour is rather similar at times)... http://bugs.php.net/bug.php?id=30346 OR http://bugs.php.net/bug.php?id=32252 It is very similar. The issue is to do with offsetGet(). Frame 5 of the dump seems to the most likely problem area. [2005-05-09 15:17:20] Jason at hybd dot net In a worst case scenario (if I can't get a small test script developed), would it be OK to email you with access details to the scripts/server so you can investigate for yourself. I can give you suitable SSH access to our testing box. That way you can do what you want in the way of running gdb, recompiling etc if need be. [2005-05-09 11:38:38] [EMAIL PROTECTED] We can't do much without a script to reproduce it ourselves, so try come up with one.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32963 -- Edit this bug report at http://bugs.php.net/?id=32963edit=1
#32963 [Fbk-Opn]: Hard to find/trace Segfault issues
ID: 32963
User updated by: Jason at hybd dot net
-Reported By: jason at amp-design dot net
+Reported By: Jason at hybd dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: CentOS 4 / RHEL 3
PHP Version: 5CVS-2005-05-06 (dev)
New Comment:
In a worst case scenario (if I can't get a small test script
developed), would it be OK to email you with access details to the
scripts/server so you can investigate for yourself. I can give you
suitable SSH access to our testing box. That way you can do what you
want in the way of running gdb, recompiling etc if need be.
Previous Comments:
[2005-05-09 11:38:38] [EMAIL PROTECTED]
We can't do much without a script to reproduce it ourselves, so try
come up with one..
[2005-05-09 11:28:08] jason at amp-design dot net
I normally do try and isolate bugs in PHP by producing a short few
lines of PHP in order to replicate the problem.
I have tried on many occasions when I have had this bug to replicate it
by stripping parts of the code down, but I have not managed to do it
sucessfully yet. Is there any other way I can profide feedback? I could
probably try and limit the amount code down to some extent, but even so
I doubt it would be a small chunk of code.
Anyway, I will attempt to find a way to replicate this as soon as I can
get time.
[2005-05-07 05:48:04] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-05-06 16:05:48] jason at amp-design dot net
OK, I've tried to narrow down things a little more. This is not proving
easy.
OK, I can see why this is making things crash according to different
browsers. I have a piece of code like this ...
/**
* Extracts path data from URL into a string.
*
* This will attempt to read the path data from many locations,
* such as after the .php part of the URL, the path request variable
* or from the site root.
*/
function iq_extract_path() {
if (!isset($_REQUEST['path'])) {
/* try to extract it from URL */
$path_string = $_SERVER['REQUEST_URI'];
/* Are we hiding the .php file ? */
if (strpos($_SERVER['SCRIPT_NAME'], '.php') !== false) {
/* Remove the index or whatever .php bit */
$path_string = preg_replace('/\/[\w]+.php/', '',
$path_string);
}
/* We need to trim on / or it replaces '/' if we are running
from
root dir */
$prefix_path = trim(dirname($_SERVER['SCRIPT_NAME']), '/');
/* Remove any prefixed URL path */
$path_string = str_replace($prefix_path, '', $path_string);
/* remove query string */
$path_string = str_replace('?'.$_SERVER['QUERY_STRING'], '',
$path_string);
} else {
$path_string = $_REQUEST['path'];
}
return $path_string;
}
As you can see, this looks at server variables, which explains that. On
the site it's used, it allows us to use a clean search engine / user
friendly URL system, instead of using HTTP GET/POST variables for the
front controller's dispatching. If no server variables are used, it
looks at $_REQUEST['path'] as a safety fallback.
I found that setting $_REQUEST['path'] to the right value (so it
doesn't touch the $_SERVER array) stops the segfault.
The segfault it's self is because of the SPL. I'm 99.9% sure of
this. zend_execute.c:1205 confirms this, and other scenarios where I
get segfaults normally involve SPL ArrayAccess objects.
We use a template system, which is modelled as an object. This
implements the ArrayAccess interface, so it makes it easy to set
variables. It's initialized like this ...
$payment_schedule = new IQ_Template('admin/payment_schedule.xml');
we can poke data in like this...
$payment_schedule['schedule_year'] = $year;
likewise, there is some system in place where we can write custom web
controls so it behaves like WACT / ASP.NETs template system.
Anyway, I found another way to prevent the crash, instead of setting
$_REQUEST['path'] was to place ...
$payment_schedule = 'insert random string here';
before the line
$payment_schedule = new IQ_Template('admin/payment_schedule.xml
#32963 [Opn]: Hard to find/trace Segfault issues
ID: 32963
User updated by: Jason at hybd dot net
Reported By: Jason at hybd dot net
Status: Open
Bug Type: Reproducible crash
Operating System: CentOS 4 / RHEL 3
PHP Version: 5CVS-2005-05-06 (dev)
New Comment:
There seems to be no way I can reduce this bug down to a few lines. I
can only think some eariler piece of code triggers some sort of memory
corruption. I've tried with a test script, fiddling about with things
like scopes and making circlar references, thinking maybe that was to
do with it (seeing as it's destruction call to the offset that seems to
be creating the problem, from what I can make out in the src)
Although I don't think it's the same thing as (Certainly I had some
code that was doing what was said in these bugs, but it seems like it
works now, which makes me believe the bugs below are different,
although the behaviour is rather similar at times)...
http://bugs.php.net/bug.php?id=30346
OR
http://bugs.php.net/bug.php?id=32252
It is very similar. The issue is to do with offsetGet(). Frame 5 of the
dump seems to the most likely problem area.
Previous Comments:
[2005-05-09 15:17:20] Jason at hybd dot net
In a worst case scenario (if I can't get a small test script
developed), would it be OK to email you with access details to the
scripts/server so you can investigate for yourself. I can give you
suitable SSH access to our testing box. That way you can do what you
want in the way of running gdb, recompiling etc if need be.
[2005-05-09 11:38:38] [EMAIL PROTECTED]
We can't do much without a script to reproduce it ourselves, so try
come up with one..
[2005-05-09 11:28:08] jason at amp-design dot net
I normally do try and isolate bugs in PHP by producing a short few
lines of PHP in order to replicate the problem.
I have tried on many occasions when I have had this bug to replicate it
by stripping parts of the code down, but I have not managed to do it
sucessfully yet. Is there any other way I can profide feedback? I could
probably try and limit the amount code down to some extent, but even so
I doubt it would be a small chunk of code.
Anyway, I will attempt to find a way to replicate this as soon as I can
get time.
[2005-05-07 05:48:04] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-05-06 16:05:48] jason at amp-design dot net
OK, I've tried to narrow down things a little more. This is not proving
easy.
OK, I can see why this is making things crash according to different
browsers. I have a piece of code like this ...
/**
* Extracts path data from URL into a string.
*
* This will attempt to read the path data from many locations,
* such as after the .php part of the URL, the path request variable
* or from the site root.
*/
function iq_extract_path() {
if (!isset($_REQUEST['path'])) {
/* try to extract it from URL */
$path_string = $_SERVER['REQUEST_URI'];
/* Are we hiding the .php file ? */
if (strpos($_SERVER['SCRIPT_NAME'], '.php') !== false) {
/* Remove the index or whatever .php bit */
$path_string = preg_replace('/\/[\w]+.php/', '',
$path_string);
}
/* We need to trim on / or it replaces '/' if we are running
from
root dir */
$prefix_path = trim(dirname($_SERVER['SCRIPT_NAME']), '/');
/* Remove any prefixed URL path */
$path_string = str_replace($prefix_path, '', $path_string);
/* remove query string */
$path_string = str_replace('?'.$_SERVER['QUERY_STRING'], '',
$path_string);
} else {
$path_string = $_REQUEST['path'];
}
return $path_string;
}
As you can see, this looks at server variables, which explains that. On
the site it's used, it allows us to use a clean search engine / user
friendly URL system, instead of using HTTP GET/POST variables for the
front controller's dispatching. If no server variables are used, it
looks at $_REQUEST['path'] as a safety fallback.
I found that setting $_REQUEST['path'] to the right value (so it
doesn't touch the $_SERVER
#29104 [Com]: Function declaration in method doesn't work
ID: 29104
Comment by: Jason at hybd dot net
Reported By: tomas_matousek at hotmail dot com
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: WinXP
PHP Version: 5.0.0RC3
New Comment:
From what I gather, like most languages, PHP doesn't
support 'nested' methods. (And therefore I doubt this is
a bug)
Where you are calling f() is ambigous. As far as PHP is
concerned f() is probably a global function and not a
method embedded inside a::g().
Previous Comments:
[2004-07-12 09:41:23] tomas_matousek at hotmail dot com
Description:
Declaration of a function in a method doesn't work.
IMHO by declaring a function in a method one creates a function not a
method. It it was a method it would be possible to call it by $a-f().
That works neither.
See the code below:
Reproduce code:
---
class A
{
function g()
{
echo function g - begin\n;
function f()
{
echo function f\n;
}
echo function g - end\n;
}
}
$a = new A;
$a-g();
f();
Expected result:
function g - begin
function g - end
function f
Actual result:
--
function g - begin
function g - end
Fatal error: Non-static method A::f() cannot be called statically ...
--
Edit this bug report at http://bugs.php.net/?id=29104edit=1
#29092 [NEW]: Object Upcasting Occurs upon itterating children
From: Jason at hybd dot net
Operating system: Windows 2003 Enterprise Server
PHP version: 5.0.0RC3
PHP Bug Type: *XML functions
Bug description: Object Upcasting Occurs upon itterating children
Description:
When using the itterator DomNode::childNodes to cycle through nodes
objects that have been extended though PHP (In this case, TplTagDefault),
the behaviour becomes inconsistent.
As you can see from the output, the object returned is sometimes a
TplTagDefault but other times it's a DOM* object. Generally the last item
in the DomNodeList is of the correct type.
I have posted this on a couple of forums/IRC support places and they all
seem to agree it's a bug (though few people seem to have DOM/XML
understanding). If this is not a bug, please could someone explain how I
prevent objects from lossing their inheritance (i.e. prevent upcasting)
when cycling through them.
-- Jay
Reproduce code:
---
?php
class TplCompileTree extends DomDocument {}
class TplTagDefault extends DomElement {}
$docRoot = new TplCompileTree();
$newNode = new TplTagDefault('Root');
$docRoot-appendChild($newNode);
for($i = 0; $i 3; $i++) {
$newNode-appendChild(new TplTagDefault('Kiddy'.$i));
}
foreach($docRoot-childNodes AS $child) {
var_dump($child);
foreach($child-childNodes as $kids) {
var_dump($kids);
}
}
echo $docRoot-saveXML();
?
Expected result:
object(TplTagDefault)#13 (0) {
}
object(TplTagDefault)#18 (0) {
}
object(TplTagDefault)#20 (0) {
}
object(TplTagDefault)#14 (0) {
}
?xml version=1.0?
RootKiddy0/Kiddy1/Kiddy2//Root
Actual result:
--
object(TplTagDefault)#13 (0) {
}
object(DOMElement)#18 (0) {
}
object(DOMElement)#20 (0) {
}
object(TplTagDefault)#14 (0) {
}
?xml version=1.0?
RootKiddy0/Kiddy1/Kiddy2//Root
--
Edit bug report at http://bugs.php.net/?id=29092edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29092r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29092r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29092r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29092r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29092r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29092r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29092r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29092r=support
Expected behavior: http://bugs.php.net/fix.php?id=29092r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29092r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29092r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29092r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29092r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29092r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29092r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29092r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29092r=float
