Issue: VW Admincp functions do not work after install

Issue Tools
- View Changes

March 16, 2017 7:39 PM

Alfa1

Distinguished Member

VW Admincp functions do not work after install

After installation of VW on my live site, none of the fucntions work here:
/admin.php?wiki/
The links work, but nothing is loaded.

The permissions sidebar of the users page has this:

vw_admin_navigation_prefix Wiki Permissions

It seems it doesnt load any phrases.

The options links at the top do not expand.

It seems to me the install is botched again.

I can access VW options from the standard XF options page.
/admin.php?options/

Issue Details

Issue Number 4955

Issue Type Bug

Project VaultWiki 4.x Series

Category Install / Upgrade

Status Fixed

Priority 3 - Loss of Functionality

Affected Version 4.0.17

Fixed Version 4.0.19

Milestone (none)

Software DependencyXenForo 1.x

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

March 17, 2017 9:50 AM

pegasus

VaultWiki Team

If you go to the Tools tab in the AdminCP, is there a pending cache rebuild that tries to finish? If not:

It sounds like the phrase-cache rebuild and the admin-template-cache rebuild that were triggered by the installer have not been applied to a higher level cache that you have. If you use a XenForo add-on that caches phrases and templates (such as [bd] Cache or DragonByte Optimise), try flushing that cache.

I have also seen a similar problem in one version of PHP 7. It was possible to reset the cache by restarting PHP. The issue also stopped occurring for upgrades after upgrading PHP to the next version. I do not remember what exact PHP version it was.

Most recently, a user told me this was related to CloudFlare, and that flushing Cloudflare's cache resolved the issue.

This issue is sometimes limited to the IP that installed the wiki. When some customers who reported this issue submitted a private ticket, the admin panel loaded correctly for my IP, and was magically fixed for their IP the next time they visited.

Reply
March 17, 2017 11:46 AM

Alfa1

Distinguished Member

I am using redis (xenforo plugin), php7 and litespeed cache (xenforo plugin). I am not using cloudfare.
This does not cause any problems with installation or upgrades of other addons.
Refreshing Litespeed cache has no effect.
Flushing Redis has no effect.
7.1.1

Reply
March 17, 2017 12:10 PM

pegasus

VaultWiki Team

PHP 7.1.1 might be the version I am thinking of (the release dates seem to be near when I noticed the issue). Have you tried restarting PHP?

Is this the same setup (same add-ons) that you used on your test board? If it is not a cache issue, then it could be an add-on conflict.

For example, this also occurred due to a conflict with a Brivium add-on "Admin Style System", but we resolved that conflict a few versions ago.

You are welcome to submit a private ticket so that we can investigate the cause on your site.

There have been no changes to the VW+XF installer since your last successful installation of 4.0.17, apart from the fix for the missing vw_usercount column. So it is likely there is something different about your environment this time.

Reply
March 18, 2017 4:53 PM

Alfa1

Distinguished Member

I see that after a day the functions appear. I find this worrisome, because if there are parts of VW not fully loaded then an import can be botched. Same for upgrades.
I have uninstalled and reinstalled VW. The same issue appeared.
I will upgrade to PHP 7.1.3 next week.

Reply
March 18, 2017 5:42 PM

pegasus

VaultWiki Team

If the functions appear after a set amount of time without you doing anything else, then this is almost certainly cache related. You will have to determine what cache is causing the problem and tweak it, but I did have some problems with PHP 7.1.1 (I think) -- in my case, not even related to VaultWiki; something as simple as changing a standard XenForo setting appeared to be unchanged until I manually restarted PHP -- so that might be it.

Reply
March 20, 2017 7:24 PM

Alfa1

Distinguished Member

We upgraded PHP to 7.1.3 and I did a new reinstall. Unfortunately the issue was not resolved.
Maybe Vaultwiki is not compatible with XF Redis or XF LiteSpeed?
Every other addon works well. All settings and front end UI displays normally. Except for VW.

Reply
March 21, 2017 10:11 AM

pegasus

VaultWiki Team

I would be happy to look into this. Are you able to reproduce the issue on your test board?

Reply
March 22, 2017 3:20 PM

Alfa1

Distinguished Member

I have installed on a test board on the same server now and the admincp pages do show.
It seems to me that there can be 3 possible causes of this issue:

1. addon comflict. I can simply exclude this by installing the same addons.
2. Vaultwiki is incompatible with Redis.
3. Vaulwiki is incompatible with LiteSpeed Cache.

The latter 2 causes would be showstopper issues. My site cannot be run without these cache mechanisms.
Are there any other big boards running VW4 on XF?

Reply
March 23, 2017 10:08 AM

pegasus

VaultWiki Team

