Content menus don't work

[stained]

Sometimes, apparently for no reason, the content menus on my pages don't work. Clicking on any menu item just scrolls the page to the top of the menu. Any ideas what may be causing this?

[pegasus]

Please check your browser's Javascript console for error messages. Since a recent patch, Javascript is required for scrolling when clicking an item in a wiki page's table of contents.

[stained]

Hi,

Okay, never done this before so bear with me. I see the following when I load one of VW pages but I don't really understand whether any of the messages regarding js relate to the problem:

cons.jpg

[stained]

It happens in FF, IE and Chrome (Javascript is on in all of them). I did find a while back that if I recreated a page the menu functioned as intended but not even that works now.

[pegasus]

I notice that for some of your resources the URL has HJ in capital letters, but for other resources the URL has HJ in lower-case letters. When the link doesn't work, when you hover over it, does the target location have capital or lower case? Does this match the current capitalization in the address bar? You should make sure that all of your configurations use the same capitalization. This includes:
- Forum URL
- Wiki Base URL
- HTTP Server Configuration of Domain

If all three of these do not match, it is possible that the link may not function properly. I will look into the possibility of working around such a misconfiguration from the Javascript side.

[stained]

Hi,

Yes, the content menu links are lower case and if I right click and open the links in a new tab they go to the correct section.

My forum URL is lower case in admincp--->Site Name / URL / Contact Details. The same goes for the Wiki Base URL so the upper case "HJ" that is visible when viewing page source is weird. What do you think might be causing that?

[pegasus]

I think your HTTP server configuration (such as Apache or nginx) may have the domain configured with an uppercase "HJ" in one of its config files. So any link that references the server's answer to "what is the currently-accessed URL" has an uppercase instead of a lowercase.

[stained]

Okay, that makes sense. I'll get on to my host. Thanks very much for your help.

[stained]

I asked my host to check and they say that the configuration is fine. I also asked over on vbulletin whether those mismatches have an effect on VB operation and it would appear that having upper and lower case versions of the url should not produce problems. So, back to square one

The problem with the content menus is intermittent. Since installing 4.0.18 I have seen this problem with the content menu on either just one page or, as now, on all pages. In the past I was able to fix single pages by recreating them but that doesn't work now.

You asked earlier whether the links in the content menu are upper or lower case. If I hover over them I see lower case: https://www.an-exampleurl.com. However, if I inspect them they are upper case:

<a onclick="_gaq.push(['_trackEvent', 'Outgoing', 'www.AN-exampleurl.com', '/forum/showwiki.php?title=How-to-create-and-or-edit-an-article']);" rel="nofollow" href="https://www.AN-exampleurl.com/forum/showwiki.php?title=How-to-create-and-or-edit-an-article#Adding-attachments"><span class="vw-toc-number">4.4</span>Adding attachments</a>

[pegasus]

The configuration may be "fine", but the capitalization must be introduced somewhere, and VaultWiki is not the one introducing it. Although the web server functions correctly, and vBulletin functions correctly, and VaultWiki for the most part functions correctly, from what I can tell this will still fail the Javascript match used to test the menu link, link.href.substring(0, index) == window.location.href.substring(0, indexL), because upper-case == lower-case is not true (index and indexL refer to the positions of # in each href). The test, "does the URL we are viewing match the URL we are going to" fails.

If the mismatch in your configuration is not resolved, the workaround to this problem is simply to fix another bug in the menu Javascript, which is that "if a menu link does not point to the same wiki page, follow the link" was not working.

[stained]

Okay, it's possible that they were not diligent when they initially looked into the problem. I'm with a company that was fantastic until being taken over by HEG in 2016. Customer support is not what it was unfortunately. I will ask them to look into the HTTP config once again. Very good to know that there is the possibility of a workaround.

[stained]

They checked again and said:

"I just checked the database, the files and the apache config and the HJ is not present in any of them.
It is definitely not coming from the apache config."

So, not VW and not the server config. I see that {vb:raw basepath} is the upper case version too which points to VB being at fault perhaps?

[stained]

Can't be VB...

Anyway, when viewing page source and hovering over links containing 'www.AN-exampleurl.com' the actual link shown at bottom left of the browser is the correct version: 'www.an-exampleurl.com'

[pegasus]

Both vBulletin and VaultWiki use the same method to create the links in question. It gets this part of the link from the following PHP environment variables, which are usually populated outside of PHP (such as a web server, proxy, etc, which sends the values to PHP). vBulletin/VaultWiki tries the variables in the following order; the first one that returns a result is the one that is used for the links:
1. $_SERVER['HTTP_HOST']
2. $_ENV['HTTP_HOST']
3. $_SERVER['SERVER_NAME']
4. $_ENV['SERVER_NAME']

So, unless you have a forum plugin that is modifying these or is modifying the output of some links, you may wish to investigate the values of these variables.

[stained]

Cheers. I've passed those variables onto them. I agree with you that it must be something at the server level and wish I could check myself.. I have tried "disable hooks" and a hard refresh but no change so I would think that my plugins are not the origin.