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?
Printable View
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?
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.
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:
Attachment 1617
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.
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.
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?
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.
Okay, that makes sense. I'll get on to my host. Thanks very much for your help.
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>
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.
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.
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?
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'
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.
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.
They checked again and there are definitely no problems with those variables. The server isn't causing the issue. I have the upper/lower case mismatch even when I disable all plugins. I'm stumped... You mentioned looking into the possibility of working around such a misconfiguration from the Javascript side and I was wondering whether that has proven feasible.
I guess not then.
I've done some tests on my own using a hostname with different capitalization "vaultWIki" vs "vaultwiki", and the new code appears to jump to the appropriate heading. This change puts VaultWiki's jump code in compliance with: https://tools.ietf.org/html/rfc4343#section-3
That's great news. Many thanks. It would be fantastic if I could get my menus to work again.
Edit: so after reading your post again do you mean that upper/lower case etc can be catered for already by Vaultwiki? So you still see my server as the culprit? I don't know what else to do to be honest as I'm on shared hosting and do not have access to the config files to see for myself whether they really are the problem. I kinda have to believe them when the techs say that everything is corect at their end.
Yes, my meaning is that VaultWiki will now correctly jump between sections even if the upper/lower case doesn't match between the domain of the current page and the domain of the jump link. This means that wherever the misconfiguration is, whether it's your server, or another vBulletin add-on, VaultWiki won't care anymore.
You can find out for sure if it's a server misconfiguration by creating a test PHP file outside your vBulletin directory and then visiting it.
It should show the hostname and servername as PHP receives it from the server, because in this test, there is no other code in between.Code:<?php
echo '$_SERVER[HTTP_HOST] = ' . $_SERVER['HTTP_HOST'] . '<br>';
echo '$_SERVER[SERVER_NAME] = ' . $_SERVER['SERVER_NAME'];
exit;
If both variables appear to be correct, then the difference lies somewhere in vBulletin's settings or one of your vBulletin add-on settings.
That's great. Thanks. The server responded with the correct lower case version of the domain so it's looking like a plugin.
When you say " VaultWiki will now correctly jump between sections even if the upper/lower case doesn't match between the domain of the current page and the domain of the jump link" do you mean that a newer version of VW than I currently have is capable of this? I have 4.0.18.
4.0.19 does this.
Just wanted to confirm that 4.0.19 has done the trick on my site. Content menus are working perfectly now. Many thanks!