Hi!
It seems like there is a small bug in a menu lib when generating a menu on an error page. The page gets broken when using this lib.
I am using the 1.3.3 version of the menu lib. Am I doing something wrong or this a bug?
Thanks!
Hi,
Please paste the code you use the generate the menu.
I’m guessing the content-object is not what you’d expect when on an error page, meaning the menu-lib can’t generate a menu for you on error pages. To generate a menu the lib-menu relies on portal.getSite(), portal.getContent() and content.getChildren().
Sorry. Forgot about the code. 
This is the function that is called:
var menuItems = libs.menu.getSubMenus(3);
Here are the lines from the log, which help to identify the error:
at jdk.nashorn.internal.scripts.Script$Recompilation$27$2298AD$index.L:1#menuItemToJson(com.company.site:/site/lib/enonic/menu/index.js:96)
at jdk.nashorn.internal.scripts.Script$Recompilation$22$876AI$index.L:1#getSubMenus(com.company.site:/site/lib/enonic/menu/index.js:51)
at jdk.nashorn.internal.scripts.Script$Recompilation$20$2073AA$utils.L:1#getPageComponents(com.company.site:/site/lib/utils.js:75)
at jdk.nashorn.internal.scripts.Script$Recompilation$128$441A$error.L:1#handle404(com.company.site:/site/error/error.js:16)
It seems to me it tries to get the content._path, but gets broken because content is null.
Please, let me know if you need more information.
Thanks!
Hi,
Please join the discussion for this issue on Github. I’ve created an issue there for you to track.
We’re currently working on 1.4.0 of lib-menu and hope to get this into that version (if possible, error pages are a bit special since they’re served without context, so it might not be an easy fix).
NB! For error pages - please consider what data you actually neeed as you don’t want to get an “error on errorpage” situation. Things like fetching content for a 404 page might be ok, but definetly not for a 500 page if the reason for instance is problems accessing the content API.
So, in short keep errorpages as simple as humanly possible to avoid any problems.
This is solved in 2.0.0, I’m about to release it today. However, since it has rewritten queries (making it up to 100 times faster!) it will not run on less than 6.13.1 of XP.
The error occurred because we do some checks on “are we currently on this content/path” when looping through the menu tree, in an errorHandler getContent() returns null, making this check fail. It will now use the getSite() data as fallback.
But as Thomas advice, too much logic in the errorHandlers might cause them to spin out of control with errors inside the errors, causing eternal loops. So, at least be very careful on what you’re doing.
Hi guys
Thanks for you replies and advice.
Is the updated menu lib already released? It seems like my Enonic instance is not pulling the new version. Also, git says 1.3.3 is the latest version:
Am I doing something wrong? 
My Enonic version is 6.13.1.
Thanks!
Hi,
Github is saying 2.0.0 is the latest, it is just not so visible since I didn’t draft any release notes this time.
Just change to 2.0.0 in the build gradle include line and you will be good to go. Because of multiple changes (introducing thymeleaf fragments, and more) be sure to test this in your app. And give feedback on Github if anything is odd.
In case this can help anyone else:
It seems like there was some cache or something like that with gradle. Running ./gradlew deploy --refresh-dependencies
solved this.
Also, I am not experiencing original bug anymore and a menu works perfect.
Thanks!