I’m making my own custom walkers for my theme’s navigation and category display. I’m curious if there’s a reason for something I’ve noticed.
If you var_dump $args within a class that’s extending Walker_Nav_Menu, it’s an object of class stdClass. However, if you do the same within a class that’s extending Walker_Category, it’s an array. (I noticed because I was copying something from my navigation menu class and it didn’t work as expected.)
Does anyone know if this is just ‘one of those things’ or if there’s a specific reason why this is? I’m trying to learn the underlying concepts for what I’m doing too, that’s why I wondered.
Edit: Now that I’m thinking about it, I wonder if it has to do with what it’s walking through. The Walker class says it can traverse ‘an array or object with hierarchical data’. I wonder if a menu is treated as an object but a taxonomy is an array and what you get in the $args variable just conforms to that? Would still like to know if anyone knows, though. My googling skills didn’t get me anywhere on this one.
Calling wp_nav_menu(), which takes an array of $args. One of those arguments says to use Class A as its walker. Class A is my own custom class extended from the Walker_Nav_Menu class.
If you use var_dump($args) inside a function in Class A, you see it is an object of class stdClass.
Walker_Category
Calling wp_list_categories(), which takes $args as an array or string (I’m using an array in this case). One of those arguments says to use Class B as its walker. Class B is my own custom class extended from the Walker_Category class.
If you use var_dump($args) inside a function in Class B, you see it is an associative array.
So for whatever reason, wp_nav_menu on line 98 turns the parsed array $args into an object.
Why, I have no clue, as apply_filters accepts anything spreadable as its args. But it then proceeds to use $args as an object throughout the rest of its code.
TLDR there doesnt seem to be a code-requirement reasoning for the difference. the Walker base class’ walk function splats the input regardless of what it is.
OK, thank you for the information! Sometimes the ‘why’ is an important conceptual answer, and sometimes it’s ‘because someone did it that way a while ago and now everything expects it to be that way’.
Agreed, and if i could find and point at a bit of code that i could say “see, this ONLY accepts an object”, it would make sense. I imagine the why at this point is “someone did it that way a long time ago and noone’s updated the codebase.”
For sure. But I had missed the line 98 then when I was walking through and trying to work out what was happening. In the private function I’m using, I think I’ll just cast $args into an object if it’s passed as an array, and that should fix my problem. It’s just a private function that’s helping with code indentation anyway.
Either way works; you can object cast whatever comes in and guarantee you’ve got an object; or you can wp_parse_args like the functions do (see line 81) and guarantee you’ve got an array.