Essentially it was code in the powerstore that we added because we didn't have anything like framework builder when we created the page.
The reality is that the solution for v4 was to actually remove most of the code and complexity from the page and create the menu as a plugin. That way we could use relative paths to the connection and in the links themselves and framework builder makes it all work.
In this case we had added 40 or so lines to account for having different paths to the menu page possibly from different directories. Since framework builder accounts for all of that stuff for you... you could say it ended up doing it twice. If the code were written by Dreamweaver and not hand coded by us, it would have worked, but we wanted to use an include for the menus and they could be in any sub-directory.
To be more specific than to say "it doesn't work on more complex sites".... Maybe we should add a note: In order to use plugins or themes you should update your plugin or theme pages to use paths relative to the directory the pages are stored in. This is a particular consideration when updating things that were already in include files into plugin files...
Dreamweaver will automatically use the relative paths, so for this to happen you must have hand coded or at least updated the include directories on the included page.
Let's use menus as an example, since that is where you ran into the problem. The basic structure of the current powerstore menus (without plugins) is that a front end page displays the navigation and links to any number of pages in any number of sub-directories.
Now the menu is stored in its own folder. Since we use a standard recordset, if we add a connection to the menu page it will use a relative path to the connections folder like:
But if the page that contains the menu is in the root, then it would need to be updated to: require_once("Connections/MyConnection.php");
Now... if it could be in any directory, like a menu, you can't use a static path at all (without something like framework builder), so you need to use code to dynamically find the correct directory path and create a dynamic require_once based on the page that had the menu displayed... so you end up with something like:
// a dozen or so lines of code to determine the $relativePath
require_once($relativePath . "Connections/MyConnection.php");
and you have to do something similar to the links themselves since they too need to reflect the proper location... so the links need to be root relative and you need to determine the site root with a bunch more code and add code to each link.
With Framework builder it all becomes simple. You create the menu as a plugin. Use the relative paths that dreamweaver would put in if you apply a recordset and set relative links in the menu just like any other DW link, and the plugin code accounts for all that stuff for you.
So essentially there was an overcomplification of the menu page to account for a lack of framework that causes a code mis-match once the framework is applied. Anyone that doesn't account for this problem specifically by hand coding won't run into the issue even on the most complex sites. And the developer that has accounted for it will be relieved to be able to remove the bloat that is no longer necessary that caused it.