Make sure that all 3 (add-ons, Redis, and Lightspeed Cache) also apply to your test board. Once you are able to reproduce the issue on the test board, please open Ticket Support so that we can identify the conflict or incompatibility or bug at play here.

There are other big boards running VW4. I do not recall how many use vBulletin vs XenForo. Other big board owners tend to post feature requests, rather than performance issues; however, it has happened - VWE-2015-1618 was reported by a big board. If they can be exploited, performance issues are usually treated with the same importance as security vulnerabilities.

Reply
March 23, 2017 3:54 PM

pegasus

VaultWiki Team

On a test board, I have tried the following:
- A default installation of Redis (3.2.8) + Xon's "Zend Redis Cache" add-on
- A default installation of Redis (3.2.8) + phpredis (3.1.1) + Xon's "Zend Redis Cache" add-on

I have not encountered problems while installing VaultWiki under these conditions, and do not see any noticeable difference in the AdminCP after installation.

Reply

March 24, 2017 9:59 PM

Alfa1

Distinguished Member

Could you try with these settings:

Redis Version: 3.2.8
phpredis version: 3.1.1
Using Lua: Yes

Config:

Code:

$config['cache']['enabled'] = true;
$config['cache']['cacheSessions'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_';
$config['cache']['frontendOptions']['automatic_serialization'] = false;
$config['cache']['frontendOptions']['lifetime'] = 0;
$config['cache']['backend'] = 'Redis';
$config['cache']['backendOptions'] = array(
'server' => '127.0.0.1',
'port' => 6379,
'connect_retries' => 2,
'use_lua' => true,
'compress_data' => 2,
'read_timeout' => 1,
'timeout' => 1,
'force_standalone' => false,
);
require(XenForo_Application::getInstance()->getConfigDir().'/SV/RedisCache/Installer.php');

Please also add Redis backend flood checking by Xon.

March 25, 2017 11:03 AM
pegasus

VaultWiki Team
Still no issues.

I wonder if Litespeed cache is inadvertently caching some of the install processes. Are you installing in automatic mode or manual mode? When you install, do any of the sub-requests for the steps serve from the Litespeed cache (you should be able to tell from the response headers)? If so, what are the response headers?

If you were having this issue only while installing using manual mode, try editing vault/core/controller/cp/progress/vw.php. Find:

Code:

header('Connection: close');

After it, add:

Code:

header('Cache-Control: no-cache');
Reply
March 26, 2017 7:57 AM

Alfa1

Distinguished Member

Installing in manual mode is impossible due to the site of my board.

I have upgraded to xf 1.5.13 and for some reason I can now install VW4 on my live site with a working admincp. Weird!

Reply
July 7, 2017 1:52 PM
pegasus

VaultWiki Team
I believe I have finally figured this out. It is not related to Redis or Litespeed, but rather another factor that is different between the live and test sites, which is traffic volume. This issue occurs due to a combination of race conditions that is only possible in a high-traffic environment.

While installing VaultWiki, the installer begins the "Rebuilding Caches" step. This relies on a XenForo deferred task. XenForo deferred tasks work in the following manner:

HTTP request that will run the task.
Delete the task from the queue, establishing a lock. If nothing is deleted, the task is locked or already finished. This prevents multiple iterations from running in parallel.
Run the task.
Insert the task back into the queue.
Reload a new HTTP request to run the next batch.
While reloading the HTTP request for the task, another user's HTTP request resolves first (in the front-end) so the deferred task system gives the task to that user. The user locks the task, so the task disappears from the queue.
At this point, there would not normally be a problem. VaultWiki's installer assumes that it has completed the task in the previous batch, and the installer completes. The other user would just complete the task, but in especially high traffic:
VaultWiki's HTTP request resolves while the user is performing the task. The user's batch finishes and tries to requeue the task at the same time VaultWiki tries to remove a matching task from the queue (for its lock).
This creates a deadlock. Neither the user performing the task nor VaultWiki are able to continue the task. The task is not requeued. XenForo is designed to respond to this deadlock silently without logging an error. The response from the deferred system is the same as if the task was completed.
VaultWiki's installer completes, not aware that a problem occurred.

I was able to complete the installation on your site by limiting the permissions for the task to a single user. However, I am aware that this permission was loosened in the past for a similar reason, so I will need to research the previous task permissions and do more tests before I can say that this issue is really fixed. If anything, customizations to XenForo's built-in deferred system may be required in order to avoid this deadlock while also satisfying whatever other factors are at play.
Reply
July 7, 2017 8:04 PM

Alfa1

Distinguished Member

Please check out this addon: https://xenforo.com/community/resour...e-by-xon.4973/
Maybe this can be extended to VW.

Reply

+ Reply

All times are GMT -4. The time now is 5:45 PM.

This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Learn more… Accept Remind me later

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: VW Admincp functions do not work after install

Issue Tools