Issues

ZF-2437: Zend_Config_Xml Does not properly support nested items

Description

This is an example config file that i have.


<?xml version="1.0" encoding="UTF-8"?>
News/news/Schedule/schedule/

When i run it though the the Zend_Config_Xml it doesnt return it right. I have narrowed the problem down to the _toArray() function.

it returns an array like this:


Array
(
    [default] => Array
        (
            [navigation] => Array
                (
                    [nav_item] => Array
                        (
                            [nav_text] => News
                            [nav_link] => /news/
                            [0] => Array
                                (
                                    [nav_text] => Schedule
                                    [nav_link] => /schedule/
                                )
                        )
                )
        )
)

which is not correct as it should be like this one.


Array
(
    [default] => Array
        (
            [navigation] => Array
                (
                    [nav_item] => Array
                        (
                            [0] => Array
                                (
                                    [nav_text] => News
                                    [nav_link] => /news/
                                )
                            [1] => Array
                                (
                                    [nav_text] => Schedule
                                    [nav_link] => /schedule/
                                )
                        )
                )
        )
)

Comments

Hi Jon.

Could you see if the below patch works for revision 7191 of Zend_Config_Xml in head. You might need to change the file paths in the attached patch file.

Unfortunately, your patch breaks for this case:


<?xml version="1.0"?>
123

as you end up with a $config->toArray() of this:


array(1) {
  ["six"] => array(1) {
    ["seven"] => array(2) {
      [0] => array(2) {
        [0] => array(1) {
          ["eight"] => string(1) "1"
        }
        [1] => array(1) {
          ["eight"] => string(1) "2"
        }
      }
      [1] => array(1) {
        ["eight"] => string(1) "3"
      }
    }
  }
}

I've fixed appropriately and committed to trunk in svn r7724.

Thanks for the heads up.

Guys. I'll test it tomorrow as i dont have time today.

Thanks providing a patch! I'll let you know.

Hi Rob. Your patch breaks the previous example of Jon. I've managed a patch that work for both the examples. We also need to create more test case scenarios for this. Hope it works this time. Cheers.

Inash,

You are right - my new unit test wasn't a true copy of Jon's scenario :(

I've updated the unit test and fixed it using


if (array_key_exists($key, $config)) {
    if (!is_array($config[$key]) || !array_key_exists(0, $config[$key])) {
        $config[$key] = array($config[$key]);
    }
    $config[$key][] = $value;
} else {
    $config[$key] = $value;
}

So fixed in svn r7727 hopefully!

ok i've freed up some time to test so i'll get this once i finish with another bug.

Hey guys it works great! Bug has been fixed!

Note that this breaks BC with 1.0.3's unit tests, so may have to be re-thought.

For reference:

Given this XML file:


<?xml version="1.0"?>
2a2b54

1.0.3 will produce this $config->toArray():


array(2) {
  ["one"] => array(1) {
    ["two"] => array(2) {
      [0] => string(2) "2a"
      [1] => string(2) "2b"
    }
  }
  ["three"] => array(1) {
    ["four"] => array(2) {
      ["five"] => string(1) "5"
      [0] => string(1) "4"
    }
  }
}

r 7727 of trunk will give:


array(2) {
  ["one"] => array(1) {
    ["two"] => array(2) {
      [0] => string(2) "2a"
      [1] => string(2) "2b"
    }
  }
  ["three"] => array(1) {
    ["four"] => array(2) {
      [0] => array(1) {
        ["five"] => string(1) "5"
      }
      [1] => string(1) "4"
    }
  }
}

Like you said, it does break that. I've checked the tests as well. But I think now it's working properly like it should. I've linked a similar issue to this which you've commented as well. I could now access the fields in your reference as mentioned in that issue.

If this should break the 1.0 branch, the fix could wait until 1.1!? What do you think!?

My opinion is that the former behavior (i.e., from 1.0.3) was broken, and that r7727 fixes the broken behavior. Based on this, the BC issue appears to be that people depending on the broken behavior should simply update to not depend on the broken and (IIRC) undocumented behavior.

Sorry, I also meant to say that I think the fix should be in 1.0.4 (merged to release-1.0 branch), too. :)

I agree too.

I also agree!

Fixed on release-1.0 branch in svn r7732.

Thanks very much for the help guys!

Not a problem. Glad to be helping!