Warning displayed while using with jquerymenu 2.3

Try it on version 1.6. I wasn't able to reproduce your issue, but I added in some new safe guards that should prevent the error if you enable the block when no books exist.

Closed until someone reports on current version.

I am having the same issue. ..."warning: Invalid argument supplied for foreach() in.....jquerymenu.module on line 193"

Just a hunch here, but based on my experience I'd bet you're using Taxonomy Menu to show your site taxonomy as part of the navigation menu that's showing up in the JQuery menu block.

This is the case for me, and apparently it creates some difficulties when you edit the vocabulary in question -- it hasn't happened to me when new terms are added (good thing, too, since the site in question allows a fair bit of freetagging), but when I change the weight of terms within the vocabulary, or edit the whole vocabulary at admin/content/taxonomy/edit/*.

Fortunately, it's easy to work around this. Just go to admin/content/taxonomy, and click on "edit vocabulary" for the vocabulary in question. At the very bottom of the edit page, check the box labeled "Select to rebuild the menu on submit", and then save. This cleared up the issue for me, though it did tend to alter the position of the vocabulary in the overall Navigation menu. But that's fixed easily enough...

Hope this helps.

No. This is not a taxonomy issue. It is caused by errors in the menu database. When the last child in a submenu is removed the parent count is not updated. See http://drupal.org/node/406200#comment-1404208
You can test this analysis by displaying only 1 menu block in your theme that has a very simple or new menu.

Rather than manually edit the menu_links you can just disable blocks until you find the bad menu, compare its has_children using phpmyadmin with your menu displayed in drupal. (First look at menu_custom to get the correct menu name to search on) Drag an item under the link that thinks it has children so that it does, save it, then drag it back and resave.

The best solution would be to fix this in the core menu edit process by checking submenu count when saving a menu update. That would be less overhead than checking it on every display. But Aaron to prevent a lot of frustration and time loss whenever the menu database has a hiccup could you please add a check as mentioned in that thread.

This module has a much better approach than dhtml_menu and providing the api is a great idea, but when I see issues like this that go on for months and no releases in 6 months it makes me worry about the future support of the module.