Can't access XF homepage while VW is enabled | VW 4.1.0 Alpha 1 & XF 2.0.10

I am having a problem with VW 4.1.0 Alpha 1 & XF 2.0.10

When VaultWiki is enabled, I can't access the root URL of XenForo. I get

"Oops! We ran into some problems.
An error occurred while the page was being generated. Please try again later."

with no additional error information (debug mode is enabled in XF config).

If I disable VaultWiki, the root URL works fine. It seems like a greedy redirection issue because any extra info I add after a trailing slash in the root URL it will just direct me to the VaultWiki area. For example, if I enter the URL example.com/forum/test I get redirected to example.com/forum/wiki

I am using the default htaccess file for XF and my URL style looks like this in XF:

https://example.com/forum/whats-new/posts/

Check: Admin > Options > VaultWiki: Site Config.
- Wiki Active, should not be grayed out, should not have a message about a failed task.
- Wiki Base URL, should be: example.com/forum (with http:// in front)
- Name of the Wiki Route, should be: wiki
If the wiki base URL has an extra slash, or if the wiki route is blank, it might explain what you are experiencing. If a deferred task failed, it might be a task related to URL handling.

Some other things to consider are, is your forum server behind a proxy? It is possible that some incoming $_SERVER variables do not match the incoming URL. I have this problem often on my proxy and need to tweak the proxy from time to time. Due to the range of configurations that is possible, VaultWiki is less forgiving in this regard than XenForo by itself. For example, I have seen $_SERVER report the proxy port rather than the requested port, or the proxy path instead of the requested path.

If you still have trouble or if you have a failed deferred task, please update to a newer Alpha so that I can assist you better. There have been a lot of bug fixes since Alpha 1. Current release is Alpha 3.

Quote:

Originally Posted by pegasus

Check: Admin > Options > VaultWiki: Site Config.
- Wiki Active, should not be grayed out, should not have a message about a failed task.
- Wiki Base URL, should be: example.com/forum (with http:// in front)
- Name of the Wiki Route, should be: wiki
If the wiki base URL has an extra slash, or if the wiki route is blank, it might explain what you are experiencing. If a deferred task failed, it might be a task related to URL handling.

Some other things to consider are, is your forum server behind a proxy? It is possible that some incoming $_SERVER variables do not match the incoming URL. I have this problem often on my proxy and need to tweak the proxy from time to time. Due to the range of configurations that is possible, VaultWiki is less forgiving in this regard than XenForo by itself. For example, I have seen $_SERVER report the proxy port rather than the requested port, or the proxy path instead of the requested path.

If you still have trouble or if you have a failed deferred task, please update to a newer Alpha so that I can assist you better. There have been a lot of bug fixes since Alpha 1. Current release is Alpha 3.

The settings are already set the same as what you describe and there are no errors visible - I will update to Alpha 3 and see what happens. Thanks.

Okay I have updated to XF 2.1.1 and VW 4.1.0 Alpha 3 and still have the exact issue. Here is what my VW options look like:

https://i.imgur.com/GDIM4LZ.png

You should find out if the $_SERVER['HTTP_HOST'] variable in PHP contains 35.226.139.164 or something else.
Also, your URL expects the site to be accessed over ports 80 or 443. If the site is behind a proxy, it is possible that the port is changed internally.

If these do not match, you can encounter redirection issues. You can test this easily by making a new PHP script and visiting it:

Code:

<?php header('Content-Type: text/plain'); echo 'Host: ' . (isset($_SERVER['HTTP_HOST']) ? $_SERVER['HTTP_HOST'] : "") . "\n"; if (isset($_SERVER['SERVER_NAME'])) { echo 'Server-name (used as host if above is empty): ' . $_SERVER['SERVER_NAME'] . "\n"; } echo 'Port: ' . $_SERVER['SERVER_PORT']; exit;

If there is an issue with the server configuration, these will not be the expected values, and you will need to fix the server.

I have had similar problems to you if I rewrite friendly URLs to index.php before routing from the proxy to the final location. In this case, I had to store the original URL in a header, pass to the proxy, then unpack that header back into REQUEST_URI when passing to PHP. In nginx, my config looks like this:

Code:

server { listen [::]:443 ssl; server_name example.com; location / { proxy_set_header X-Orig-Uri $request_uri; if (!-e $request_filename) { rewrite ^/xf/(.*) /xf/index.php?$1 last; } proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Port 443; proxy_set_header X-Orig-Https on; proxy_pass http://unix:/example; } } server { listen unix:/example; index index.php; location ~ \.php($|/) { fastcgi_param HTTP_HOST "example.com"; include php.conf; fastcgi_param HTTPS $http_x_orig_https if_not_empty; fastcgi_param SERVER_PORT $http_x_forwarded_port; fastcgi_param REQUEST_URI $http_x_orig_uri; } }

There is no proxy in use. I ran the above code and got this output:

Code:

Host: 35.226.139.164 Server-name (used as host if above is empty): 35.226.139.164 Port: 443

which looks fine to me.

First, check AdminCP > Setup > Navigation > Route Filters, for any filters that exist with an empty find route and disable them. This behavior will definitely occur if there is a filter where [empty] => wiki, but possibly another one is triggering it.

Please make the following edit, which helped me when I had a loop while Friendly URLs were turned off and I visited the wiki route without index.php (and the wiki-route root was different from the forum root). In src/addons/vw/vw/XF/Mvc/Router.php, find:

Code:

public function buildLink($link, $data = null, array $parameters = [])

BEFORE it, add:

Code:

protected function suffixMatchesRoute($suffix, array $route, \XF\Mvc\RouteMatch $match, \XF\Http\Request $request = null) { if ($match->getController() == '\vw\vw\Pub\Controller\Wiki\Wiki') { $params = $match->getParams(); if (!empty($params['vwResolvedRoute']) AND $params['vwResolvedRoute']->id > 0) { return $match; } } return parent::suffixMatchesRoute($suffix, $route, $match, $request); }

If after this change, your forum index redirects to the wiki index, that tells us that for some reason the router believes the wiki index path has a different root from the forum index path. Check Options > Basic Board Information > Board URL. For your configuration to work correctly, it should be the same value as the Wiki Base URL established in your earlier post.

If all these are correct, I would recommend opening a support ticket so that the problem can be investigated more closely.

Quote:

Originally Posted by pegasus

If after this change, your forum index redirects to the wiki index, that tells us that for some reason the router believes the wiki index path has a different root from the forum index path. Check Options > Basic Board Information > Board URL. For your configuration to work correctly, it should be the same value as the Wiki Base URL established in your earlier post.

If all these are correct, I would recommend opening a support ticket so that the problem can be investigated more closely.

I have switched to the forum account which has our VaultWiki license so that I can open a ticket. To answer your reply, there are no route filters and after making the edit there are no changes to how the forum behaves. The root URL still goes to an Oops message and all non existent subURLs under forum/* redirect to the wiki route.

Actually I just refreshed the root URL and it redirected to the wiki this time! So I checked my Board URL and sure enough it was set to our load balancer address instead of the actual server address. VW was set to the actual server address. Now that the two addresses match, the issue is resolved. Thanks for your help!

I can't figure out how to close the ticket I just opened?