Wrong links in menu

Hi,

I’ve installed the Menu Application on my XWiki, allowing me to display a menu in the left panel.

However, when I edit this menu and insert a link (through the dedicated WYSIWYG button), the link is wrong.
I have to change it manually and add the “Technical Services” to make it point to the right page.

xwiki-menu

If I leave it as is, when I click on the link, it will ask me to create a page as it cannot be found.
If I create a page from this prompt, the page will be created under Menu > TS Material (missing the Menu > Technical Services > TS Material

Any idea, how I can get this link to be correct without any manual modification ?

Thanks for any help / advice :slight_smile:

I guess the issue is that your link is relative and not absolute (see the leading dot). Try making it absolute.

Oh, but how do you make it absolute from the WYSIWYG ?

xwiki-menu-3

Thing is, I can’t propose to the source editor as people without any knowledge of how this works will be using the platform.

AFAIK WYSIWYG always proposes absolute links, @mflorea is that so?

Thanks

@vmassol no, the WYSIWYG editor generates relative references whenever possible (e.g. when inserting links or images). That’s not the issue. The issue is that the menu is rendered in the context of the current document, so all relative references are resolved relative to the current document instead of being resolved relative to the menu document. We don’t see this issue often because most of the time the pages linked in the menu are not nested within the menu page. Honestly, I find it strange to organize your menu links as nested within the menu page. The pages you link from the menu shouldn’t be aware that they are displayed in a menu :slight_smile: . But anyway, this is something to fix in the Menu Application (and possibly in the UI Extension API, to support rendering in the context of the UIX document rather than in the context of the current document; it may be already supported, I haven’t checked).

Thanks. Yes, I had guessed this was the case but if the user uses absolute references, they can work around this problem.

Ok, I didn’t know (or remember) that the WYSIWYG was generating relative URLs. I hope this is not causing other problems elsewhere (like when including pages, etc). It feels slightly weird since when we write links (on xwiki.org for ex) we never use relative links, so either we’re doing it badly and we should use relative links more or using relative links doesn’t bring that much advantages. I haven’t thought about it so I don’t know what are the pros and cons. BTW do we have some doc on this (best practices of using relative links vs absolute ones)?

We always use relative links on xwiki.org but most of the time we make them relative to the current wiki, i.e. we don’t include the wiki component when the target page is on the same wiki.

Depends how you include the content. If you use the Include Macro (with context=current) to include a page from a different wiki then it’s enough for that page to have links that do not have the wiki component in order to have problems. So when you include content you need to check if it can be included in the current context (no relative references) or if it needs its own context.

Relative links are definitely better as it allows you to encapsulate the content and thus make it portable. You can export and import in another wiki, you can copy to another location without the need to perform changes. Refactoring (move/rename) is also easier.

I can’t find anything on xwiki.org regarding this, but I’m pretty sure we discussed about this in the past on the developers mailing list.

yes ofc but that was not my point. My point is that we never use leading dots/links relative to spaces.

Yes except that including pages cross-wiki is a lot less used than including pages from the same wiki.

This looks pretty theoretical since we’ve never had this issue on xwiki.org over 14 years. And we have done the use cases you mention a lot: move between wikis, copy to another location, move/rename.

Actually I’d say that we get even less problems with absolute links than relative ones since if you move a page having relative links and you don’t move these pages too then you’re going to break the links, which doesn’t happen when you use absolute links.

So my POV (backed by 14 years of experience on xwiki.org) is that it’s the opposite to what you say: there are usually more benefits to using absolute links than relative ones.

I don’t remember that. We introduced the concept but never used it ourselves. And I don’t know a single occasion where we’ve used it for real and with an advantage. For me it’s enough to note that the most knowledgeable xwiki users (us) don’t use relative links at all to question the supposed advantage of them. I can see several problems with them (including this thread) but very few real benefits. I’m not saying that we shouldn’t have support for relative links but that their need/usage is marginal and I don’t think we should use them for WYSIWYG (at least by default). At the very minimum I’d question that, to make sure it’s a good idea.

We should ofc fix the Menu app too.

Hey,

Thanks @vmassol and @mflorea for your support.

The reason I nested the pages in the menu context is because when I create that menu, it automatically goes as a page in the “native” menu.

So I can’t create the structure under the “native” menu and then create a page named the exact same way as the first-child menu link.

xwiki-menu-4

In this example, I have a menu TESSSS, all the links in that menu are refering (now) to pages under Technical Services (I made the change based on your previous response).
But now, I can’t rename TESSS into Technical Services, because this name (and so page) is already existing.

So, i’m guessing that I’m using this menu extension in a wrong way.
Could you let me know if it is the case ? If so, how can I correct this wrong?
Are we saying that everybody is setting their pages automatically under “Home”, or on the same level as “Home” ?